3 ms·

> So because your ass is just lazy another guy a few months down the road has to suffer (in this case decipher what it is you wanted to do with your changes)?

> So because your ass is just lazy another guy a few months down the road has to suffer (in this case decipher what it is you wanted to do with your changes)? The problem that Greg is referring to here is that `git commit` (as for many other version control systems) overloads two distinct operations: checkpointing your work and creating a new revision. Forcing you to provide messages for the former use case can even be counterproductive [1]. Contrast this with, say, Smalltalk's ENVY: saving a method automatically versioned the method (without the need of providing any other metadata), but you could also separately create system snapshots as named versions. Common Git usage is to squash checkpoint commits, anyway, with individual commit messages often disappearing in the process. [1] https://xkcd.com/1296/ https://xkcd.com/1296/

nhaehnle 9y ago
... so have a policy of all your "checkpoint" commits just having "checkpoint" as a message. Or ".". Forcing a commit message is a good default, because it's a good idea to nudge developers towards properly expressing what they're doing. But if you think you know what you're doing, it's easy enough to work around.
- rbehrends 9y ago
  Checkpointing is generally different from commits in more than just not having a commit message (ex: should one allow checkpoints to be pushed? should they be suppressed in the log by default? should they be part of the normal revision graph or a separate hierarchy?). Yes, you can emulate them because Git is a general versioned, hierarchical key value store. But by the same token, you don't really need Git, you could just store each new version in a separate directory. A version control system is about more than providing raw access to a storage engine; it needs to support appropriate high-level operation and integration with the development process. The problem here is the Procrustean way in which people try to force everything to fit Git's model rather than to think beyond its limitations (many of which are shared by other VCSes, I don't want to single Git out here) and to address these problems at the user experience level (especially when we're talking about normal users, such as writers and artists, who may not have a deep understanding of the technical details).

nhaehnle 9y ago

... so have a policy of all your "checkpoint" commits just having "checkpoint" as a message. Or ".". Forcing a commit message is a good default, because it's a good idea to nudge developers towards properly expressing what they're doing. But if you think you know what you're doing, it's easy enough to work around.

rbehrends 9y ago
Checkpointing is generally different from commits in more than just not having a commit message (ex: should one allow checkpoints to be pushed? should they be suppressed in the log by default? should they be part of the normal revision graph or a separate hierarchy?). Yes, you can emulate them because Git is a general versioned, hierarchical key value store. But by the same token, you don't really need Git, you could just store each new version in a separate directory. A version control system is about more than providing raw access to a storage engine; it needs to support appropriate high-level operation and integration with the development process. The problem here is the Procrustean way in which people try to force everything to fit Git's model rather than to think beyond its limitations (many of which are shared by other VCSes, I don't want to single Git out here) and to address these problems at the user experience level (especially when we're talking about normal users, such as writers and artists, who may not have a deep understanding of the technical details).