git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Feature Request: `git commit --amend-to`

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Sep 28, 2021, 19:54 UTC
Message-ID
<87y27gv5bk.fsf@evledraar.gmail.com>
In-Reply-To
<kl6l1r58r6ba.fsf@chooglen-macbookpro.roam.corp.google.com>
On Tue, Sep 28 2021, Glen Choo wrote:
Show 31 quoted lines
> Carlo Arenas <carenas@gmail.com> writes:
>>   git commit --fixup reword:$SHA && EDITOR=true git rebase
>> --interactive --autosquash "$SHA^"
>>
>> granted it is not 1 command, but usually I find it useful to do
>> several of those and then one single
>> rebase at the end.
>
> This is fairly similar to what I use, though I use this through the
> Magit Emacs plugin.
>
> My concern with "--amend-to" is that the semantics aren't as simple as
> --amend.
>
> With --amend, you know you're working on the branch tip, so
> it's relatively simple to discard the last commit and create a new one.
>
> With something like --amend-to, you aren't just modifying a single
> commit, you are also introducing a potential merge conflict with every
> commit after that. You would have to provide some kind of facility for
> users to fix the merge conflicts. A command like git rebase --autosquash
> does a good job at communicating to users that they are actually doing a
> rebase and they need to be prepared to fix problems through a rebase UX.
> However, git commit --amend-to communicates none of that. A user who
> takes a cursory glance at git commit --amend-to has no idea that they
> are potentially comitting to a rebase.
>
> I personally think the current UI makes sense given how Git works. I
> also wish that it were easier to do --amend-to, but I think the problem
> has more to do with how Git manages merges and conflicts and less to do
> with having shortcuts in the CLI.

I think that users who'd like an --amend-to would probably be happy with or might want to try out something like "hg absorb", which is something I think we should have stolen in git already, but it's never too late.

I.e. it's a "git commit --squash" on steroids, which tries to find what commit to amend things into.

See [1] (and [2] for an archive of the linked PDF) for a past reference. There's a "git absorb" in Rust that I haven't tried out, but seems interesting[3]. It looks like "absorb" is now part of "hg" itself[4], but I'd looked at & tried it back when it was part of the Facebook-specific patchset to "hg", which I understand has then mostly or entirely gotten upstreamed in some way.

I'd think that for a git implementation we'd want to re-use the engine we've got in range-diff.c, i.e. consider each unstaged hunk and find which hunk/commit in say @{u}.. to squash it into.

1. https://lore.kernel.org/git/877ej0iuhc.fsf@evledraar.gmail.com
2. https://web.archive.org/web/20181003211051/http://files.lihdd.net/hgabsorb-note.pdf
3. https://crates.io/crates/git-absorb
4. https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-mercurial-4.8/
Previous: Glen ChooNext: Glen Choo
Message 4 of 7 in “Feature Request: `git commit --amend-to`”
  1. Aidan GallagherSep 24, 2021
  2. Carlo ArenasSep 24, 2021
  3. Glen ChooSep 28, 2021
  4. Ævar Arnfjörð BjarmasonSep 28, 2021
  5. Glen ChooSep 29, 2021
  6. Fabian StelzerSep 30, 2021
  7. Phillip WoodSep 30, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.