12

I use git for my local work (and love it ever so much), and I follow a workflow similar to the one described in this article. So basically, when starting on a new feature, I create a branch for it, go through the usual hack then commit cycle, and when I think I'm done with it, I squash it into a single commit using git rebase --interactive master, and I always end up editing the multitude of commit messages into something looking like the example in the article, reproduced here:

[#3275] User Can Add A Comment To a Post

* Adding Comment model, migrations, spec
* Adding Comment controller, helper, spec
* Adding Comment relationship with Post
* Comment belongs to a User
* Comment form on Post show page

Of course, that's after a bunch of removing # This is the xth commit message lines and copy/pasting * in front of each commit message.

Now, what I was wondering, is there any way to customize how git rebase -i outputs the squashed commit messages so I don't have to do all that hacking?

(I use msysgit, if that matters. My editor is Notepad++.)

Thanks!

Joakim
  • 11,468
  • 9
  • 44
  • 50
adamjford
  • 7,478
  • 6
  • 29
  • 41
  • 1
    You should consider changing the accepted answer, since git has added support for this now – Joakim Jun 01 '16 at 14:06
  • @Joakim As discussed below, the git 2.6 feature does not match exactly the OP, so Jefromi's answer stands. – VonC Jun 01 '16 at 17:29

3 Answers3

12

Starting Git 2.6+ (Q3 2015), there will actually be a way to configure git rebase -i commit message.

See commit 16cf51c (13 Jun 2015) by Michael Rappazzo (rappazzo).
(Merged by Junio C Hamano -- gitster -- in commit 9f56db7, 03 Aug 2015)

git-rebase--interactive.sh: add config option for custom instruction format

A config option 'rebase.instructionFormat' can override the default 'oneline' format of the rebase instruction list.

Since the list is parsed using the left, right or boundary mark plus the sha1, they are prepended to the instruction format.

You will soon have a new config:

rebase.instructionFormat

A format string, as specified in git log, to be used for the instruction list during an interactive rebase.
The format will automatically have the long commit hash prepended to the format.

For example:

git config --add rebase.instructionFormat "[%an @ %ar] %s"

Note there is a bug/regression after the release of that feature:
See "Comment in rebase instruction has become too rigid"

I noticed that the format of the comment lines in a rebase instruction sheet has become stricter - it could no longer begin with spaces or tabs. The comment char ("#" for example) has to appear on the first column.


Jefromi comments below:

it appears it's only meant to affect the display within interactive rebase, not the resulting commit messages.

I gave it a try with your example format string and I indeed saw the author information in my editor, but once I told it to squash, the resulting template commit message was still the usual one.

So this isn't a perfect fit for the OP.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Someone told me my answer was wrong now so I had a look at this - it appears it's only meant to affect the display within interactive rebase, not the resulting commit messages. I gave it a try with your example format string and I indeed saw the author information in my editor, but once I told it to squash, the resulting template commit message was still the usual one. – Cascabel Jun 01 '16 at 17:01
  • @Jefromi Good point. I have included your comment in the answer for more visibility. And I have added a comment to the question stating your answer is still the one. – VonC Jun 01 '16 at 17:31
  • ~~this is a great feature, except I can't figure out how to format the date. I'm stuck with the horrendously verbose default. Is there a way to override the date setting of `git log` to get around this?~~ nvm I figured out `--format` has dates like `%ai`, `%aD` etc – CervEd Nov 27 '21 at 13:14
  • @CervEd All options are listed at https://git-scm.com/docs/git-log#Documentation/git-log.txt-emadem: `%ad`, `%aD`, `%ai`, `%ah`,...: try one of those and see which one fits. – VonC Nov 27 '21 at 13:19
  • @VonC yeah, sorry I figured it out – CervEd Nov 27 '21 at 13:20
  • @CervEd No problem, and well done! – VonC Nov 27 '21 at 13:21
  • @VonC are there any limitation to the `rebase.instructionFormat`? I'm trying to add `%N` for commit notes without success :/ – CervEd Dec 22 '21 at 15:20
  • @CervEd Not that I know of. Don't hesitate to post a separate question illustrating the issue (and the OS and Git version) – VonC Dec 22 '21 at 21:19
  • @VonC I think it's a bug so it's probably better I write the mailing-list – CervEd Dec 22 '21 at 21:23
4

There's no way (short of hacking the source) to modify the squash message template, I don't think. However, you have a couple options:

  • Use a git log command to get the shortlist, something like `git log --pretty="* %s" commit-1..commit-2 to get you your bullets. In linux it's very possible to do this from within your editor - don't know how that works with msysgit.

  • Have your editor do the work for you! I don't know what your editor is, so I can't really tell you what to do, but it'd certainly be very possible in vim. (The idea being: search for /# This is the .* commit message/, delete a couple lines, keep one, delete up to the next comment)

Also, it's not what you want in this case, probably, but in fairly recent versions of git, there's a fixup identifier that you can use instead of squash - it does the same thing, but it discards the commit message, so if you have one commit with the real message then ten fixes, you can just mark them all fixup and not have to delete their throwaway messages.

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • I agree. +1. For more on fixup (and autosquashing), see http://stackoverflow.com/questions/2302736/trimming-git-checkins/2302947#2302947 – VonC Mar 19 '10 at 23:00
  • Cool! I'll have to update msysgit and give this fixup and such a shot. :) – adamjford Mar 22 '10 at 16:24
  • I've started to use Vim for my text editing shenanigans, so I suppose I'm going with door #2! – adamjford Apr 26 '10 at 19:27
  • This answer is now incorrect since support for this was added to git. – Joakim Jun 01 '16 at 14:05
  • @Joakim That changes the instruction format displayed in interactive rebase. But does it also change the resulting commit messages? (I tried it, and it didn't seem to - I saw the modified instructions, but the original squash combination message.) – Cascabel Jun 01 '16 at 16:54
  • @Jefromi ah, I had misunderstood the question. I did not realise it was the format of the squashed commit the question was about. I guess because the term "merge" was used instead, which is something else in git. – Joakim Jun 01 '16 at 17:07
0

You can made a --amend when you want. You can checkout in commit previous you commit you want change and amend it.

shingara
  • 46,608
  • 11
  • 99
  • 105
  • Yup, and I use --amend quite a bit because I have fat fingers, apparently. :) But I don't need to --amend my squashed commits to edit the resulting commit message; I just format it in the text editor that pops up after you assign pick/edit/squash to each commit. I clarified my question to account for this. – adamjford Mar 22 '10 at 16:07