On 2009.09.15 15:54:58 +0200, Martin Langhoff wrote: > 2009/9/15 Björn Steinbrink <B.Steinbrink@xxxxxx>: > > Just don't use patch(1), there's no sane reason to do that, you're > > sacrificing all of what git can offer there. > > Oh, yes there is, specially for newcomers used to patch, and how it > handles conflicts. Sooner or later you'll hit a merge conflict anyway, and conflict markers aren't that hard to understand, and IMHO are easier to handle than .rej files, as you get to edit everything in-place. > In this case, I happen to know that Howard is a refugee from CVS land > (the moodle project in this case), and he is familiar with the output > of patch if things go wrong. Uhm, CVS uses the same conflict markers that git uses. > It's not what I'd recommend to someone that is deep in git-land. But > even myself (with a bit of code in git) sometimes use patch when > git-apply tries to be too clever and I just want a damn .rej file to > review and edit with emacs. Well, you likely shouldn't be using git-apply, which is plumbing, and can't easily make use of the "index" information in git patches to do a three-way merge instead of a "stupid" patch application. Instead use git-am --3way to make git perform a three-way merge, leading to conflicts instead of plain patch rejection. And in a case like Howard's, in which nothing is coming from outside the repo, there's not even any reason to use am. It's already all in there, so "checkout -m", "stash/stash apply" (uncommitted changes) and "cherry-pick", "rebase [-i]" are way better than manually dealing with format-patch + am or even apply. Björn -- 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