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

Linus Torvalds <torvalds@osdl.org> writes:

> 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.

>> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html