4 ms·
If you think of the change set as the subject, so the question is 'what does this do?' and the answer is 'fix X' then it makes more sense. Past tense suggests
by gchpaco 14y ago
If you think of the change set as the subject, so the question is 'what does this do?' and the answer is 'fix X' then it makes more sense. Past tense suggests you might be thinking of it as a journal or something that you're not supposed to do with git due to rebase etc.; each commit ought to stand on its own.
That said I don't think this is significant enough to add up to a compelling reason either way.
- why-el 14y agoYour point about rebase is compelling enough for me. :) I thoroughly missed that. Thanks.
- nirvdrum 14y agoSorry, pardon the ignorance, but how does past tense imply something that would be affected by rebase? It may not be linear history, but it definitely happened in the past. I guess I always looked at more as: "here's a patch", "what did you do?" If it's just a tomato/tomato thing (yeah, that doesn't come out well in text), just let me know.
- gchpaco 14y agoBecause rebase, and rebase -i especially, gives you the ability to break your patches into discrete this-one-one-goddamn-thing patches (which is awkward in a "oh, you committed it? Then you committed it forever" SCM like Perforce or SVN), you should do so. It makes it a lot easier to review than the "so this does X, but also fixes some syntax errors and adds logging" style. And that means you should make the patch comment reflect what it is doing. Some errors here are inevitable but it's something to which I aspire. Edit: to be a little clearer; your traditional SCM has a write-once-never-change model for the trunk of development. This has a problem in a peer review situation, and the problem is this: I may go forth with the best of intentions to decompose things into discrete patches. But when you get down to brass tacks, changes to the system tend to happen in any given order--you might discover a latent bug when testing your feature that has nothing to do with your feature. Now you have two choices: you can wait and commit nothing until everything is great, which means you're not integrating with the mainline, which means that integrating will be incredibly painful, which leads to locks; or you commit as it comes in the moment, which is much better for integration and much easier to back out partial changes and generally get all of the non-backup elements of an SCM, but which is the very devil to peer review. With rebase -i, it is quite easy to commit in the second style in the moment and then clean them up for peer review later; that is the ability to revise history means you can make decisions immediately without worrying that they will be cast in stone forever and ever anon. I wasn't always this much of a hardliner on the subject, but my current job uses Perforce as the main SCM and I have realized that I disagree with almost every decision Perforce makes across the board. I still use it, because any SCM is way better than no SCM and I don't want to explain git to everyone else, but my actual development occurs with git-p4.
- nirvdrum 14y agoThanks for responding. I don't think I necessarily agree, but then again I rarely rebase because I distinctly dislike rewriting history, but I think I understand the rationale a bit better.
- stcredzero 14y agoso the question is 'what does this do?' and the answer is 'fix X' then it makes more sense. Better to say "fixes" then, so it's distinguishable from the use in a phrase as an imperative. "We need to fix this."
- generalk 14y agoI've always found it useful to start writing my commit messages as if they begain with "When applied, this commit will..." ex: "Resolve #459." "Fix the PDF rendering issue on older clients." "Revert commit 1234567."
- stcredzero 14y agoRemone will, and you get more versatile comments.