Re: Refactoring git-rebase.sh and git-rebase--interactive.sh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 2. a. If --continue, --skip or --abort requested, rebase-apply/ or
>      rebase-merge/ must exist. (What if -i is also passed and
>          rebase-apply/ exists?)
>   b. Otherwise, rebase-apply/ or rebase-merge/ must not exist

This actually hints at a more general question, namely whether command
line or saved options should be used when continuing a rebase. For
example, if an interactive rebase has been started with a certain merge
strategy, should that merge strategy be used throughout the rebase, or
should whatever is passed on the command line when continuing be used
instead? Does it depend on which option we are talking about?

As far as I can understand from the code, it seems like non-interactive
rebase currently does not store e.g. the merge strategy, but allows it
to be passed on the command line together with '--continue' (but only if
passed before). Interactive rebase, OTOH, does store the option when the
rebase is initated and does not allow it to be overriden on the command
line. I have not tested either of them, so I may very well be wrong.

Whatever the current behavior is, how do you think it *should* behave?
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]