Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> 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? > 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. Besides, this part of the patch would need fixing anyway ;-) @@ -288,6 +314,7 @@ test $# -gt 2 && usage if test -n "$action" then + test -n "$resume_incompatible" && "--$action used with incompatible option" test -z "$in_progress" && die "No rebase in progress?" # Only interactive rebase uses detailed reflog messages if test "$type" = interactive && test "$GIT_REFLOG_ACTION" = rebase -- 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