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@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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
