7

Is there a way to set a comment for the next future commit using git? Imagine something like this:

git next-commit "Implement client-side validation"

# implement the feature ...

# commit changes
# equivalent to git commit -m "Implement client-side validation"
git commit -m from-next-commit

The motivation behind this is that I often have a particular feature in mind when I'm programming, but along the way I end up developing some other features or fixing related things and I lose track of the main task I was working on.

At that point I have modified the source code with useful changes, but I don't even remember what the main feature I added is, since it's all just a bunch of changes and the only commit message I can think of is git commit -m "Update stuff". Setting the message for the next commit could also help me keep working on what I was supposed to do. At any point if I feel like I've forgotten the main task and have derailed to other feature, I would ideally ask git with something like git next-commit, which could print Implement client-side validation.

Does a feature like this exist?

EDIT: after seeing some answers, I think I should clarify another thing. Ideally, this command would also help you keep track of when the future commit has already been used. For example, if you use git commit -m from next-commit twice without setting a new future commit message before, it should fail.

$ git next-commit "Implement client-side validation"
ok
$ git commit -m from-next-commit
ok
# git commit -m from-next-commit
error : already used
$ git next-commit "Optimize get_request"
ok
$ git commit -m from-next-commit
ok
Mei Zhang
  • 1,434
  • 13
  • 29

4 Answers4

2

Perhaps use git commit -F <file> to read the comment from a file?

jspcal
  • 50,847
  • 7
  • 72
  • 76
  • I do this occasionally. It's useful when working on a long feature. I put the message in a .commit file, and edit the message during the work. In between, I make small commit with message starting with "... ". In the end, make the final commit with the .commit file. – chuan Feb 19 '19 at 10:54
  • maybe -e flag. `git commit -eF ` lets you edit the message in the final commit – chuan Feb 19 '19 at 10:55
2

Honestly if you are having so much trouble remembering what you did in the current commit, I might question whether you would even be in a good state the review all the code before making that commit. Maybe you should invest in an issue tracker like Jira.

That being said, one trick you might find useful here would be to start off by making a dummy commit, where you just make a small change somewhere. Add the "future" commit message you have in mind via:

git commit -m 'Implement client-side validation'

Then, do your work and finish the commit. When it comes time to commit this work, you may amend the previous commit:

git commit --amend

This should by default bring up an editor window, in which you should see your future commit message already there.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • True enough, if having trouble remembering things, would be better to add a note somewhere to keep track of things you're doing and have done. – Mukyuu Feb 18 '19 at 06:20
  • I think that was the point of the answer, to use git as a quick way to add that note. – yewang Feb 18 '19 at 06:21
  • The problem with `git commit --amend` is that it's always possible to run it. Ideally, once you commit with the future comment you set before, the comment would be deleted, and you would have to set a new future comment to do it again. – Mei Zhang Feb 18 '19 at 06:24
  • 1
    @MeiZhang When I gave this answer, I was assuming that the commit message would change with each commit, which in 10+ years of using Git has been my general experience. – Tim Biegeleisen Feb 18 '19 at 06:26
  • Of course I want to change the message with every commit, maybe I didn't explain myself well. What I'm saying is that an ideal solution would also keep track of when the future commit has already been used. For example, the second time you try to use it, it should fail: `$ git next-commit "Implement client-side validation" ok $ git commit -m from-next-commit ok # git commit -m from-next-commit error : already used, set a new next-commit first`. The probem with `git commit --amend`, it's something that can be done at any time without any checks. – Mei Zhang Feb 18 '19 at 06:30
2

Personally I would do what Tim Biegeleisen suggested, but it wouldn't be terribly hard to do what you want if you're willing to use a custom command instead of git commit.

That is, you could make a custom git-next-commit script, put it in PATH, and have it write your desired commit message to some file in the root of your git repo (or maybe in .git/).

Then make another custom script (e.g. git-commit-from-next, or just reuse git-next-commit, possibly with a command-line option) that invokes git commit with the previously stored message and deletes the file. If the file doesn't exist, then print an appropriate error message.

You also might be able to get the git prepare-commit-msg hook to do what you want if it sees a special "from-next-commit" message.

jamesdlin
  • 81,374
  • 13
  • 159
  • 204
  • James, it should be possible to setup a pre-commit hook which reads a commit message from a file somewhere. Then, you'd only need some command line program which writes a message to that file. Downside: then you might loose the ability to easily choose a message when you actually commit. – Tim Biegeleisen Feb 18 '19 at 07:27
  • @TimBiegeleisen My thinking was to use the prepare-commit-msg hook (not the pre-commit hook) to check for some special "from-next-commit" message, replace the contents of the commit message if found, and otherwise leave everything alone. Looking at the prepare-commit-msg hook some more, I think it should be possible (but I haven't spent the time to actually implement it). – jamesdlin Feb 18 '19 at 07:55
1

My recommendation would be to cut a branch with the "description" you have in mind (e.g. git checkout -b "mz-client-side-validation". Remember the commit at which you started this branch (use a tag, say mz-csv if you need to) and then begin your work. It doesn't matter at first if you're not focused with the nature of your work. What you should get into the habit of is making small commits (even with bad messages). So while the commits are not always related to client-side-validation, they are small enough to be useful in the history.

Once you're done implementing your actual feature (perhaps via. multiple commits), do a git rebase -i mz-csv. Now you can clean up the history of work on mz-client-side-validation. Cut up commits, merge them, drop them etc. and when you're ready, merge mz-client-side-validation back into the main branch.

Noufal Ibrahim
  • 71,383
  • 13
  • 135
  • 169