Re: [PATCH] combine-diff: add safety check to --cc.
- From
Junio C Hamano <junkio@cox.net>
- Date
- Feb 3, 2006, 00:02 UTC
- Message-ID
- <7v64nxmhqn.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <Pine.LNX.4.64.0602021454060.21884@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Ok, my testing shows that this is all wonderful.
Thanks for the compliment.
> And now when I look at Len's "Merge from hell", not only does it take less > than 2 seconds for git-diff-tree to calculate, it looks correct too. At > least I don't see anything that I consider extraneous, although it might, > of course, have removed too much, and I'd not notice.
Two seconds? You must be using CPUs/disks/memory that are lot faster than what I use (the kernel.org machine available to me seems to do it at around 3.5 wallclock seconds). Envy, envy,...
I've done a couple of fixups and added one missing feature and have pushed it out in 'pu' after some final testing. The missing feature was line numbers from each parent. I could not count them right for a long time for some unknown silliness.
Before setting the output format in stone by having gitk interpret it, I'd like to do a quick sanity-check poll.
Len's merge is a bit too wide, so I'll use GIT 1.0.0 commit as an example. Here is what I have right now.
$ git diff-tree --cc v1.0.0 -- debian/changelog | head -n 15
c2f3bf071ee90b01f2d629921bb04c4f798f02fa
diff --cc debian/changelog
index d36904c..376f0fa->4fa6c16
@@@ +1,93 -1,87 -1,3 @@@
++git-core (1.0.0-0) unstable; urgency=low
++
++ * GIT 1.0.0
++
++ -- Junio C Hamano <junkio@cox.net> Wed, 21 Dec 2005...
++
+git-core (0.99.9n-0) unstable; urgency=low
+
+ * GIT 0.99.9n aka 1.0rc6
+
+ -- Junio C Hamano <junkio@cox.net> Wed, 14 Dec 2005...Two things to note.
* Somebody said he missed "index" lines. There is one now, but I am wondering if it might be just be an added noise. It gets absolutely horrible if you run diff-tree on Len's merge. On the other hand, being able to cut&paste them to "git cat-file blob" command line might be handy.
Do we want to keep it?
If we were to keep it, is the format OK? It lists parent blob names (double-dot separated), an arrow, and then result blob name. An alternative would be parent,parent..result, like this:
index d36904c,376f0fa..4fa6c16
which might be more consistent with the normal ones.
* I show the line number from the result (+1,93) and then parents' line numbers (-1,87 for the first parent, -1,3 for the second parent). To be consistent with the normal ones, I am thinking it might be better to move the line number for the result to the last. One downside of that change is I tend to use the line number of the result to look up the full result more often than to use the line number of the parent, and something like Len's merge would push the most important line number off the edge of the screen.
Do we want to keep it the way it is, or do we want to do this instead?
@@@ -1,87 -1,3 +1,93 @@@