Re: git pull suggestion

[Aghiles <aghilesk@gmail.com>]

>>
>> 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