Re: [PATCH v2 00/31] refactor rebase
- From
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
- Date
- Feb 23, 2011, 11:26 UTC
- Message-ID
- <alpine.DEB.2.00.1102230613040.5290@debian>
- In-Reply-To
- <7vd3mjdge1.fsf@alter.siamese.dyndns.org>
On Tue, 22 Feb 2011, Junio C Hamano wrote:
Show 18 quoted lines
> Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes: > > > On Sun, 13 Feb 2011, Martin von Zweigbergk wrote: > > ... > >> This would apply on top of mz/rebase after dropping 95135b0 (rebase: > >> stricter check of standalone sub command, 2011-02-06). If you agree > >> with it, I will include it in a future re-roll. > > > > Any opinions about this, anyone? I have one example: I was rebasing > > some things the other day where I thought there would be no conflicts. > > After applying a number of patches, it turned out there were > > conflicts. I think allowing 'git rebase --continue -sours' would have > > been useful in that case. It's rare enough that I don't care much, > > though. > > Hmm, do you think applying -sours throughout to the rest of the series > would have been a safe thing, or do you think you would rather wanted to > see -sours applied only to that particular one?
In this particular case, I actually wanted it on the rest of the series, but it was such a degenerate case that it doesn't really matter (I just wanted the history graph for testing and didn't care about the trees).
Show 7 quoted lines
> > The reason I'm asking is that I have a patch that fixes the problems > > with the command line parsing that Johannes Sixt pointed out in > > another mail on this thread and would like to know if I should make it > > apply on top of this patch or not. > > It is a good idea to build a change you are more certain of first, > excluding the ones you have doubts about.
True. Will do.
Let's leave this patch for now then and get back to it in a few years when/if someone actually requests it ;-). I agree that it's not clear at this point what the desired behavior is.