0

I recently started using git commit --fixup and --squash options. I use --fixup option for, ehm, fixups. When I commit with --fixup option, commit message is constructed automatically. For example, when I commit

$ git commit -m '[#123] Lorem ipsum dolor sit amet'

then I do some minor editing

$ git add .
$ git commit --fixup :/123

will autogenerate commit message fixup! [#123] Lorem isum dolor sit amet. However, when I use --squash option instead, such as

$ git add .
$ git commit --squash :/123

git will run text editor and ask me to write the commit message, but at the same time, it will generate and insert in the editor the default commit message squash! [#123] Lorem ipsum dolor sit amet.

My question is: What is the best practice for writing --squash commit messages? With --fixup option, there is no confusion, because git will autogenerate the message and give me no choice of editing it. But with --squash option, git on autogenerates the message on one hand, but gives me the option of editing it on the other hand. The conundrum is, if I always just accept the autogenerated message squash! [#123] ..., what is the purpose of git giving me the opportunity to edit it, and what is the purpose of having --squash option in addition to --fixup if it does the same thing? I am afraid that if I edit the message in a wrong way, git will no longer recognize the commit as intended to be autosquashed to the original [#123] commit.

Boris Stitnicky
  • 12,444
  • 5
  • 57
  • 74
  • 2
    it basically comes down to this: http://stackoverflow.com/a/16758662/2266261 In short, fixup commit message is ignored and the original message is kept, with squash you have the possibility to change the message. – Dunno Sep 19 '16 at 12:26
  • @Dunno, I am asking _how_ to write a good `--squash` message. – Boris Stitnicky Sep 19 '16 at 13:32
  • My take is that it boils down to the same distinction between the "squash" and "fixup" actions in the rebase script you edit after running `git rebase -i` and before that script is executed to actually run the rebasing process. Basically "fixup" is a *stronger* form of "squash" because it does the same thing "squash" does but throws away the commit message. So here's the distinction: squash means "I want the change of this commit be integrated into that commit". Since there are now *two* changes in the same commit, and you're supposed to *document* the changes a commit implements, you're given – kostix Sep 19 '16 at 14:47
  • ...a chance to edit the message of the resulting prospective commit. "fixup", on the other hand, is for "oopsie!" cases when you just, say, forgot to add a new file or did a stupid typo or something like this. IOW, the commit being squashed adds no *logically distinct* change and hence there's no need to document it. As you can see, your question sort of not makes real sense: in the message of a commit to squash into another, you document the change about to be squashed into. – kostix Sep 19 '16 at 14:50
  • Well, to maybe restate all that in different words: if you don't know what to write in the commit message of the commit to squash into another, use fixup. Otherwise explain there what this commit implements, and why -- as you do with every other commit. – kostix Sep 19 '16 at 14:55
  • @kostix, what you say are generalities. What I need is concrete guide. Canned experience. – Boris Stitnicky Sep 19 '16 at 14:59
  • Ah, that's simple: always write "I have no idea" as the squash commit message. Hope this helps. – kostix Sep 19 '16 at 17:00
  • @kostix, I'm getting a hang of it, lol – Boris Stitnicky Sep 20 '16 at 09:37

0 Answers0