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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

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

-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]