Phil Hord <phil.hord@xxxxxxxxx> writes: > On Thu, Mar 8, 2012 at 12:23 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Phil Hord <phil.hord@xxxxxxxxx> writes: > ... > $ git rebase origin/master > Noise, noise, noise > Resolved 'foo' using previous resolution. > Failed to merge in the changes. > > I reach for my utility belt, but my usual tricks all fail at this point: > > $ git mergetool > No files need merging > > $ git rebase --continue > foo: needs merge Just to make sure we are on the same page (I do not personally use "mergetool"), the above looks like a bug in mergetool. Are you reporting a still-unfixed breakage, or is it an anecdote on how you were frustrated in the past due to a bug that has since been fixed? > How's this: Looks good. > 'status':: > > -Like 'diff', but this only prints the filenames that will be tracked > -for resolutions. > +Print paths with conflicts whose merge resolution rerere will record. > + > +'remaining':: > + > +Print paths with conflicts that have not been autoresolved by rerere. > +This includes paths whose resolutions cannot be tracked by rerere, > +such as conflicting submodules. We might want to add "and a path that was deleted by one branch and modified by the other branch" at the end here. Unless an earlier part of the documentation that discusses what kind of resolutions get recorded and reapplied makes it clear enough that the reader can easily guess a delete/modify conflict is not handled, that is. I _think_ the description at the top makes it clear the two branches being merged both need to have a file at the path, so in that sense, singling out delete/modify and mentioning it here might be redundant, but I am not the target audience (I wrote and named it rerere after all ;-), so I shouldn't be my own judge. Thanks. -- 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