Re: git-apply that handles rejects like merge conflicts

Jeff King [off-list ref] writes:

In the general case, you can't represent all failed hunks with conflict
markers, can you?

Conflict markers come from the use of a 3-way merge, and if you were to do
a 3-way merge, by definition, you would need some way to tell where the
preimage of the patch and the target tree you are attempting to apply the
patch forked from. That's done by fall-back-3way in "am -3".

You _could_ lift that logic out of "am -3", but I do not think it is worth
the effort to do so (IOW, I do not see a reason to avoid "am -3").

If you do not want to create a commit for whatever reason, then you can
"reset --soft" back.

On Mon, Nov 07, 2011 at 03:45:48PM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

In the general case, you can't represent all failed hunks with conflict
markers, can you?

Conflict markers come from the use of a 3-way merge, and if you were to do
a 3-way merge, by definition, you would need some way to tell where the
preimage of the patch and the target tree you are attempting to apply the
patch forked from. That's done by fall-back-3way in "am -3".

You _could_ lift that logic out of "am -3", but I do not think it is worth
the effort to do so (IOW, I do not see a reason to avoid "am -3").

I think it would purely be "I have a patch produced by git diff, not by
git format-patch". If you want to use "am -3", you would have to dress
up your patch with mail headers.

In practice, this doesn't come up much for me. I think I was using "git
diff >patch" as a poor-man's stash (and I did just stick some fake
headers in, and "git reset HEAD^" afterwards). But maybe other workflows
deal with this more.

But I think there are two questions:

  1. Should am's 3-way fallback be made more easily available to users
     of regular "apply"?

  2. Short of doing a 3-way merge, are there better ways to represent
     failed hunks in the patch target itself, rather than saving ".rej"
     files?

I'm actually not sure which one Ori was asking about.

-Peff

On 11/08/2011 07:46 AM, Jeff King wrote:

On Mon, Nov 07, 2011 at 03:45:48PM -0800, Junio C Hamano wrote:
But I think there are two questions:

[ snip ]

I'm actually not sure which one Ori was asking about.

I'm actually interested in both :)

Here's a copy of the description of my problem from another reply:

I'm dealing with two codebases that have branched in the past, before
any VCS was used, and now I'm tracking both separately with git. I'm
trying to  apply changes from one to the other with format-patch and
git-am/apply.

In answer to your first question

  1. Should am's 3-way fallback be made more easily available to users
     of regular "apply"?

git-am is never part of this workflow as I'm trying to move patches
between separate repositories with no shared root.

<rant>
And, personally, I don't think git-am is named correctly as the only
use-case I have for it is applying+committing single patches produced by
format-patch and sent as individual files over some medium which isn't
mboxes (I'm not that old-school). I never understood why git-apply can't
do the commit and I have to instead use a tool with 'mail' in its name
(Let's ignore the historical reasons) -- Shouldn't git-am be an
mbox-reading wrapper around some more basic patch-applying tool?
</rant>

quoted

  2. Short of doing a 3-way merge, are there better ways to represent
     failed hunks in the patch target itself, rather than saving ".rej"
     files?

I really want this as .rej files feel very un-git-like. However, after
understanding the problems raised in this thread, I'm a bit more
realistic :)

-Ori

On Tue, Nov 08, 2011 at 10:50:51PM +0200, Ori Avtalion wrote:

In answer to your first question

quoted

  1. Should am's 3-way fallback be made more easily available to users
     of regular "apply"?

git-am is never part of this workflow as I'm trying to move patches
between separate repositories with no shared root.

Isn't git-am the right tool for that? You format-patch out your commits
in one repo, and then apply them in the other. No shared history is
required; just the ability of the patches to actually be applied.

It _helps_ if you have the common base objects (the actual files, not
the commits), since the git diffs carry the pre- and post-image file
sha1s, which is what allows us to do a real 3-way merge. In that case,
it is just a matter of making the objects from the first repo available
to git during the moment you are applying in the second repo. You could
do it by fetching the history of the first into a side-branch of the
second, or even just by sharing object databases via the "alternates"
mechanism.

<rant>
And, personally, I don't think git-am is named correctly as the only
use-case I have for it is applying+committing single patches produced by
format-patch and sent as individual files over some medium which isn't
mboxes (I'm not that old-school). I never understood why git-apply can't
do the commit and I have to instead use a tool with 'mail' in its name
(Let's ignore the historical reasons) -- Shouldn't git-am be an
mbox-reading wrapper around some more basic patch-applying tool?
</rant>

git-am _is_ an mbox-reading wrapper around some more basic
patch-applying tool. That tool is "git apply". I think what you are
missing is that a single patch (or multiple patches) produced by
format-patch _is_ an mbox. There is nothing wrong with:

  cd repo1 &&
  git format-patch -1 --stdout >../my.patch &&
  cd ../repo2 &&
  git am ../my.patch

There is no standard for representing commit metadata in the diff
format. So git had to invent its own. It used rfc822 messages and
mailboxes because it was simple and convenient, it mapped to what some
people were already doing, and it means we don't need a separate tool
for applying local commits versus ones that were emailed.

So the "m" is really for mbox, which happens to be git's format for
storing one or more commits, including metadata. If you just forget that
it's associated with mail, then I think you will be happy. :)

-Peff