15

I'm wondering if it is possible to build git commit messages incrementally, documenting what I'm doing as I make code changes:

  1. Check out and begin work
  2. Enter commit message title (i.e. summary)
  3. Make a code change
  4. Update my commit message to describe change
  5. Repeat 3 and 4 until commit is ready

Is there any mechanism built into git to do this?

mtbkrdave
  • 2,900
  • 3
  • 23
  • 24
  • 4
    This is more about preference than objectivity, but I don't think your commits should be large enough to require this. Small, cohesive commits are a godsend when it comes time to rollback or look through your history of changes. – Matt Greer Jan 25 '11 at 22:13
  • In addition to the frequent amending suggestion, you can also use rebase to squash all the commits in question together (possibly using the fixup/autosquash feature). – Cascabel Jan 25 '11 at 22:27
  • 1
    Similar question, possibly even a duplicate: http://stackoverflow.com/questions/3743999/write-git-commit-message-before-git-commit – Tyler Jan 29 '11 at 23:00
  • Small, atomic commits are definitely preferred. But it's even possible to work on small, atomic commits over a period of days or weeks, depending on how much attention a project is getting. I generally aim for atomicity that fits well within a single day's work, but sometimes it just doesn't work out this way. – mtbkrdave Mar 01 '12 at 22:37

3 Answers3

14

git commit can take a commit message from a file using the -F option. So, you can do something like this:

# Do some work
$ echo 'Did some work' > commit-msg.txt
# Do some more work
$ echo 'Did some more work' >> commit-msg.txt
$ git commit -F commit-msg.txt
mipadi
  • 398,885
  • 90
  • 523
  • 479
  • Excellent - provided this file doesn't get staged, or is located outside the repository, this is a good solution to the suboptimal situation pointed out by skco. Thanks! – mtbkrdave Jan 25 '11 at 22:15
  • @medicdave: If you do go with this, rather than amending/squashing, you could add commit-msg.txt to .git/info/excludes, so that it will be ignored within this repository, keeping you from accidentally staging it. – Cascabel Jan 25 '11 at 22:29
6

You are supposed to do a commit for every small change you do that requires a message. This is especially easy with a distributed versioning system like git that you are using.

  1. Check out and begin work
  2. Make a code change
  3. Enter commit message and commit
  4. Repeat 2 and 3
  5. Push updates

And if you for some reason dislike this pattern and want to do the way you described, just use notepad and append to your message after coding a while and then copy paste it when commiting.

skco
  • 131
  • 4
  • This has the advantage of listing your actual incremental changes with each commit (rather than one big one). – Igor Jan 25 '11 at 22:10
  • Ideally, yes, this is the case. But sometimes small changes can break code in other areas (especially when maintaining code with poor coupling, that *ahem* must have been written by someone else), requiring rework unrelated to the original change. In such situations, the desire for small atomic commits is at odds with the desire to only commit working, tested code. In these situations, you end up poring over diffs in order to write a useful commit message after the changes are made. – mtbkrdave Jan 25 '11 at 22:13
  • 1
    @medicdave That's what topic branches are for. Each small commit can break the build, but you do a non-fast-forward merge with master, so all the commits on master are clean and pass the test suite. – William Pursell Jan 26 '11 at 11:00
  • @WilliamPursell good call... I have recently begun using git-flow (and loving it!) and thus my understanding of Git's branching workflow has improved dramatically! – mtbkrdave Mar 01 '12 at 22:33
5

If you really want to do it like this (I don't recommend you to do it that way though), then try this:

  1. Check out and begin work
  2. Make some code changes
  3. git commit
  4. Make some further code changes
  5. git commit --amend
  6. Repeat 4 & 5
  7. git commit --amend --reset-author to further reset the timestamp
poke
  • 369,085
  • 72
  • 557
  • 602
  • 1
    This is effective at solving the problem, but *make sure* that commit doesn't get pushed anywhere public and then amended later! – mtbkrdave Mar 01 '12 at 22:34