path: root/unpack-trees.h
AgeCommit message (Collapse)Author
2020-04-29Merge branch 'en/sparse-checkout'Junio C Hamano
"sparse-checkout" UI improvements. * en/sparse-checkout: sparse-checkout: provide a new reapply subcommand unpack-trees: failure to set SKIP_WORKTREE bits always just a warning unpack-trees: provide warnings on sparse updates for unmerged paths too unpack-trees: make sparse path messages sound like warnings unpack-trees: split display_error_msgs() into two unpack-trees: rename ERROR_* fields meant for warnings to WARNING_* unpack-trees: move ERROR_WOULD_LOSE_SUBMODULE earlier sparse-checkout: use improved unpack_trees porcelain messages sparse-checkout: use new update_sparsity() function unpack-trees: add a new update_sparsity() function unpack-trees: pull sparse-checkout pattern reading into a new function unpack-trees: do not mark a dirty path with SKIP_WORKTREE unpack-trees: allow check_updates() to work on a different index t1091: make some tests a little more defensive against failures unpack-trees: simplify pattern_list freeing unpack-trees: simplify verify_absent_sparse() unpack-trees: remove unused error type unpack-trees: fix minor typo in comment
2020-03-27unpack-trees: provide warnings on sparse updates for unmerged paths tooElijah Newren
When sparse-checkout runs to update the list of sparsity patterns, it gives warnings if it can't remove paths from the working tree because those files have dirty changes. Add a similar warning for unmerged paths as well. Reviewed-by: Derrick Stolee <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2020-03-27unpack-trees: split display_error_msgs() into twoElijah Newren
display_error_msgs() is never called to show messages of both ERROR_* and WARNING_* types at the same time; it is instead called multiple times, separately for each type. Since we want to display these types differently, make two slightly different versions of this function. A subsequent commit will further modify unpack_trees() and how it calls the new display_warning_msgs(). Reviewed-by: Derrick Stolee <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2020-03-27unpack-trees: rename ERROR_* fields meant for warnings to WARNING_*Elijah Newren
We want to treat issues with setting the SKIP_WORKTREE bit as a warning rather than an error; rename the enum values to reflect this intent as a simple step towards that goal. Reviewed-by: Derrick Stolee <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2020-03-27unpack-trees: move ERROR_WOULD_LOSE_SUBMODULE earlierElijah Newren
A minor change, but we want to convert the sparse messages to warnings and this allows us to group warnings and errors. Reviewed-by: Derrick Stolee <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2020-03-27unpack-trees: add a new update_sparsity() functionElijah Newren
Previously, the only way to update the SKIP_WORKTREE bits for various paths was invoking `git read-tree -mu HEAD` or calling the same code that this codepath invoked. This however had a number of problems if the index or working directory were not clean. First, let's consider the case: Flipping SKIP_WORKTREE -> !SKIP_WORKTREE (materializing files) If the working tree was clean this was fine, but if there were files or directories or symlinks or whatever already present at the given path then the operation would abort with an error. Let's label this case for later discussion: A) There is an untracked path in the way Now let's consider the opposite case: Flipping !SKIP_WORKTREE -> SKIP_WORKTREE (removing files) If the index and working tree was clean this was fine, but if there were any unclean paths we would run into problems. There are three different cases to consider: B) The path is unmerged C) The path has unstaged changes D) The path has staged changes (differs from HEAD) If any path fell into case B or C, then the whole operation would be aborted with an error. With sparse-checkout, the whole operation would be aborted for case D as well, but for its predecessor of using `git read-tree -mu HEAD` directly, any paths that fell into case D would be removed from the working copy and the index entry for that path would be reset to match HEAD -- which looks and feels like data loss to users (only a few are even aware to ask whether it can be recovered, and even then it requires walking through loose objects trying to match up the right ones). Refusing to remove files that have unsaved user changes is good, but refusing to work on any other paths is very problematic for users. If the user is in the middle of a rebase or has made modifications to files that bring in more dependencies, then for their build to work they need to update the sparse paths. This logic has been preventing them from doing so. Sometimes in response, the user will stage the files and re-try, to no avail with sparse-checkout or to the horror of losing their changes if they are using its predecessor of `git read-tree -mu HEAD`. Add a new update_sparsity() function which will not error out in any of these cases but behaves as follows for the special cases: A) Leave the file in the working copy alone, clear the SKIP_WORKTREE bit, and print a warning (thus leaving the path in a state where status will report the file as modified, which seems logical). B) Do NOT mark this path as SKIP_WORKTREE, and leave it as unmerged. C) Do NOT mark this path as SKIP_WORKTREE and print a warning about the dirty path. D) Mark the path as SKIP_WORKTREE, but do not revert the version stored in the index to match HEAD; leave the contents alone. I tried a different behavior for A (leave the SKIP_WORKTREE bit set), but found it very surprising and counter-intuitive (e.g. the user sees it is present along with all the other files in that directory, tries to stage it, but git add ignores it since the SKIP_WORKTREE bit is set). A & C seem like optimal behavior to me. B may be as well, though I wonder if printing a warning would be an improvement. Some might be slightly surprised by D at first, but given that it does the right thing with `git commit` and even `git commit -a` (`git add` ignores entries that are marked SKIP_WORKTREE and thus doesn't delete them, and `commit -a` is similar), it seems logical to me. Reviewed-by: Derrick Stolee <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2020-03-27unpack-trees: simplify pattern_list freeingElijah Newren
commit e091228e17 ("sparse-checkout: update working directory in-process", 2019-11-21) allowed passing a pre-defined set of patterns to unpack_trees(). However, if o->pl was NULL, it would still read the existing patterns and use those. If those patterns were read into a data structure that was allocated, naturally they needed to be free'd. However, despite the same function being responsible for knowing about both the allocation and the free'ing, the logic for tracking whether to free the pattern_list was hoisted to an outer function with an additional flag in unpack_trees_options. Put the logic back in the relevant function and discard the now unnecessary flag. Reviewed-by: Derrick Stolee <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2020-03-27unpack-trees: remove unused error typeElijah Newren
commit 08402b0409 ("merge-recursive: distinguish "removed" and "overwritten" messages", 2010-08-11) split ERROR_WOULD_LOSE_UNTRACKED into both ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN ERROR_WOULD_LOSE_UNTRACKED_REMOVED and also split ERROR_WOULD_LOSE_ORPHANED into both ERROR_WOULD_LOSE_ORPHANED_OVERWRITTEN ERROR_WOULD_LOSE_ORPHANED_REMOVED However, despite the split only three of these four types were used. ERROR_WOULD_LOSE_ORPHANED_REMOVED was not put into use when it was introduced and nothing else has used it in the intervening decade either. Remove it. Reviewed-by: Derrick Stolee <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2020-03-16builtin/checkout: compute checkout metadata for checkoutsbrian m. carlson
Provide commit metadata for checkout code paths that use unpack_trees and friends. When we're checking out a commit, use the commit information, but don't provide commit information if we're checking out from the index, since there need not be any particular commit associated with the index, and even if there is one, we can't know what it is. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2020-02-04tree-walk.c: break circular dependency with unpack-treesJeff King
The unpack-trees API depends on the tree-walk API. But we've recently introduced a dependency in tree-walk.c on MAX_UNPACK_TREES, which doesn't otherwise care about unpack-trees at all. Let's break that dependency by reversing the constants: we'll introduce a new MAX_TRAVERSE_TREES which belongs to the tree-walk API. And then we can define MAX_UNPACK_TREES in terms of that (since unpack-trees cannot possibly work with more trees than it can traverse at once via tree-walk). The value for both will remain at 8. This is somewhat arbitrary and probably more than is necessary, per ca885a4fe6 (read-tree() and unpack_trees(): use consistent limit, 2008-03-13), but there's not really any pressing need to reduce it. Suggested-by: Elijah Newren <> Signed-off-by: Jeff King <> Acked-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2019-11-22sparse-checkout: update working directory in-processDerrick Stolee
The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the skip-worktree bits in the index and to update the working directory. This extra process is overly complex, and prone to failure. It also requires that we write our changes to the sparse-checkout file before trying to update the index. Remove this extra process call by creating a direct call to unpack_trees() in the same way 'git read-tree -mu HEAD' does. In addition, provide an in-memory list of patterns so we can avoid reading from the sparse-checkout file. This allows us to test a proposed change to the file before writing to it. An earlier version of this patch included a bug when the 'set' command failed due to the "Sparse checkout leaves no entry on working directory" error. It would not rollback the index.lock file, so the replay of the old sparse-checkout specification would fail. A test in t1091 now covers that scenario. Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
2019-09-05treewide: rename 'struct exclude_list' to 'struct pattern_list'Derrick Stolee
The first consumer of pattern-matching filenames was the .gitignore feature. In that context, storing a list of patterns as a 'struct exclude_list' makes sense. However, the sparse-checkout feature then adopted these structures and methods, but with the opposite meaning: these patterns match the files that should be included! It would be clearer to rename this entire library as a "pattern matching" library, and the callers apply exclusion/inclusion logic accordingly based on their needs. This commit renames 'struct exclude_list' to 'struct pattern_list' and renames several variables called 'el' to 'pl'. Signed-off-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
2019-03-24unpack-trees: rename "gently" flag to "quiet"Nguyễn Thái Ngọc Duy
The gently flag was added in 17e4642667 (Add flag to make unpack_trees() not print errors. - 2008-02-07) to suppress error messages. The name "gently" does not quite express that. Granted, being quiet is gentle but it could mean not performing some other actions. Rename the flag to "quiet" to be more on point. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-09-17Merge branch 'nd/clone-case-smashing-warning'Junio C Hamano
Running "git clone" against a project that contain two files with pathnames that differ only in cases on a case insensitive filesystem would result in one of the files lost because the underlying filesystem is incapable of holding both at the same time. An attempt is made to detect such a case and warn. * nd/clone-case-smashing-warning: clone: report duplicate entries on case-insensitive filesystems
2018-08-20Merge branch 'en/incl-forward-decl'Junio C Hamano
Code hygiene improvement for the header files. * en/incl-forward-decl: Remove forward declaration of an enum compat/precompose_utf8.h: use more common include guard style urlmatch.h: fix include guard Move definition of enum branch_track from cache.h to branch.h alloc: make allocate_alloc_state and clear_alloc_state more consistent Add missing includes and forward declarations
2018-08-17clone: report duplicate entries on case-insensitive filesystemsDuy Nguyen
Paths that only differ in case work fine in a case-sensitive filesystems, but if those repos are cloned in a case-insensitive one, you'll get problems. The first thing to notice is "git status" will never be clean with no indication what exactly is "dirty". This patch helps the situation a bit by pointing out the problem at clone time. Even though this patch talks about case sensitivity, the patch makes no assumption about folding rules by the filesystem. It simply observes that if an entry has been already checked out at clone time when we're about to write a new path, some folding rules are behind this. In the case that we can't rely on filesystem (via inode number) to do this check, fall back to fspathcmp() which is not perfect but should not give false positives. This patch is tested with vim-colorschemes and Sublime-Gitignore repositories on a JFS partition with case insensitive support on Linux. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-08-15Add missing includes and forward declarationsElijah Newren
I looped over the toplevel header files, creating a temporary two-line C program for each consisting of #include "git-compat-util.h" #include $HEADER This patch is the result of manually fixing errors in compiling those tiny programs. Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2018-08-13unpack-trees: remove 'extern' on function declarationNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2018-05-22unpack_trees_options: free messages when doneMartin Ågren
The strings allocated in `setup_unpack_trees_porcelain()` are never freed. Provide a function `clear_unpack_trees_porcelain()` to do so and call it where we use `setup_unpack_trees_porcelain()`. The only non-trivial user is `unpack_trees_start()`, where we should place the new call in `unpack_trees_finish()`. We keep the string pointers in an array, mixing pointers to static memory and memory that we allocate on the heap. We also keep several copies of the individual pointers. So we need to make sure that we do not free what we must not free and that we do not double-free. Let a separate argv_array take ownership of all the strings we create so that we can easily free them. Zero the whole array of string pointers to make sure that we do not leave any dangling pointers. Note that we only take responsibility for the memory allocated in `setup_unpack_trees_porcelain()` and not any other members of the `struct unpack_trees_options`. Helped-by: Junio C Hamano <> Signed-off-by: Junio C Hamano <> Signed-off-by: Martin Ågren <> Signed-off-by: Junio C Hamano <>
2018-05-08merge-recursive: fix overwriting dirty files involved in renamesElijah Newren
This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a subsequent commit. Reviewed-by: Stefan Beller <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2018-04-11Revert "Merge branch 'en/rename-directory-detection'"Junio C Hamano
This reverts commit e4bb62fa1eeee689744b413e29a50b4d1dae6886, reversing changes made to 468165c1d8a442994a825f3684528361727cd8c0. The topic appears to inflict severe regression in renaming merges, even though the promise of it was that it would improve them. We do not yet know which exact change in the topic was wrong, but in the meantime, let's play it safe and revert it out of 'master' before real Git-using projects are harmed. Signed-off-by: Junio C Hamano <>
2018-02-27merge-recursive: fix overwriting dirty files involved in renamesElijah Newren
This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a subsequent commit. Reviewed-by: Stefan Beller <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2017-03-16unpack-trees: check if we can perform the operation for submodulesStefan Beller
In a later patch we'll support submodule entries to be in sync with the tree in working tree changing commands, such as checkout or read-tree. When a new submodule entry changes in the tree, we need to check if there are conflicts (directory/file conflicts) for the tree. Add this check for submodules to be performed before the working tree is touched. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2013-06-02diff-lib, read-tree, unpack-trees: mark cache_entry array paramters constRené Scharfe
Change the type merge_fn_t to accept the array of cache_entry pointers as const pointers to const pointers. This documents the fact that the merge functions don't modify the cache_entry contents or replace any of the pointers in the array. Only a single cast is necessary in unpack_nondirectories because adding two const modifiers at once is not allowed in C. The cast is safe in that it doesn't mask any modfication; call_unpack_fn only needs the array for reading. Signed-off-by: René Scharfe <> Signed-off-by: Junio C Hamano <>
2013-04-15dir.c: replace is_path_excluded with now equivalent is_excluded APIKarsten Blees
Signed-off-by: Karsten Blees <> Signed-off-by: Junio C Hamano <>
2012-06-06unpack-trees.c: use path_excluded() in check_ok_to_remove()Junio C Hamano
This function is responsible for determining if a path that is not tracked is ignored and allow "checkout" to overwrite it as needed. It used excluded() without checking if higher level directory in the path is ignored; correct it to use path_excluded() for this check. Signed-off-by: Junio C Hamano <> --- * There are uses of lower-level interface excluded_from_list() in the codepath for narrow-checkout hack; they are supposed to be already checking each level as they descend, and are not touched with this patch.
2011-10-05Merge branch 'jc/diff-index-unpack'Junio C Hamano
* jc/diff-index-unpack: diff-index: pass pathspec down to unpack-trees machinery unpack-trees: allow pruning with pathspec traverse_trees(): allow pruning with pathspec
2011-08-29unpack-trees: allow pruning with pathspecJunio C Hamano
Use the pathspec pruning of traverse_trees() from unpack_trees(). Again, the unpack_trees() machinery is primarily meant for merging two (or more) trees, and because a merge is a full tree operation, it didn't support any pruning with pathspec, and this codepath probably should not be enabled while running a merge, but the caller in diff-lib.c::diff_cache() should be able to take advantage of it. Signed-off-by: Junio C Hamano <>
2011-06-30Merge branch 'jc/diff-index-quick-exit-early'Junio C Hamano
* jc/diff-index-quick-exit-early: diff-index --quiet: learn the "stop feeding the backend early" logic Conflicts: unpack-trees.h
2011-05-31diff-index --quiet: learn the "stop feeding the backend early" logicJunio C Hamano
A negative return from the unpack callback function usually means unpack failed for the entry and signals the unpack_trees() machinery to fail the entire merge operation, immediately and there is no other way for the callback to tell the machinery to exit early without reporting an error. This is what we usually want to make a merge all-or-nothing operation, but the machinery is also used for diff-index codepath by using a custom unpack callback function. And we do sometimes want to exit early without failing, namely when we are under --quiet and can short-cut the diff upon finding the first difference. Add "exiting_early" field to unpack_trees_options structure, to signal the unpack_trees() machinery that the negative return value is not signaling an error but an early return from the unpack_trees() machinery. As this by definition hasn't unpacked everything, discard the resulting index just like the failure codepath. Signed-off-by: Junio C Hamano <>
2011-05-25unpack-trees: add the dry_run flag to unpack_trees_optionsJens Lehmann
Until now there was no way to test if unpack_trees() with update=1 would succeed without really updating the work tree. The reason for that is that setting update to 0 does skip the tests for new files and deactivates the sparse handling, thereby making that unsuitable as a dry run. Add the new dry_run flag to struct unpack_trees_options unpack_trees(). Setting that together with the update flag will check if the work tree update would be successful without doing it for real. The only class of problems that is not detected at the moment are file system conditions like ENOSPC or missing permissions. Also the index entries of updated files are not as they would be after a real checkout because lstat() isn't run as the files aren't updated for real. Signed-off-by: Jens Lehmann <> Signed-off-by: Junio C Hamano <>
2010-11-15use persistent memory for rejected pathsClemens Buchacher
An aborted merge prints the list of rejected paths as part of the error message. Since commit f66caaf9 (do not overwrite files in leading path), some of those paths do not have static buffers, so we have to keep a copy. Use string_list's to accomplish this. This changes the order of the list to the order in which the paths are processed. Previously, it was reversed. Signed-off-by: Clemens Buchacher <> Signed-off-by: Junio C Hamano <>
2010-09-03Move "show_all_errors = 1" to setup_unpack_trees_porcelain()Matthieu Moy
Not only this makes the code clearer since setting up the porcelain error message is meant to work with show_all_errors, but this fixes a call to setup_unpack_trees_porcelain() in git_merge_trees() which did not set show_all_errors. add_rejected_path() used to double-check whether it was running in plumbing mode. This check was ineffective since it was setting show_all_errors too late for traverse_trees() to see it, and is made useless by this patch. Remove it. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-09-03setup_unpack_trees_porcelain: take the whole options struct as parameterMatthieu Moy
This is a preparation patch to let setup_unpack_trees_porcelain set show_all_errors itself. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-09-03Move set_porcelain_error_msgs to unpack-trees.c and rename itMatthieu Moy
The function is currently dealing only with error messages, but the intent of calling it is really to notify the unpack-tree mechanics that it is running in porcelain mode. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-08-11unpack_trees: group error messages by typeMatthieu Moy
When an error is encountered, it calls add_rejected_file() which either - directly displays the error message and stops if in plumbing mode (i.e. if show_all_errors is not initialized at 1) - or stores it so that it will be displayed at the end with display_error_msgs(), Storing the files by error type permits to have a list of files for which there is the same error instead of having a serie of almost identical errors. As each bind_overlap error combines a file and an old file, a list cannot be done, therefore, theses errors are not stored but directly displayed. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-08-11merge-recursive: distinguish "removed" and "overwritten" messagesMatthieu Moy
To limit the number of possible error messages, the error messages for the case would_lose_untracked_file and would_lose_orphaned in unpack_trees_options.msgs were handled with a single string, parameterized by an action string ("overwritten" or "removed"). Instead, we consider them as two different cases, with unparameterized string. This will make it easier to make separate lists sorted by error types later. Only the bind_overlap case still takes two %s parameters, but that's unavoidable. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-08-11Turn unpack_trees_options.msgs into an array + enumMatthieu Moy
The list of error messages was introduced as a structure, but an array indexed over an enum is more flexible, since it allows one to store a type of error message (index in the array) in a variable. This change needs to rename would_lose_untracked -> would_lose_untracked_file to avoid a clash with the function would_lose_untracked in merge-recursive.c. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-01-25Merge branch 'jc/fix-tree-walk'Junio C Hamano
* jc/fix-tree-walk: read-tree --debug-unpack unpack-trees.c: look ahead in the index unpack-trees.c: prepare for looking ahead in the index Aggressive three-way merge: fix D/F case traverse_trees(): handle D/F conflict case sanely more D/F conflict tests tests: move convenience regexp to match object names to Conflicts: builtin-read-tree.c unpack-trees.c unpack-trees.h
2010-01-07read-tree --debug-unpackJunio C Hamano
A debugging patch. Signed-off-by: Junio C Hamano <>
2010-01-07unpack-trees.c: prepare for looking ahead in the indexJunio C Hamano
This prepares but does not yet implement a look-ahead in the index entries when traverse-trees.c decides to give us tree entries in an order that does not match what is in the index. A case where a look-ahead in the index is necessary happens when merging branch B into branch A while the index matches the current branch A, using a tree O as their common ancestor, and these three trees looks like this: O A B t t t-i t-i t-i t-j t-j t/1 t/2 The traverse_trees() function gets "t", "t-i" and "t" from trees O, A and B first, and notices that A may have a matching "t" behind "t-i" and "t-j" (indeed it does), and tells A to give that entry instead. After unpacking blob "t" from tree B (as it hasn't changed since O in B and A removed it, it will result in its removal), it descends into directory "t/". The side that walked index in parallel to the tree traversal used to be implemented with one pointer, o->pos, that points at the next index entry to be processed. When this happens, the pointer o->pos still points at "t-i" that is the first entry. We should be able to skip "t-i" and "t-j" and locate "t/1" from the index while the recursive invocation of traverse_trees() walks and match entries found there, and later come back to process "t-i". While that look-ahead is not implemented yet, this adds a flag bit, CE_UNPACKED, to mark the entries in the index that has already been processed. o->pos pointer has been renamed to o->cache_bottom and it points at the first entry that may still need to be processed. Signed-off-by: Junio C Hamano <>
2009-08-24unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final indexNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2009-08-24unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkoutNguyễn Thái Ngọc Duy
This patch introduces core.sparseCheckout, which will control whether sparse checkout support is enabled in unpack_trees() It also loads sparse-checkout file that will be used in the next patch. I split it out so the next patch will be shorter, easier to read. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2009-06-27read-tree: migrate to parse-optionsStephen Boyd
Cleanup the documentation to explicitly state that --exclude-directory is only meaningful when used with -u. Also make the documentation more consistent with the usage message printed with read-tree --help-all. The -m, --prefix, --reset options are performing similar actions (setting some flags, read_cache_unmerged(), checking for illegal option combinations). Instead of performing these actions when the options are parsed, we delay performing them until after parse-opts has finished. The bit fields in struct unpack_trees_options have been promoted to full unsigned ints. This is necessary to avoid "foo ? 1 : 0" constructs to set these fields. Signed-off-by: Stephen Boyd <> Signed-off-by: Junio C Hamano <>
2009-05-25Optimize "diff-index --cached" using cache-treeJunio C Hamano
When running "diff-index --cached" after making a change to only a small portion of the index, there is no point unpacking unchanged subtrees into the index recursively, only to find that all entries match anyway. Tweak unpack_trees() logic that is used to read in the tree object to catch the case where the tree entry we are looking at matches the index as a whole by looking at the cache-tree. As an exercise, after modifying a few paths in the kernel tree, here are a few numbers on my Athlon 64X2 3800+: (without patch, hot cache) $ /usr/bin/time git diff --cached --raw :100644 100644 b57e1f5... e69de29... M Makefile :100644 000000 8c86b72... 0000000... D arch/x86/Makefile :000000 100644 0000000... e69de29... A arche 0.07user 0.02system 0:00.09elapsed 102%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+9407minor)pagefaults 0swaps (with patch, hot cache) $ /usr/bin/time ../git.git/git-diff --cached --raw :100644 100644 b57e1f5... e69de29... M Makefile :100644 000000 8c86b72... 0000000... D arch/x86/Makefile :000000 100644 0000000... e69de29... A arche 0.02user 0.00system 0:00.02elapsed 103%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+2446minor)pagefaults 0swaps Cold cache numbers are very impressive, but it does not matter very much in practice: (without patch, cold cache) $ su root sh -c 'echo 3 >/proc/sys/vm/drop_caches' $ /usr/bin/time git diff --cached --raw :100644 100644 b57e1f5... e69de29... M Makefile :100644 000000 8c86b72... 0000000... D arch/x86/Makefile :000000 100644 0000000... e69de29... A arche 0.06user 0.17system 0:10.26elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k 247032inputs+0outputs (1172major+8237minor)pagefaults 0swaps (with patch, cold cache) $ su root sh -c 'echo 3 >/proc/sys/vm/drop_caches' $ /usr/bin/time ../git.git/git-diff --cached --raw :100644 100644 b57e1f5... e69de29... M Makefile :100644 000000 8c86b72... 0000000... D arch/x86/Makefile :000000 100644 0000000... e69de29... A arche 0.02user 0.01system 0:01.01elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k 18440inputs+0outputs (79major+2369minor)pagefaults 0swaps This of course helps "git status" as well. (without patch, hot cache) $ /usr/bin/time ../git.git/git-status >/dev/null 0.17user 0.18system 0:00.35elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+5336outputs (0major+10970minor)pagefaults 0swaps (with patch, hot cache) $ /usr/bin/time ../git.git/git-status >/dev/null 0.10user 0.16system 0:00.27elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+5336outputs (0major+3921minor)pagefaults 0swaps Signed-off-by: Junio C Hamano <>
2008-09-10checkout: do not lose staged removalJunio C Hamano
The logic to checkout a different commit implements the safety to never lose user's local changes. For example, switching from a commit to another commit, when you have changed a path that is different between them, need to merge your changes to the version from the switched-to commit, which you may not necessarily be able to resolve easily. By default, "git checkout" refused to switch branches, to give you a chance to stash your local changes (or use "-m" to merge, accepting the risks of getting conflicts). This safety, however, had one deliberate hole since early June 2005. When your local change was to remove a path (and optionally to stage that removal), the command checked out the path from the switched-to commit nevertheless. This was to allow an initial checkout to happen smoothly (e.g. an initial checkout is done by starting with an empty index and switching from the commit at the HEAD to the same commit). We can tighten the rule slightly to allow this special case to pass, without losing sight of removal explicitly done by the user, by noticing if the index is truly empty when the operation begins. For historical background, see: This case is marked as *0* in the message, which both Linus and I said "it feels somewhat wrong but otherwise we cannot start from an empty index". Signed-off-by: Junio C Hamano <>
2008-05-20unpack-trees: allow Porcelain to give different error messagesJunio C Hamano
The plumbing output is sacred as it is an API. We _could_ change it if it is broken in such a way that it cannot convey necessary information fully, but we just do not _reword_ for the sake of rewording. If somebody does not like it, s/he is complaining too late. S/he should have been here in early May 2005 and make the language used by the API closer to what humans read. S/he wasn't here. Too bad, and it is too late. And people who complain should look at a bigger picture. Look at what was suggested by one of them and think for five seconds: $ git checkout mytopic -fatal: Entry 'frotz' not uptodate. Cannot merge. +fatal: Entry 'frotz' has local changes. Cannot merge. If you do not see something wrong with this output, your brain has already been rotten with use of git for too long a time. Nobody asked us to "merge" but why are we talking about "Cannot merge"? This patch introduces a mechanism to allow Porcelains to specify messages that are different from the ones that is given by the underlying plumbing implementation of read-tree, so that we can reword the message Porcelains give without disrupting the output from the plumbing. $ git-checkout pu error: You have local changes to 'Makefile'; cannot switch branches. There are other places that ask unpack_trees() to n-way merge, detect issues and let it issue error message on its own, but I did this as a demonstration and replaced only one message. Yes I know about C99 structure initializers. I'd love to use them but we try to be nice to compilers without it. Signed-off-by: Junio C Hamano <>
2008-04-09Make branch merging aware of underlying case-insensitive filsystemsLinus Torvalds
If we find an unexpected file, see if that filename perhaps exists in a case-insensitive way in the index, and whether the file matches that. If so, ignore it as a known pre-existing file of a different name. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2008-04-09Make unpack_trees_options bit flags actual bitfieldsLinus Torvalds
Instead of wasting space with whole integers for a single bit. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2008-03-14read-tree() and unpack_trees(): use consistent limitJunio C Hamano
read-tree -m can read up to MAX_TREES, which was arbitrarily set to 8 since August 2007 (4 is needed to deal with 2 merge-base case). However, the updated unpack_trees() code had an advertised limit of 4 (which it enforced). In reality the code was prepared to take only 3 trees and giving 4 caused it to stomp on its stack. Rename the MAX_TREES constant to MAX_UNPACK_TREES, move it to the unpack-trees.h common header file, and use it from both places to avoid future confusion. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>