Re: [PATCH] Fall back to three-way merge when applying a patch.

From: Eric W. Biederman <ebiederm@xmission.com>
Date: Oct 6, 2005, 14:52 UTC
Message-ID: <m1wtkqk89a.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <Pine.LNX.4.64.0510060731560.31407@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 17 quoted lines

> On Wed, 5 Oct 2005, Eric W. Biederman wrote:
>>
>> Ah.  I had missed that git-whatchanged can be given a filename that is
>> nice.  One of the better kept secrets of git.  That makes my whole
>> question worthwhile :)
>
> That's definitely not a secret - it was part of the whole point of 
> git-whatchanged. It's the native git version of "annotate", and I 
> personally find it much more useful.
>
> It's not even just a filename. You can do
>
> 	git-whatchanged -p drivers/scsi/ include/scsi
>
> to limit the set to those two subdirectories. IOW, you can give 
> git-whatchanged an arbitrary list of individual pathnames or directory 
> names.

Which probably means it's time for me to generate a patch to the git-whatchanged documentation.

Show 7 quoted lines

>> But if you happen to have at least the file level sha1 you can
>> actually know if the patch was against what you think it is against.
>
> Yes, a file-level SHA1 may be useful. On the other hand, I suspect that by 
> that time (since you have to search for the version anyway) you might as 
> well have the "just try to apply the patch" approach. It's basically the 
> same search space.

Maybe.

After thinking about it I don't think you need to look through the history to use it for a merge3 operation. As I recall merge3 only looks at the base and the two derived versions of the file. If we have the sha1 of the original in the git repository I think all we need to compute is the diff between that sha1 the current version file. And then apply the merge3 algorithm to combine the two sets of changes.

Eric