histedit predates evolve, so it drops you on an _uncommitted_ version
of the commit you're amending/splitting, which is in contrast to git
which expects you to use git commit --amend (I think - I'm basing
this on internal bug reports). My hope is that this output will guide
users a little more towards the expected workflow.
Details
- Reviewers
martinvonz - Group Reviewers
hg-reviewers - Commits
- rHG3f82a915ab2a: histedit: tweak `edit` message to try and guide users to our workflow
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
hgext/histedit.py | ||
---|---|---|
37 | This line (same on line 60) sounds at least as confusing. How about "use commit, but edit before committing" or something like that? |
hgext/histedit.py | ||
---|---|---|
802 | What does "amend" mean here? Amend into the parent commit? Or amend relative to the original commit? I think it's the latter, but it sounds like the former to me. Maybe simply s/amend/rewrite/ would make it clearer? |
hgext/histedit.py | ||
---|---|---|
802 | I went with edit because characters are pretty precious at this point. If that's not clear enough (I honestly can't tell), please feel encouraged to suggest alternatives that can keep this line in its 80col limit. |
hgext/histedit.py | ||
---|---|---|
802 | That seems good enough. My problem with "amend" is that hg amend is about squashing the working copy changes into the working copy parent, which I don't think is what we're doing here. |
This line (same on line 60) sounds at least as confusing. How about "use commit, but edit before committing" or something like that?