The 08/04/10, Aghiles wrote: > >> > >> 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. Doesn't 'git status' ouput what you want ? Or am I out of the scope ? -- Nicolas Sebrecht -- 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