Hi Johannes
On 04/04/2025 12:41, Johannes Schindelin wrote:
On Thu, 3 Apr 2025, phillip.wood123@xxxxxxxxx wrote:
On 03/04/2025 13:17, Johannes Schindelin wrote:
On Wed, 2 Apr 2025, phillip.wood123@xxxxxxxxx wrote:
On 01/04/2025 17:22, Johannes Schindelin wrote:
It is unfortunate that we cannot fix this, as `git commit` with an
interrupted `pick` _would_ retain authorship, right?
Unfortunately not. Running "git commit" rather than "git rebase
--continue" to commit a conflict resolution when rebasing always
loses the authorship.
(Why is that so? Can we really not use the same trick with `merge`s?)
Authorship is retained when a `git cherry-pick` (what an unwieldy command
name for _such_ a common operation!) failed with merge conflicts and those
conflicts were resolved and the user then calls `git commit`, though.
Why can this technique not be used in interrupted `pick`/`merge` commands
of `git rebase`?
[Fixed totally garbled formatting that pretended that the first half of
this sentence was written by me, the second half by you:]
Sorry I'm not sure what happened there
`git cherry-pick` retains authorship by writing CHERRY_PICK_HEAD which
`git commit` uses to look up the commit message and authorship.
And why can we not teach `git commit` to use the author information
recorded in `.git/rebase-merge/author-script`, too, and teach `git reset
--hard` to delete it?
If the user passes "--committer-date-is-author-date" then we write the
author-script when stopping for an unconflicted edit command. However if
the user runs "git commit" rather than "git commit --amend" we do not
want to use that script because they are creating a new commit. That
means that "git commit" cannot simply use the author-script if it
exists. I expect we could read all of the rebase state to figure out
what to do but I think it is a much simpler UI to say that the user
should run "git rebase --continue" unless the user is creating a new
commit. Otherwise in a world where "git commit" knows about the author
script the user has to figure out whether or not they need to pass
"--amend" when running "git commit". If they're committing a conflict
resolution for a normal pick they should run "git commit". However if
they are committing a conflict resolution for a fixup then they need to
add "--amend". If "git commit" starts deciding whether to amend or not
to avoid the user having to remember that is even more confusing because
it is behaving differently during a rebase compared to any other time.
When we're rebasing the sequencer removes CHERRY_PICK_HEAD and instead
writes the commit message to MERGE_MSG and the authorship to
.git/rebase-merge/author-script. I think the reason for the different
behavior is to avoid confusing things like `git status`.
The reason is probably more that you can mix `git rebase` and `git
cherry-pick` (why does this common operation have such a long name,
again?). I actually do this quite often, I frequently even have something
like this in my rebase scripts:
exec git cherry-pick ..upstream/seen^{xx/something-something}^2
CHERRY_PICK_HEAD has been removed when rebasing since it was
introduced in d7e5c0cbfb0 (Introduce CHERRY_PICK_HEAD, 2011-02-19). These days
rebase supports --reset-author-date which means it cannot use the same
mechanism as cherry-pick.
Right. But it can recapitulate cherry-pick's strategy in spirit. After
all, `git commit` had to be taught about an interrupted `git cherry-pick`
so that it _could_ pick up the necessary information and use that.
Likewise, `git commit` could be taught about an interrupted `git rebase`
and similarly pick up the author information from what `git rebase`
recorded.
Personally I'd much rather we tell people to use "git rebase --continue"
to commit their conflict resolutions as using "git commit" has never
worked if one wanted to preserve authorship and I think making it work
would be a pain and probably fragile as I'm not sure how we'd ensure
"git commit" knew it was committing a conflict resolution created by
"git rebase" rather than one created by some other commit run while the
rebase was stopped or by an exec command.
Even I, the inventor of `git rebase -i`, have run afoul of this authorship
resetting on more than a dozen occasions.
This is proof enough for me that Git is unnecessarily confusing (no big
revelation there, right? Git earned that reputation very effortlessly, not
only in this particular scenario).
I think it's confusing because "git commit" tries to do too much and
that it was a mistake to allow merge conflicts to be committed by "git
commit" rather than "git <cmd> --continue". I believe the reason "git
commit" allows conflict resolutions to be committed is historical and
that "git merge --continue" was a later addition. Originally "git
commit" was the only way to conclude a conflicted merge. Arguably that's
not too bad for a merge or a single cherry-pick but I'd argue it would
be much less confusing if "git commit" refused to run when it looked
like the user was committing a conflict resolution and told them to run
"git <cmd> --continue" instead.
I'd rather like this usability problem to be fixed, even if it is a pain.
If the pain stems from the way the source code is organized, well, then
maybe this hints at the need to clean up a little?
The sequencer could certainly use a clean up but I fear it would be a
huge time sink for both the patch author and the reviewer.
Best Wishes
Phillip
