Re: Finding file revisions

From: Chris Mason <mason@suse.com>
Date: Apr 28, 2005, 22:27 UTC
Message-ID: <200504281827.54553.mason@suse.com>
In-Reply-To: <1114723987.4212.51.camel@localhost.localdomain>

On Thursday 28 April 2005 17:33, Kay Sievers wrote:

Show 8 quoted lines

> 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