kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Linus Torvalds	0c7993839b	Improved three-way blob merging code This fleshes out the code that generates a three-way merge of a set of blobs. It still actually does the three-way merge using an external executable (ie just calling "merge"), but the interfaces have been cleaned up a lot and are now fully based on the 'mmfile_t' interface, so if libxdiff were to ever grow a compatible three-way-merge, it could probably be directly plugged in. It also uses the previous XDL_EMIT_COMMON functionality extension to libxdiff to generate a made-up base file for the merge for the case where no base file previously existed. This should be equivalent to what we currently do in git-merge-one-file.sh: diff -u -La/$orig -Lb/$orig $orig $src2 \| git-apply --no-add except it should be much simpler and can be done using the direct libxdiff interfaces. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	83788070a3	Prepare "git-merge-tree" for future work This changes how "git-merge-tree" works in two ways: - instead of printing things out as we walk the trees, we save the results in memory. - when we've walked the tree fully, we print out the results in a more explicit way, describing the data. This is basically preparatory work for extending the git-merge-tree functionality in interesting directions. In particular, git-merge-tree is also how you would create a diff between two trees _without_ necessarily creating the merge commit itself. In other words, if you were to just wonder what another branch adds, you should be able to (eventually) just do git merge-tree -p $base HEAD $otherbranch to generate a diff of what the merge would look like. The current merge tree already basically has all the smarts for this, and the explanation of the results just means that hopefully somebody else than me could do the boring work. (You'd basically be able to do the above diff by just changing the printout format for the explanation, and making the "changed in both" first do a three-way merge before it diffs the result). The other thing that the in-memory format allows is rename detection (which the current code does not do). That's the basic reason why we don't want to just explain the differences as we go along - because we want to be able to look at the _other_ differences to see whether the reason an entry got deleted in either branch was perhaps because it got added in another place.. Rename detection should be a fairly trivial pass in between the tree diffing and the explanation. In the meantime, this doesn't actually do anything new, it just outputs the information in a more verbose manner. For an example merge, commit `5ab2c0a475` in the git tree works well and shows renames, along with true removals and additions and files that got changed in both branches. To see that as a tree merge, do: git-merge-tree `64e86c57` `c5c23745` `928e47e3` where the two last ones are the tips that got merged, and the first one is the merge base. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Dmitry V. Levin	31fff305bc	Separate object name errors from usage errors Separate object name errors from usage errors. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	dcb3450fd8	sha1_to_hex() usage cleanup Somebody on the #git channel complained that the sha1_to_hex() thing uses a static buffer which caused an error message to show the same hex output twice instead of showing two different ones. That's pretty easily rectified by making it uses a simple LRU of a few buffers, which also allows some other users (that were aware of the buffer re-use) to be written in a more straightforward manner. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	1b0c7174a1	tree/diff header cleanup. Introduce tree-walk.[ch] and move "struct tree_desc" and associated functions from various places. Rename DIFF_FILE_CANON_MODE(mode) macro to canon_mode(mode) and move it to cache.h. This macro returns the canonicalized st_mode value in the host byte order for files, symlinks and directories -- to be compared with a tree_desc entry. create_ce_mode(mode) in cache.h is similar but is intended to be used for index entries (so it does not work for directories) and returns the value in the network byte order. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	164dcb97f0	git-merge-tree: generalize the "traverse <n> trees in sync" functionality It's actually very useful for other things too. Notably, we could do the combined diff a lot more efficiently with this. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	01df529722	Handling large files with GIT On Tue, 14 Feb 2006, Linus Torvalds wrote: > > Here, btw, is the trivial diff to turn my previous "tree-resolve" into a > "resolve tree relative to the current branch". Gaah. It was trivial, and it happened to work fine for my test-case, but when I started looking at not doing that extremely aggressive subdirectory merging, that showed a few other issues... So in case people want to try, here's a third patch. Oh, and it's against my _original_ path, not incremental to the middle one (ie both patches two and three are against patch #1, it's not a nice series). Now I'm really done, and won't be sending out any more patches today. Sorry for the noise. Linus Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	492e0759bf	Handling large files with GIT On Tue, 14 Feb 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > If somebody is interested in making the "lots of filename changes" case go > > fast, I'd be more than happy to walk them through what they'd need to > > change. I'm just not horribly motivated to do it myself. Hint, hint. > > In case anybody is wondering, I share the same feeling. I > cannot say I'd be "more than happy to" clean up potential > breakages during the development of such changes, but if the > change eventually would help certain use cases, I can be > persuaded to help debugging such a mess ;-). Actually, I got interested in seeing how hard this is, and wrote a simple first cut at doing a tree-optimized merger. Let me shout a bit first: THIS IS WORKING CODE, BUT BE CAREFUL: IT'S A TECHNOLOGY DEMONSTRATION RATHER THAN THE FINAL PRODUCT! With that out of the way, let me descibe what this does (and then describe the missing parts). This is basically a three-way merge that works entirely on the "tree" level, rather than on the index. A lot of the _concepts_ are the same, though, and if you're familiar with the results of an index merge, some of the output will make more sense. You give it three trees: the base tree (tree 0), and the two branches to be merged (tree 1 and tree 2 respectively). It will then walk these three trees, and resolve them as it goes along. The interesting part is: - it can resolve whole sub-directories in one go, without actually even looking recursively at them. A whole subdirectory will resolve the same way as any individual files will (although that may need some modification, see later). - if it has a "content conflict", for subdirectories that means "try to do a recursive tree merge", while for non-subdirectories it's just a content conflict and we'll output the stage 1/2/3 information. - a successful merge will output a single stage 0 ("merged") entry, potentially for a whole subdirectory. - it outputs all the resolve information on stdout, so something like the recursive resolver can pretty easily parse it all. Now, the caveats: - we probably need to be more careful about subdirectory resolves. The trivial case (both branches have the exact same subdirectory) is a trivial resolve, but the other cases ("branch1 matches base, branch2 is different" probably can't be silently just resolved to the "branch2" subdirectory state, since it might involve renames into - or out of - that subdirectory) - we do not track the current index file at all, so this does not do the "check that index matches branch1" logic that the three-way merge in git-read-tree does. The theory is that we'd do a full three-way merge (ignoring the index and working directory), and then to update the working tree, we'd do a two-way "git-read-tree branch1->result" - I didn't actually make it do all the trivial resolve cases that git-read-tree does. It's a technology demonstration. Finally (a more serious caveat): - doing things through stdout may end up being so expensive that we'd need to do something else. In particular, it's likely that I should not actually output the "merge results", but instead output a "merge results as they _differ_ from branch1" However, I think this patch is already interesting enough that people who are interested in merging trees might want to look at it. Please keep in mind that tech _demo_ part, and in particular, keep in mind the final "serious caveat" part. In many ways, the really _interesting_ part of a merge is not the result, but how it _changes_ the branch we're merging into. That's particularly important as it should hopefully also mean that the output size for any reasonable case is minimal (and tracks what we actually need to do to the current state to create the final result). The code very much is organized so that doing the result as a "diff against branch1" should be quite easy/possible. I was actually going to do it, but I decided that it probably makes the output harder to read. I dunno. Anyway, let's think about this kind of approach.. Note how the code itself is actually quite small and short, although it's prbably pretty "dense". As an interesting test-case, I'd suggest this merge in the kernel: git-merge-tree $(git-merge-base 4cbf876 7d2babc) 4cbf876 7d2babc which resolves beautifully (there are no actual file-level conflicts), and you can look at the output of that command to start thinking about what it does. The interesting part (perhaps) is that timing that command for me shows that it takes all of 0.004 seconds.. (the git-merge-base thing takes considerably more ;) The point is, we _can_ do the actual merge part really really quickly. Linus PS. Final note: when I say that it is "WORKING CODE", that is obviously by my standards. IOW, I tested it once and it gave reasonable results - so it must be perfect. Whether it works for anybody else, or indeed for any other test-case, is not my problem ;) Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	2fbdd13174	Remove "merge-tree.c" It's there in the history if somebody wants to resurrect it, but it seems to have been successfully superceded by the new and improved index-merge thing, where we do all merging entirely in the index.	20 years ago
Junio C Hamano	d07f651c25	[PATCH] Add '-z' to merge-tree.c This adds '-z' to merge-tree and changes its default line termination to LF to make it consistent with your other recent changes. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Linus Torvalds	33deb63a36	Add "merge-tree" helper program. Maybe it's retarded, maybe it's helpful. It only works one directory level at a time, so lookout..	20 years ago

12 Commits (5d4a60033543e063bc9d77ca957de0187fb58fb3)