Stephan Beyer <s-beyer@xxxxxxx> writes: >> > Comments? Opinions? Ideas? >> >> I actually expected that the primitive command sequence the backward >> compatible "edit" would expand to would be a pair, "pick" followed by >> "pause". > > Something "like" this was my veeeery first approach: "edit" with commit > was the backwards-compatible "edit" and without arguments was your > "pause". > Example: > pick ea7beef > edit # or "pause" as you suggested > After a little discussion this became: > pick --edit ea7beef > > And I can't objectively say what's better Me neither. My "expectation" came primarily from what I understood, namely you seemt to prefer atomism, and not from "I want things to be this way". If we think any proposed and future instruction would be reasonable to have --edit option, then all insn implementation would need to support "edit" option anyway, and the users do not have to remember which insn does and does not support --edit so both forms would work equally well (and "--edit option" would make the insn stream shorter, which may be good). But probably "mark --edit" and "reset --edit" would not make sense, so a separate "edit" insn may be more generic and useful. > The open question is, if we should do this by a natural number <n> or > by a commit. > The natural number approach seems easier, but imagine someone pauses > and does some commits (not --amend)... Here the behavior of these > approaches differs. ;-) I see. Not using count but setting an explicit mark and using that commit sounds more robust, considering that use case. >> About the other parts in your original message: >> >> - The "tag" command looked a little out of place; > > Eh, why? Why not? I just wondered why there was a support only for lightweight tag there. You do not have "branch" command, and your "tag" command does not seem to support things like -a, -s, -m<msg>, etc. Not that I think you should support full "tag" and "branch" command set, but it seemed a bit odd. -- 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
