Re: git-apply that handles rejects like merge conflicts

[Jeff King <peff@peff.net>]

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

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

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