Re: Finding file revisions

[Chris Mason <mason@suse.com>]

On Thursday 28 April 2005 17:33, Kay Sievers wrote:
> Sure. But file-changes lists the commit:
>   c79bea07ec4d3ef087962699fe8b2f6dc5ca7754
>
> when asked for:
>   "drivers/usb/core/usb.c"
>
> and that file isn't touched there. Actually it lists merge-commits which
> are not related to the file.

Ok, this is what Daniel and David were talking about.  When we've got commit 
with multiple parents, we'll find the file at least one more time than it was 
really changed.  Looking at the results on git web, it's easy it ignore the 
merge sets as noise, but it would be nice if we only printed the merge set 
when it made some change to the file the original cset being merged did not.

I had misread your first mail, thinking that you had developed this 
independently and solved these issues ;)  The problem is that if we do a true 
depth first search, it seems like we'll have to keep a potentially unbounded 
amount of data in order to find the first changeset that happened to create a 
given sha1.  I'd really rather print the mergeset and let the user figure it 
out.

But, we're not really printing a merge set so much as we're printing the 
complete diff of what was merged.  Is there some way to see what changes had 
to be done in order to resolve conflicts during a merge?

-chris