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 -- To unsubscribe from this list: 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