Re: [PATCH v2 00/31] refactor rebase

Martin von Zweigbergk [off-list ref] writes:

On Sun, 13 Feb 2011, Martin von Zweigbergk wrote:
...

quoted

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