Re: [PATCH 2/2] Add a 'source' decorator for commits

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

 




On Tue, 28 Oct 2008, Linus Torvalds wrote:
> 
> I could imagine doing it as not a single string: you could make it be a 
> pointer to a list of (alphabetically sorted) strings, and then you don't 
> have to make an allocation for each commit, you'd only need to do 
> something like
> 
> 	void add_source(struct commit *commit, struct strin_list *list)

Actually, no. That would be wrong.

Why? Becuase we might be printing out the commit before we see it for the 
second time, so if we were to print out anything but the "first reached 
data", we'd now have really nasty _unreliable_ data that would actually 
change depending on whether we also do things like --topo-sort and/or do 
commit limiting.

So suddenly --source would have to do the full tree just to make sure that 
it's reliably giving the same information, and that makes it much less 
useful.

In contrast, the thing I sent out is not only really simple and has 
basically zero peformance impact, but it's actually "more reliable" in 
that what it gives you is meaningful and clear. It might pick one 
particular name over another in random ways that depend on internal 
choices and the exact order that you gave your arguments in, but it 
doesn't even _try_ to claim anything else.

The source "name" is unambiguous only if there is a single source, and it 
doesn't really even try to claim anything else - for other cases, it will 
give answers that "make sense" but they won't necessarily be the _whole_ 
truth. But it won't ever be really misleading either, and it will never 
cause any slowdowns.

		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]

  Powered by Linux