Re: git pull suggestion
- From
- Aghiles <aghilesk@gmail.com>
- Date
- Apr 8, 2010, 19:33 UTC
- Message-ID
- <p2x3abd05a91004081233j77b7177bm5928913a64de0e57@mail.gmail.com>
- In-Reply-To
- <201004081754.24954.trast@student.ethz.ch>
Show 17 quoted lines
>> >> 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