summaryrefslogtreecommitdiff
path: root/read-tree.c
AgeCommit message (Collapse)AuthorFilesLines
2005-07-29[PATCH] Unify usage strings declarationLibravatar Petr Baudis1-1/+1
All usage strings are now declared as static const char []. This is carried over from my old git-pb branch. Signed-off-by: Petr Baudis <pasky@ucw.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-14Start adding interfaces to read in partial treesLibravatar Linus Torvalds1-1/+1
The same way "git-diff-tree" can limit its output to just a set of matches, we can read in just a partial tree for comparison purposes.
2005-06-15git-read-tree: fix "--reset" handlingLibravatar Linus Torvalds1-0/+1
2005-06-12[PATCH] read-tree: loosen too strict index requirementsLibravatar Junio C Hamano1-0/+6
This patch teaches read-tree 3-way merge that, when only "the other tree" changed a path, and if the index file already has the same change, we are not in a situation that would clobber the index and the work tree, and lets the merge succeed; this is case #14ALT in t1000 test. It does not change the result of the merge, but prevents it from failing when it does not have to. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] Finish making --emu23 equivalent to pure 2-way merge.Libravatar Junio C Hamano1-5/+132
This adds #3ALT rule (and #2ALT rule for symmetry) to the read-tree 3-way merge logic that collapses paths that are added only in one branch and not in the other internally. This makes --emu23 to succeed in the last remaining case where the pure 2-way merge succeeded and earlier one failed. Running diff between t1001 and t1005 test scripts shows that the only difference between the two is that --emu23 can leave the states into separate stages so that the user can use usual 3-way merge resolution techniques to carry forward the local changes when pure 2-way merge would have refused to run. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] read-tree: fix too strong index requirement #5ALTLibravatar Junio C Hamano1-2/+18
This fixes too strong index requirement 3-way merge enforces in one case: the same file is added in both branches. In this case, the original code insisted that if the index file has that path, it must match our branch and be up-to-date. However in this particular case, it only has to match it, and can be dirty. We just need to make sure that we keep the work-tree copy instead of checking out the merge result. The resolution of such a path, however, cannot be left to outside script, because we will not keep the original stage0 entries for unmerged paths when read-tree finishes, and at that point, the knowledge of "if we resolve it to match the new file added in both branches, the merge succeeds and the work tree would not lose information, but we should _not_ update the work tree from the resulting index file" is lost. For this reason, the now code needs to resolve this case (#5ALT) internally. This affects some existing tests in the test suite, but all in positive ways. In t1000 (3-way test), this #5ALT case now gets one stage0 entry, instead of an identical stage2 and stage3 entry pair, for such a path, and one test that checked for merge failure (because the test assumed the "stricter-than-necessary" behaviour) does not have to fail anymore. In t1005 (emu23 test), two tests that involves a case where the work tree already had a change introduced in the upstream (aka "merged head"), the merge succeeds instead of failing. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12[PATCH] read-tree --emu23.Libravatar Junio C Hamano1-4/+77
This new flag causes two-way fast forward to internally use the three-way merge mechanism. This behaviour is intended to offer a better fast forward semantics when used in a dirty work tree. The new test t1005 is parallel to the existing t1001 "pure 2-way" tests, but some parts that are commented out would fail. These failures are due to three-way merge enforcing too strict index requirements for cases that could succeed. This problem will be addressed by later patches. Without even changing three-way mechanism, the --emu23 two-way fast forward already gives the user an easier-to-handle merge result when a file that "merged head" updates has local modifications. This is demonstrated as "case 16" test in t1005. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-09git-read-tree: remove deleted files in the working directoryLibravatar Linus Torvalds1-6/+18
Only when "-u" is used of course.
2005-06-09git-read-tree: add "--reset" flagLibravatar Linus Torvalds1-9/+38
This is the same as "-m", but it will silently ignore any unmerged entries, which makes it useful for efficiently forcing a new position regardless of the state of the current index file. IOW, to reset to a previous HEAD (in case you have had a failed merge, for example), you'd just do git-read-tree -u --reset HEAD which will also update your working tree to the right state. NOTE! The "update" will not remove files that may have been added by the merge. Yet.
2005-06-07git-read-tree: -u without -m is meaningless. Don't allow it.Libravatar Linus Torvalds1-1/+3
Also, documetn the "-u" in the usage string.
2005-06-07git-read-tree: make one-way merge also honor the "update" flagLibravatar Linus Torvalds1-5/+5
It didn't set CE_UPDATE before, so "-u" was a no-op.
2005-06-07[PATCH] read-tree: save more user hassles during fast-forward.Libravatar Junio C Hamano1-13/+36
This implements the "never lose the current cache information or the work tree state, but favor a successful merge over merge failure" principle in the fast-forward two-tree merge operation. It comes with a set of tests to cover all the cases described in the case matrix found in the new documentation. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-06git-read-tree: some "final" cleanupsLibravatar Linus Torvalds1-14/+10
Looking good, but hey, it's not like I even have a real testcase for any of this. But unlike the mess that this was yerstday, today read-cache is pretty readable and understandable. Which is always a good sign.
2005-06-06git-read-tree: simplify merge loops enormouslyLibravatar Linus Torvalds1-163/+110
Stop trying to haev this stateful thing that keeps track of what it has seen, and use a much simpler "gather all the different stages with the same name together and just merge them in one go" approach. Makes it a lot more understandable, and allows the different merge algorithms to share the basic merge loop.
2005-06-06[PATCH] index locking like everybody elseLibravatar Junio C Hamano1-17/+5
This patch teaches read-tree how to use the index file locking helpers the same way "checkout-cache -u" and "update-cache" do. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-05Fix off-by-one in new three-way-merge updatesLibravatar Linus Torvalds1-1/+1
That's the final one ("Yeah, sure, we believe you"). Anyway, at least the tests pass, which is not saying a lot, since they don't end up testing all the new the things that the new merge world order tries to do. But hopefully we're now at least not any worse off than we were before the rewrite.
2005-06-05Three-way merge: fix silly bug that made trivial merges not workLibravatar Linus Torvalds1-2/+2
Making the main loop look more like the one- and two-way cases introduced a bug where "src" had been updated early, but later users hadn't been adjusted to match.
2005-06-05git-read-tree: fix up two-way mergeLibravatar Linus Torvalds1-15/+44
This is starting to look better.
2005-06-05More work on merging with git-read-tree..Libravatar Linus Torvalds1-19/+104
Add a "-u" flag to update the tree as a result of a merge. Right now this code is way too anal about things, and fails merges it shouldn't, but let me fix up the different cases and this will allow for much smoother merging even in the presense of dirty data in the working tree.
2005-06-05git-read-tree: fix up three-way merge testsLibravatar Linus Torvalds1-14/+14
When we collapse three entries, we need to check all of the collapsed entries against the old pre-merge state.
2005-06-05git-read-tree: be a lot more careful about merging dirty treesLibravatar Linus Torvalds1-3/+51
We don't want to overwrite state that we haven't committed yet when merging, so it's better to make git-read-tree fail than end up with a merge tree that ends up not having the dirty changes. Update git-resolve-script to fail cleanly when git-read-tree fails.
2005-05-20sparse cleanupLibravatar Linus Torvalds1-1/+1
Fix various things that sparse complains about: - use NULL instead of 0 - make sure we declare everything properly, or mark it static - use proper function declarations ("fn(void)" instead of "fn()") Sparse is always right.
2005-05-19[PATCH] cleanup of in-code namesLibravatar Alexey Nezhdanov1-1/+1
Fixes all in-code names that leaved during "big name change". Signed-off-by: Alexey Nezhdanov <snake@penza-gsm.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-11Fixed a leak in read-treeLibravatar Petr Baudis1-1/+4
unpack_tree() would not free the tree object it has read.
2005-05-01Add "get_sha1()" helper function.Libravatar Linus Torvalds1-1/+1
This allows the programs to use various simplified versions of the SHA1 names, eg just say "HEAD" for the SHA1 pointed to by the .git/HEAD file etc. For example, this commit has been done with git-commit-tree $(git-write-tree) -p HEAD instead of the traditional "$(cat .git/HEAD)" syntax.
2005-04-28[PATCH] Rename and extend read_tree_with_tree_or_commit_sha1Libravatar Junio C Hamano1-1/+1
This patch renames read_tree_with_tree_or_commit_sha1() to read_object_with_reference() and extends it to automatically dereference not just "commit" objects but "tag" objects. With this patch, you can say e.g.: ls-tree $tag read-tree -m $(merge-base $tag $HEAD) $tag $HEAD diff-cache $tag diff-tree $tag $HEAD Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-22Move "read_tree()" to "tree.c" to be used as a generic helper function.Libravatar Linus Torvalds1-63/+3
Next step: make "diff-cache" use it.
2005-04-22Clean up and simplify read-tree a bit.Libravatar Linus Torvalds1-7/+6
This is preparation for moving parts of it into "tree.c" to be used as a library function.
2005-04-21Add support for a "GIT_INDEX_FILE" environment variable.Libravatar Linus Torvalds1-8/+11
We use that to specify alternative index files, which can be useful if you want to (for example) generate a temporary index file to do some specific operation that you don't want to mess with your main one with. It defaults to the regular ".git/index" if it hasn't been specified.
2005-04-20[PATCH] Usage-string fixes.Libravatar Junio C Hamano1-4/+6
Usage string fixes to make maintenance easier (only one instance of a string to update not multiple copies). I've spotted and corrected inconsistent usage text in diff-tree while doing this. Also diff-cache and read-tree usage text have been corrected to match their up-to-date features. Earlier, neither "--cached" form of diff-cache nor "-m single-merge" form of read-tree were described. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-20[PATCH] Teach read-tree about commit objectsLibravatar Junio C Hamano1-10/+24
Updates read-tree to use read_tree_with_tree_or_commit_sha1() function. The command can take either tree or commit IDs with this patch. The change involves a slight modification of how it recurses down the tree. Earlier the caller only supplied SHA1 and the recurser read the object using it, but now it is the caller's responsibility to read the object and give it to the recurser. This matches the way recursive behaviour is done in other tree- related commands. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-19Make "read-tree" know how to do a "1-way merge".Libravatar Linus Torvalds1-5/+39
This one just reads one tree, but picks up any matching stat information from the old index.
2005-04-19Make "read-tree" take the 'stat' information for a merge result from theLibravatar Linus Torvalds1-2/+39
old index state if the result matches. This leaves the stat information in the result tree for any trivial merges, which is just the way we like it.
2005-04-16Be much more liberal about the file mode bits.Libravatar Linus Torvalds1-1/+1
We only really care about the difference between a file being executable or not (by its owner). Everything else we leave for the user umask to decide.
2005-04-16Make 'read-tree' do a few more of the trivial merge cases.Libravatar Linus Torvalds1-17/+53
This cuts down the work for the "real merge" to stuff where people might actually disagree on the algorithm. The trivial cases would seem to be totally independent of any policy.
2005-04-15Make "read-tree" merge the trees it reads by giving them consecutive states.Libravatar Linus Torvalds1-6/+53
Normally you'd use state 0 for the "merged" state, and start out with state 1 being "origin", state 2 being "first tree" and state 3 being "second tree". Once all the index entries are back in state 0, we have a successful merge and can write the result tree back.
2005-04-15Encode a few extra flags per index entry.Libravatar Linus Torvalds1-1/+1
This will allow us to have the same name in different "states" in the index at the same time. Which in turn seems to be a very simple way to merge.
2005-04-15Convert the index file reading/writing to use network byte order.Libravatar Linus Torvalds1-2/+2
This allows using a git tree over NFS with different byte order, and makes it possible to just copy a fully populated repository and have the end result immediately usable (needing just a refresh to update the stat information).
2005-04-13[PATCH] Consolidate the error handlingLibravatar Petr Baudis1-5/+5
Now there is error() for "library" errors and die() for fatal "application" errors. usage() is now used strictly only for usage errors. Signed-off-by: Petr Baudis <pasky@ucw.cz>
2005-04-11Rename ".dircache" directory to ".git"Libravatar Linus Torvalds1-3/+3
I started out calling the tool "dircache". That's clearly moronic.
2005-04-11Fix stale index.lock file removal using "atexit()".Libravatar Linus Torvalds1-22/+23
Problem noted by Randy Dunlap.
2005-04-10Make "update-cache" a bit friendlier to use (and harder to mis-use).Libravatar Linus Torvalds1-1/+1
It now requires the "--add" flag before you add any new files, and a "--remove" file if you want to mark files for removal. And giving it the "--refresh" flag makes it just update all the files that it already knows about.
2005-04-09Teach "fsck" and "read-tree" about recursive tree-nodes.Libravatar Linus Torvalds1-7/+21
This is totally untested, since we can't actually _write_ things that way yet, but I'll get to that next, I hope. That should fix the huge wasted space for kernel-sized tree objects.
2005-04-09Make "read-tree" read the tree into the current directory cache.Libravatar Linus Torvalds1-49/+53
It will no longer update the actual working directory, just the cache. To update the working directory, you need to use "checkout-cache".
2005-04-08Use "-Wall -O2" for the compiler to get more warnings.Libravatar Linus Torvalds1-1/+0
And fix up the warnings that it pointed out. Let's keep the tree clean from early on. Not that the code is very beautiful anyway ;)
2005-04-07Make read-tree actually unpack the whole tree.Libravatar Linus Torvalds1-1/+41
I needed this to make a "sparse" archive conversion from my old BitKeeper tree data. The scripts to do the conversion are just incredibly ugly, but they seem to validate the notion that you can actually use this silly 'git' thing to save your history in.
2005-04-07Add copyright notices.Libravatar Linus Torvalds1-0/+5
The tool interface sucks (especially "committing" information, which is just me doing everything by hand from the command line), but I think this is in theory actually a viable way of describing the world. So copyright it.
2005-04-07Initial revision of "git", the information manager from hellLibravatar Linus Torvalds1-0/+43