summaryrefslogtreecommitdiff
path: root/unpack-trees.c
AgeCommit message (Collapse)AuthorFilesLines
2007-08-05unpack-trees.c: assume submodules are clean during check-outLibravatar Junio C Hamano1-0/+9
Sven originally raised this issue: If you have a submodule checked out and you go back (or forward) to a revision of the supermodule that contains a different revision of the submodule and then switch to another revision, it will complain that the submodule is not uptodate, because git simply didn't update the submodule in the first move. The current policy is to consider it is perfectly normal that checked-out submodule is out-of-sync wrt the supermodule index. At least until we introduce a superproject repository configuration option that says "in this repository, I do care about this submodule and at any time I move around in the superproject, recursively check out the submodule to match", it is a reasonable policy, as we currently do not recursively checkout the submodules at all. The most extreme case of this policy is that the superproject index knows about the submodule but the subdirectory does not even have to be checked out. The function verify_uptodate(), called during the two-way merge aka branch switching, is about "make sure the filesystem entity that corresponds to this cache entry is up to date, lest we lose the local modifications". As we explicitly allow submodule checkout to drift from the supermodule index entry, the check should say "Ok, for submodules, not matching is the norm" for now. Later when we have the ability to mark "I care about this submodule to be always in sync with the superproject" (thereby implementing automatic recursive checkout and perhaps diff, among other things), we should check if the submodule in question is marked as such and perform the current test. Acked-by: Lars Hjemli <hjemli@gmail.com> Acked-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-24cleanup unpack-trees.c: shrink struct tree_entry_listLibravatar René Scharfe1-9/+3
Remove the two write-only fields executable and symlink from struct tree_entry_list. Also replace usage of the field directory with S_ISDIR checks on the mode field, and then remove this now obsolete field, too. Noticed by David Kastrup. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-18unpack-trees.c: assume submodules are clean during check-outLibravatar Sven Verdoolaege1-25/+50
In particular, when moving back to a commit without a given submodule and then moving back forward to a commit with the given submodule, we shouldn't complain that updating would lose untracked file in the submodule, because git currently does not checkout subprojects during superproject check-out. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-12Teach read-tree 2-way merge to ignore intermediate symlinksLibravatar Junio C Hamano1-0/+3
Earlier in 16a4c61, we taught "read-tree -m -u" not to be confused when switching from a branch that has a path frotz/filfre to another branch that has a symlink frotz that points at xyzzy/ directory. The fix was incomplete in that it was still confused when coming back (i.e. switching from a branch with frotz -> xyzzy/ to another branch with frotz/filfre). This fix is rather expensive in that for a path that is created we would need to see if any of the leading component of that path exists as a symbolic link in the filesystem (in which case, we know that path itself does not exist, and the fact we already decided to check it out tells us that in the index we already know that symbolic link is going away as there is no D/F conflict). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-20Merge branch 'maint-1.5.1' into maintLibravatar Junio C Hamano1-4/+0
* maint-1.5.1: annotate: make it work from subdirectories. git-config: Correct asciidoc documentation for --int/--bool t1300: Add tests for git-config --bool --get unpack-trees.c: verify_uptodate: remove dead code Use PATH_MAX instead of TEMPFILE_PATH_LEN branch: fix segfault when resolving an invalid HEAD
2007-05-20unpack-trees.c: verify_uptodate: remove dead codeLibravatar Sven Verdoolaege1-4/+0
This code was killed by commit fcc387db9bc453dc7e07a262873481af2ee9e5c8. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-11read-tree -m -u: avoid getting confused by intermediate symlinks.Libravatar Junio C Hamano1-4/+10
When switching from a branch with both x86_64/boot/Makefile and i386/boot/Makefile to another branch that has x86_64/boot as a symlink pointing at ../i386/boot, the code incorrectly removed i386/boot/Makefile. This was because we first removed everything under x86_64/boot to make room to create a symbolic link x86_64/boot, then removed x86_64/boot/Makefile which no longer exists but now is pointing at i386/boot/Makefile, thanks to the symlink we just created. This fixes it by using the has_symlink_leading_path() function introduced previously for git-apply in the checkout codepath. Earlier, "git checkout" was broken in t4122 test due to this bug, and the test had an extra "git reset --hard" as a workaround, which is removed because it is not needed anymore. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-22delay progress display when checking out filesLibravatar Nicolas Pitre1-7/+2
Let's start displaying progress only if more than 50% of total number of files remains to be checked out after 2 seconds. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-22make progress "title" part of the common progress interfaceLibravatar Nicolas Pitre1-4/+3
If the progress bar ends up in a box, better provide a title for it too. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-22common progress display supportLibravatar Nicolas Pitre1-45/+9
Instead of having this code duplicated in multiple places, let's have a common interface for progress display. If someday someone wishes to display a cheezy progress bar instead then only one file will have to be changed. Note: I left merge-recursive.c out since it has a strange notion of progress as it apparently increase the expected total number as it goes. Someone with more intimate knowledge of what that is supposed to mean might look at converting it to the common progress interface. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10Treat D/F conflict entry more carefully in unpack-trees.c::threeway_merge()Libravatar Junio C Hamano1-14/+20
This fixes three buglets in threeway_merge() regarding D/F conflict entries. * After finishing with path D and handling path D/F, some stages have D/F conflict entry which are obviously non-NULL. For the purpose of determining if the path D/F is missing in the ancestor, they should not be taken into account. * D/F conflict entry is a marker to say "this stage does _not_ have the path", so do not send them to keep_entry(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10t1000: fix case table.Libravatar Junio C Hamano1-1/+1
Case #10 is not handled with unpack-trees.c:threeway_merge() internally, unless under the agressive rule, and it is not a bug. As the test expects, ND (one side did not do anything, other side deleted) case was meant to be handled by the caller's policy (e.g. git-merge-one-file or git-merge-recursive). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-04Fix switching to a branch with D/F when current branch has file D.Libravatar Junio C Hamano1-1/+112
This loosens the over-eager verify_absent() check that gets upset to find directory D in the current working tree when switching to a branch that has a file there. The check needs to make sure that we do not lose precious working tree files as a result of removing directory D and replacing it with the file from the other branch, which is a tad expensive but this is a less common case. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-04Fix twoway_merge that passed d/f conflict marker to merged_entry().Libravatar Junio C Hamano1-2/+8
When switching from one tree to another, we should not send a marker that says "this file does not exist in the new tree -- I am a placeholder to tell you that, and not a real blob" down to merged_entry() as the result of the merge.
2007-04-04unpack-trees: get rid of *indpos parameter.Libravatar Junio C Hamano1-9/+7
This variable keeps track of which entry in the original index the traversal is looking at, and belongs to the unpack_trees_options structure along with other traversal status information. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-04unpack_trees.c: pass unpack_trees_options structure to keep_entry() as well.Libravatar Junio C Hamano1-7/+7
Other decision functions, deleted_entry() and merged_entry() take one as their parameter, and this function should. I'll be introducing a separate index to build the result in, and am planning to pass it as the part of the structure. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-21Initialize tree descriptors with a helper function rather than by hand.Libravatar Linus Torvalds1-2/+1
This removes slightly more lines than it adds, but the real reason for doing this is that future optimizations will require more setup of the tree descriptor, and so we want to do it in one place. Also renamed the "desc.buf" field to "desc.buffer" just to trigger compiler errors for old-style manual initializations, making sure I didn't miss anything. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20simplify inclusion of system header files.Libravatar Junio C Hamano1-2/+0
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-13Merge branch 'jc/read-tree-ignore'Libravatar Junio C Hamano1-5/+19
* jc/read-tree-ignore: read-tree: document --exclude-per-directory Loosen "working file will be lost" check in Porcelain-ish read-tree: further loosen "working file will be lost" check.
2006-12-05read-tree: further loosen "working file will be lost" check.Libravatar Junio C Hamano1-5/+19
This follows up commit ed93b449 where we removed overcautious "working file will be lost" check. A new option "--exclude-per-directory=.gitignore" can be used to tell the "git-read-tree" command that the user does not mind losing contents in untracked files in the working tree, if they need to be overwritten by a merge (either a two-way "switch branches" merge, or a three-way merge). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-04unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.Libravatar Junio C Hamano1-3/+5
The structure that ends with a flexible array member (or 0 length array with older GCC) "char name[FLEX_ARRAY]" is allocated on the stack and we use it after clearing its entire size with memset. That does not guarantee that "name" is properly NUL terminated as we intended on platforms with more forgiving structure alignment requirements. Reported breakage on m68k by Roman Zippel. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-27merge: loosen overcautious "working file will be lost" check.Libravatar Junio C Hamano1-3/+1
The three-way merge complained unconditionally when a path that does not exist in the index is involved in a merge when it existed in the working tree. If we are merging an old version that had that path tracked, but the path is not tracked anymore, and if we are merging that old version in, the result will be that the path is not tracked. In that case we should not complain. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23Convert memcpy(a,b,20) to hashcpy(a,b).Libravatar Shawn Pearce1-1/+1
This abstracts away the size of the hash values when copying them from memory location to memory location, much as the introduction of hashcmp abstracted away hash value comparsion. A few call sites were using char* rather than unsigned char* so I added the cast rather than open hashcpy to be void*. This is a reasonable tradeoff as most call sites already use unsigned char* and the existing hashcmp is also declared to be unsigned char*. [jc: Splitted the patch to "master" part, to be followed by a patch for merge-recursive.c which is not in "master" yet. Fixed the cast in the latter hunk to combine-diff.c which was wrong in the original. Also converted ones left-over in combine-diff.c, diff-lib.c and upload-pack.c ] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-17Do not use memcmp(sha1_1, sha1_2, 20) with hardcoded length.Libravatar David Rientjes1-1/+1
Introduces global inline: hashcmp(const unsigned char *sha1, const unsigned char *sha2) Uses memcmp for comparison and returns the result based on the length of the hash name (a future runtime decision). Acked-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15remove unnecessary initializationsLibravatar David Rientjes1-1/+1
[jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15use appropriate typedefsLibravatar David Rientjes1-1/+1
Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-30read-tree: move merge functions to the libraryLibravatar Johannes Schindelin1-0/+404
This will allow merge-recursive to use the read-tree functionality without exec()ing git-read-tree. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-30read-trees: refactor the unpack_trees() partLibravatar Johannes Schindelin1-0/+395
Basically, the options are passed by a struct unpack_trees_options now. That's all. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>