aboutsummaryrefslogtreecommitdiffstats
path: root/commit.c
diff options
context:
space:
mode:
authorNicolas Pitre <nico@cam.org>2007-05-09 14:42:42 -0400
committerJunio C Hamano <junkio@cox.net>2007-05-10 15:22:33 -0700
commit726f852b0ed7e03e88c419a9996c3815911c9db1 (patch)
treebd0fc241e9265851d7107982a26e4282ebca89d6 /commit.c
parentmake "repack -f" imply "pack-objects --no-reuse-object" (diff)
downloadgit-726f852b0ed7e03e88c419a9996c3815911c9db1.tar.gz
git-726f852b0ed7e03e88c419a9996c3815911c9db1.zip
deprecate the new loose object header format
Now that we encourage and actively preserve objects in a packed form more agressively than we did at the time the new loose object format and core.legacyheaders were introduced, that extra loose object format doesn't appear to be worth it anymore. Because the packing of loose objects has to go through the delta match loop anyway, and since most of them should end up being deltified in most cases, there is really little advantage to have this parallel loose object format as the CPU savings it might provide is rather lost in the noise in the end. This patch gets rid of core.legacyheaders, preserve the legacy format as the only writable loose object format and deprecate the other one to keep things simpler. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'commit.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-23 20:25:13 +0000
s='logsubject'>xdl_merge(): introduce xmparam_t for merge specific parametersJunio C Hamano6-12/+17 So far we have only needed to be able to pass an option that is generic to xdiff family of functions to this function. Extend the interface so that we can give it merge specific parameters. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2010-01-16git_attr(): fix function signatureJunio C Hamano9-14/+19 The function took (name, namelen) as its arguments, but all the public callers wanted to pass a full string. Demote the counted-string interface to an internal API status, and allow public callers to just pass the string to the function. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2010-01-10rerere forget path: forget recorded resolutionJunio C Hamano4-0/+161 After you find out an earlier resolution you told rerere to use was a mismerge, there is no easy way to clear it. A new subcommand "forget" can be used to tell git to forget a recorded resolution, so that you can redo the merge from scratch. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2010-01-10rerere: refactor rerere logic to make it independent from I/OJunio C Hamano1-35/+76 This splits the handle_file() function into in-core part and I/O parts of the logic to create the preimage, so that we can compute the conflict identifier without having to use temporary files. Earlier, I thought the output from handle_file() should also be refactored, but it is always about writing preimage (or thisimage) that is used for later three-way merge, so it is saner to keep it to always write to FILE *. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2009-12-25rerere: remove silly 1024-byte line limitJunio C Hamano1-9/+10 Ever since 658f365 (Make git-rerere a builtin, 2006-12-20) rewrote it, it kept this line-length limit regression, even after we started using strbuf in the same function in 19b358e (Use strbuf API in buitin-rerere.c, 2007-09-06). Signed-off-by: Junio C Hamano <gitster@pobox.com> 2009-12-25resolve-undo: teach "update-index --unresolve" to use resolve-undo infoJunio C Hamano3-1/+20 The update-index plumbing command had a hacky --unresolve implementation that was written back in the days when merge was the only way for users to end up with higher stages in the index, and assumed that stage #2 must have come from HEAD, stage #3 from MERGE_HEAD and didn't bother to compute the stage #1 information. There were several issues with this approach: - These days, merge is not the only command, and conflicts coming from commands like cherry-pick, "am -3", etc. cannot be recreated by looking at MERGE_HEAD; - For a conflict that came from a merge that had renames, picking up the same path from MERGE_HEAD and HEAD wouldn't help recreating it, either; - It may have been Ok not to recreate stage #1 back when it was written, because "diff --ours/--theirs" were the only availble ways to review conflicts and they don't need stage #1 information. "diff --cc" that was invented much later is a lot more useful way but it needs stage #1. We can use resolve-undo information recorded in the index extension to solve all of these issues. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2009-12-25resolve-undo: "checkout -m path" uses resolve-undo informationJunio C Hamano5-0/+77 Once you resolved conflicts by "git add path", you cannot recreate the conflicted state with "git checkout -m path", because you lost information from higher stages in the index when you resolved them. Since we record the necessary information in the resolve-undo index extension these days, we can reproduce the unmerged state in the index and check it out. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2009-12-25resolve-undo: allow plumbing to clear the informationJunio C Hamano2-0/+17 At the Porcelain level, operations such as merge that populate an initially cleanly merged index with conflicted entries clear the resolve-undo information upfront. Give scripted Porcelains a way to do the same, by implementing "update-index --clear-resolve-info". With this, a scripted Porcelain may "update-index --clear-resolve-info" first and repeatedly run "update-index --cacheinfo" to stuff unmerged entries to the index, to be resolved by the user with "git add" and stuff. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2009-12-25resolve-undo: basic testsJunio C Hamano2-1/+130 Make sure that resolving a failed merge with git add records the conflicted state, committing the result keeps that state, and checking out another commit clears the state. "git ls-files" learns a new option --resolve-undo to show the recorded information. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2009-12-25resolve-undo: record resolved conflicts in a new index extension sectionJunio C Hamano8-1/+160 When resolving a conflict using "git add" to create a stage #0 entry, or "git rm" to remove entries at higher stages, remove_index_entry_at() function is eventually called to remove unmerged (i.e. higher stage) entries from the index. Introduce a "resolve_undo_info" structure and keep track of the removed cache entries, and save it in a new index extension section in the index_state. Operations like "read-tree -m", "merge", "checkout [-m] <branch>" and "reset" are signs that recorded information in the index is no longer necessary. The data is removed from the index extension when operations start; they may leave conflicted entries in the index, and later user actions like "git add" will record their conflicted states afresh. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2009-12-25builtin-merge.c: use standard active_cache macrosJunio C Hamano1-3/+2 Instead of using the low-level index_state interface, use the bog standard active_cache and active_nr macros to access the cache entries when using the default one. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2009-12-23Git 1.6.6v1.6.6Junio C Hamano3-4/+6 Signed-off-by: Junio C Hamano <gitster@pobox.com>