Re: git pull suggestion

[Nicolas Sebrecht <nicolas.s.dev@gmx.fr>]

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