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

Re: Git Feature Request (Fixdown in interactive rebase)

From
Mike McLean <stixmclean@googlemail.com>
Date
Dec 23, 2020, 23:28 UTC
Message-ID
<CAM0jFOddeArOtbrKVGP0r3Nh=GHPoKqyZ7v6==iFTMpTus4-Fw@mail.gmail.com>
In-Reply-To
<X+PR6yms1G9zVcML@camp.crustytoothpaste.net>

I think I was unclear :) I mean that the new command would take *only* the 2nd commit message. (By analogy to `fixup` which takes *only* the 1st commit message)

I agree that `squash` currently gives you the concatenation of both commits ("all", if squashing >2 commits)

On Wed, Dec 23, 2020 at 11:25 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 44 quoted lines
>
> On 2020-12-23 at 23:08:58, Mike McLean wrote:
> > I initially raised this as a FR with my git UI of choice, and was told
> > that it was actually something that git itself would need to do ...
> > and that the standard way to raise Feature Requests was to email this
> > list.
>
> This is absolutely the right place.
>
> > During an interactive rebase, the text file defining the operations
> > has a command option for "fixup".
> > This will squash the target commit into the previous commit (listed
> > above it in the file), and automatically use the commit message of the
> > previous commit (thus bypassing the "choose the commit message"
> > dialog/file).
> >
> > Can we have a similar convenience-command that squashes, and retains
> > the second commit's message? Purpose is the same as the fixup command
> > - saving a bit of time and unnecessary typing during a common
> > operation.
>
> Maybe I'm misunderstanding what you want, but I think the "squash"
> command does what you want.  It does invoke the editor to edit it, which
> tends to be useful when working on projects that use a sign-off, since
> otherwise your second commit message would be tacked on after the
> sign-off and other trailers.
>
> If you really want to avoid the editor prompt, you can run your rebase
> like so:
>
>   GIT_SEQUENCE_EDITOR="$(git var GIT_EDITOR)" GIT_EDITOR=true git rebase -i
>
> which will avoid spawning an editor except for the todo list and will
> implicitly concatenate the two messages.  That will also make any
> "reword" options a no-op, though.
>
> If you were looking for an editor command that just concatenates the two
> messages without an editor prompt, then no, we don't have that, and that
> would be a new feature.  I wouldn't use it because most of my projects
> use sign-offs, but I'll let other folks weigh in if that's a feature
> they'd like to see.
> --
> brian m. carlson (he/him or they/them)
> Houston, Texas, US
Previous: brian m. carlsonNext: Junio C Hamano
Message 3 of 10 in “Git Feature Request (Fixdown in interactive rebase)”
  1. Mike McLeanDec 23, 2020
  2. brian m. carlsonDec 23, 2020
  3. Mike McLeanDec 23, 2020
  4. Junio C HamanoDec 23, 2020
  5. Mike McLeanDec 24, 2020
  6. Johannes SixtDec 24, 2020
  7. Junio C HamanoDec 24, 2020
  8. Johannes SixtDec 24, 2020
  9. Johannes SchindelinJan 6, 2021
  10. Charvi MendirattaJan 27, 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.