>> >> It would be nice to have _all_ the WIP conflicts listed when pulling. >> As of now, one has to fix the currently showed conflict to see the next one. > > Are you using 'git pull --rebase' or the equivalent > branch.<name>.rebase setting? > > If so, note that git-rebase (which does all the hard work) can't know > the later conflicts once it hits the first one: your resolution of the > first conflict constitutes the base onto which the further patches are > applied. So depending on what changes you make during the resolution, > there may be more or fewer conflicts in the rest of the rebase. > > If not, I can't see how your question makes sense as ordinary 'git > pull' does a merge, and during a 'git merge' there can only ever be > one conflict resolution phase. > Sorry, my explanation was not clear. I am talking about changes in the working directory that are not in the index. So my working directory is "dirty" and I just issue a 'git pull'. Because some files are not "up to date" git would abort the pull, saying that a certain file is not "up to date". So I was suggesting to list all the "problematic" files in one go instead. Not a biggie of course. -- aghiles -- 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