I don't imagine having a problem with conflict markers although I've never had any in a git related project (yet!). I'm in the happy position of working by myself at the moment which, in the end, is how I got out of my problem because I knew where all the changes where. Interestingly, the whole .rej file thing IS new to me. I've been using patch files for years and have never had that happen before. Hmmm... Never used emacs either - I'm a Vim-kid :-) Martin's point about simply copying the repo so you have a backup is at the same time dead simple and brilliant. It's almost an undo. I have an idea that I could now fumble my way through a problem like this. The bother is that git has too many commands and too little (idiot proof) help which is a shame. Not everybody is a power user - but we are just the sort of people who mess up. I'm trying to put a positive spin on things - we need a git tips wiki or something. Version control to me is a dull necessity - I don't want to have to think about it! Howard 2009/9/15 Björn Steinbrink <B.Steinbrink@xxxxxx>: > 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 > -- 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