2

I use "git add -p" to stage my changes. What I'd like to be able to do is to accumulate a commit message as I'm examining my changes and then when I call "git commit", it is already filled out for me and allows me to make changes before I commit.

Now, its easy to do with git gui by simply examining the changes and editing the commit message text box accordingly, but I'm a command line guy and was wondering if this is possible at the command line.

Carl
  • 39,407
  • 10
  • 74
  • 99
  • 2
    Why not use `git commit --amend`? – Jakub Narębski May 10 '10 at 11:51
  • I think Jakub's comment is probably a better answer than either of the current ones, though squashing with rebase accomplishes the same thing. – Cascabel May 10 '10 at 17:13
  • I agree. I would need to add, commit, and then rinse repeat add, commit --amend until I'm done. It fits in with the existing work flow. – Carl May 10 '10 at 21:19
  • @Jefromi, @Jakub_Narebski [I know it's been ages, but for Googlers]: No, no, why? `commit --amend` would be such an overkill, with possible casualties plus unknown side-effects due to the impedance-mismatch of jolting the git change transaction granularity out of sync with the granularity of the actual change process (imagine a premature accidental `push`!), in addition to less unknown side-effects like possibly confusing/abusing commit hooks, and who knows what. I'd rather send a feature request to git, and just collect interim notes in a text file pasted over at commit in the meantime. – Sz. Mar 16 '17 at 16:27
  • @Sz. Mostly because it's built-in, it lets the OP do what they want (unlike peeking at diffs when writing the message), and it makes the association between the changes and the commit message explicit (unlike mipadi's answer). If you have commit hooks doing things on all local commits, even ones you think of as temporary, or if you refuse to make commits you don't think are "final", you're already going to have a bad time. Squashing with rebase -i is a good solution too, essentially equivalent, so go with what you prefer. But doing it explicitly within git is a good idea, in general. – Cascabel Mar 16 '17 at 16:33
  • @Jefromy, yes, it often fits, and as OP ack'd, his is one of those. Despite what the title suggests, actually: we model changes as atomic, but in practice they mostly aren't, so there's a subtle difference between "recording steps of a change" (handiwork) and "splitting a change into smaller ones" (`commit --amend`). I'm all for microcycle development, but I assumed the first being the case, for which (cheap) support for hand-growing a `COMMIT_EDITMSG` seems to be the correct way, decoupling possibly interfering things cleanly. But now I see your point (as a good solution for the other case). – Sz. Mar 16 '17 at 17:17

2 Answers2

2

git add doesn't offer that functionality, but you could try some other options:

  • use git commit -v to have the diff displayed so you get remembered what you are about to commit
  • make small commits in a private branch, then squash them in a git rebase -i.
  • use another editor to populate .git/COMMIT_EDITMSG. This will be used as a template when you do commit. I believe this way is messy and not much easier than writing down the pieces in a file anywhere and loading when you commit (for vi use `:r filename).
Benjamin Bannier
  • 45,636
  • 10
  • 55
  • 78
1

git commit can take a F (or --file) option that specifies that the commit message should be taken from a file. So you could add your changes, update a file in which you record your message, and then pass that filename to git commit -F <file>.

That doesn't sound like exactly what you want, but it could be a decent workaround.

mipadi
  • 359,228
  • 81
  • 502
  • 469