Re: git and bzr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, 28 Nov 2006, Aaron Bentley wrote:
> 
> I notice that blame has an option to limit the annotation to recent
> history.  I can only assume that is for performance reasons.

You'd assume wrong.

Trust me, if you talk about performance, bzr will lose. I can pretty much 
guarantee you that you perform worse. The mozilla discussion pointed to a 
performance test between hg and bzr, and hg in that test tended to perform 
better by a factor of 2-10. And git tends to be another factor faster than 
_that_.

Performance is important to git, but it's important not in the sense of 
"let's not do it because it performs badly", but in the sense of "things 
should be so fast that people don't even realize that they are done". You 
guys may count commit times in seconds. I still want to commit multiple 
patches _per_second_ to the kernel tree. THAT is performance.

So no, performance wasn't the reason.

The reason is simple: be logical. The original blame/annotate semantics 
were

	git blame filename

which is what people traditionally use, but then to specify which version 
to _start_ with (in case you wanted to go backwards in time), you had an 
optional revision argument at the end.

Which is totally against how all the other git programs work, and I 
complained, because I had actually wanted to see the blame at a particular 
release version, and what my fingers typed didn't work. I want to be able 
to do

	git blame [revno] [--] filename

the same way I can ask for a git log, git whatchanged, gitk, and any 
other such history tool.

And once you do the same command line parsin as the other log-related 
commands, you pretty much automatically get the revision limiting. So now 
you can do

	git blame v2.6.17..v2.6.18 filename

on the kernel archive to see who is to blame for certain lines in a 
certain _range_ of commits. It just fell out of using the same syntax 
everywhere.

It's also happens to be useful. Quite often, you know something broke 
after a particular known-good release, so you're interested in the blame, 
but anything older than that known-good release is simply noise, and 
actually takes AWAY from the information, by just making things more 
cluttered.

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]