Stephan Beyer [off-list ref] writes:
quoted
quoted
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.
quoted
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.
Hi,
quoted
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".
Yes I prefer atomism, because it helps to keep things simple and stupid.
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
Currently every insn where it makes sense (indeed, this may be
subjective) does support --edit. So currently "file" (or "patch"),
"pick", "merge" and "squash" do, because they commit something.
But you are right (and I think Peff meant the same), that the separate
insn is more generic and thus it's more flexible.
So would you prefer a)"pause" or b)"edit"?
Or as text:
a)
edit [<commit>]::
Pauses the sequencer process to let you manually make changes.
+
After you have finished your changes and added them to the index,
invoke `git-sequencer --continue`.
If you only want to edit the last commit message with an editor,
run `git commit --amend` (see linkgit:git-commit[1]) before.
+
If `<commit>` is given, pick `<commit>` first. This is a short form for
`pick <commit>` and `edit` on separate lines.)
b)
edit <commit>::
Picks a commit and pauses the sequencer process to let you
make changes.
+
This is a short form for `pick <commit> and `pause` on separate lines.
pause:: # (perhaps options may occur later, if they make sense)
Pauses the sequencer process to let you manually make changes.
+
After you have finished your changes and added them to the index,
invoke `git-sequencer --continue`.
If you only want to edit the last commit message with an editor,
run `git commit --amend` (see linkgit:git-commit[1]) before.
More flexible and modular seems to be the approach b).
But I want your opinion to go sure. ;-)
I see. Not using count but setting an explicit mark and using that commit
sounds more robust, considering that use case.
So I take the --up-to syntax from Paolo?
Seemed right to me.
quoted
quoted
- The "tag" command looked a little out of place;
Eh, why?
Why not?
Because it's practical.
The marks are only available during sequencer process and it's just
useful to tag something that you can reach by that name afterwards
(or during sequencing, too).
The user could use tag instead of mark if he wants to keep the ref
after sequencing.
I also can imagine sequencer-using scripts, that want to tag a version
release or something.
I just wondered why there was a support only for lightweight tag there.
Basically because it's in next :)
And then I thought "Ok, nice. Let's keep it.".
You do not have "branch" command, and your "tag" command does not seem to
support things like -a, -s, -m<msg>, etc.
Hmmm, -a, -s and -m could even be useful.
Regards,
Stephan
--
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F