Re: How to resolve git-am conflict (possible bug)

From: Junio C Hamano <junkio@cox.net>
Date: Aug 12, 2006, 19:49 UTC
Message-ID: <7v7j1dpwe6.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0608121146550.10541@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

> On Sat, 12 Aug 2006, Jakub Narebski wrote:
>
>> Why do we not record commit id in patch?
>
> Because we do not have to.

More relevant point is that more often than not it does not help. The most common workflow that involves format-patch output is to give your change to somebody else that does not have (and does not merge with) your repository, and the commit that is formatted is your own. The other party does not have the commit so telling its object name is useless.

Even if you recorded the commit object name of the pre-image that would not help unless the patch happens to be the first patch in a series forked from something the other party has.

>> And how git-rebase deals with this?

It applies the format-patch output using "git-am -3". In this case, the preimage blobs recorded on "index" lines are guaranteed to exist in the repository the "git-am" runs, because the patches are coming from the same repository. And the patches are obviously not munged (we do not give you a chance to muck with them between the time we generate and we apply) so they are guaranteed to apply to the blobs recorded on "index" lines. Running the three-way fallback procedure on a change already present on the new "onto" branch results in no change in the index and that is how it notices the patch has already been applied.