From: Phillip Wood Date: Fri, 04 Apr 2025 14:13:40 GMT Subject: Re: [PATCH 3/3] wt-status: suggest 'git rebase --continue' to conclude 'merge' instruction Message-ID: <8fd9d4d0-93e1-4a88-a1ed-1d84b2150893@gmail.com> In-Reply-To: Hi Johannes On 04/04/2025 12:41, Johannes Schindelin wrote: > On Thu, 3 Apr 2025, phillip.wood123@gmail.com wrote: >> On 03/04/2025 13:17, Johannes Schindelin wrote: >>> On Wed, 2 Apr 2025, phillip.wood123@gmail.com 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 --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 --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