Hacker News Reader

Comment by gear54rus | Hacker News Reader

The general sentiment of this article is in things like:

> A commit message is already too annoying for many users!

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)?

Put some damn effort in, we have enough crapware already, we don't need to add more just because you were 'annoyed by having to document changes'.

The thing with git (the way I see it more and more while working with it) is that it barely cares if it makes sense to the 'lay user', it instead cares about wrapping the most fundamental operations on text files. And that's a good thing in my book. I would not like seeing all this ruined just because it was 'zomg too confusing, not useful for most users'.

View on HN

Unfortunately this is simply the reality for many developers.

I have worked with multiple people whose commit logs would look something like...

> e96ddd0 update code

> 65c3072 update code

> dd9ccc1 update code

> 7992ef8 update code

> 6c536e6 update code

> ...

Over and over several dozen commits. Which is technically fine if they know how to rebase. The overwhelming majority of my commits are simply 'git commit -a -m "CI-WIP"` (check-in work in progress), rarely do I realistically revert to any of them.

Unfortunately, a lot of developers aren't willing to learn the 4 or 5 basic commands which make for a clean git history.

And when I have to work with them, I really would prefer if git had something like `git save`. Which in the backend kept doing something like `git commit -a --amend`.

> And when I have to work with them, I really would prefer if git had something like `git save`. Which in the backend kept doing something like `git commit -a --amend`.

This works fine, but it encourages squashing all your changes into a single commit, rater than providing you the opportunity to build a series of commits.

Instead of `git commit -a` I have gotten into the habit of `git add -p` followed by `git commit` and breaking up my current WIP changes into themed-commits. Then later, I perform an interactive rebase and clean up my series (reorder, squash, reword, edit, etc.).

I think, as you and others in this thread describe, the pain is that forming these lightweight commits is cognitively expensive -- but like all things, with experience and practice it becomes nothing at all.

If you use `git commit --fixup=<commit>`, then the new commit will be automatically moved, and given the "fixup" action when doing an interactive rebase. (Same for --squash).

This means you only need to match the fixups to commits once, when you're initially creating them.

Yes, but I rarely use this as I often haven't made up my mind regarding how the series should be structured.

If instead I could fixup using a tag or theme identifier, which would be used to reorder and group commits, then I would spend less time in my rebase.

> I think, as you and others in this thread describe, the pain is that forming these lightweight commits is cognitively expensive -- but like all things, with experience and practice it becomes nothing at all.

A person can only control their own behavior. :)

You can disable pushes to the master branch and (politely) refuse to merge bad commits.

Bad when I used darcs we used to give everyone permission to push to the main repo, but we'd aggressively unpull patches from the server that were bad.

With Mercurial it's all like this. Plus merge commits referencing others' branches full of this sort of history.

History is rather useless if it isn't clean.

Suppose you have a bunch of maintenance releases, and you have to backport some commits occasionally. (Sometimes you realize that you have to do this long after the commits are written.) If those commits are logically organized and minimal, then it's easy to cherry-pick them from the mainline onto the maintenance release branches. If not, then you're in for a world of hurt, and ultimately may have to replicate the relevant bug fixes by hand.

Clean history is critical to a large project, and especially to a large project with maintenance branches.

And that people, is why all good projects do code review.

As the author intimates, most of the problems with git are problems of UI - the UI is simply not very good, it's confusing, inconsistent and too intimately tied with the implementation. This can and should be fixed.

This is a really interesting article, even if you don't agree with it, and the author has a deep understanding of version control systems (works on hg). There's no need to be dismissive of it.

Commit messages could just as easily be a policy requirement instead of a tool requirement. Maybe all the repos you interact with require a message for every commit, and that's fine.

But maybe the default policy should be permissive. People might decide not to use any tool at all if this is the straw that broke the camel's back for them, and that's a worse outcome in my opinion.

And, honestly, 90% of all commits I've seen use crap messages like "stuff", "fixes", or "change 357" that are so devoid of useful content that I'd argue that those commits would be better off with no message at all. Just date and author. At least then you won't be distracted by contentless messages that can't even be self-consistent most of the time. This isn't a swing at those people, I'm just being realistic.

I would rather go the other way. Commit messages should be modifiable by themselves. The idea that commit messages will be gotten right on the first try predates CVS and it’s just wrong.

Who hasn’t put the wrong bug number on a commit? You’re stuck with that. Who hasn’t confidently remarked that they have solved a problem and then discovered they haven’t? Commentary about a block of code needs to be a living document every bit as much as the code it refers to.

Two years from now when you’re trying to figure out what the hell you were doing in a block of code, the message is going to be wrong and everything you’ve thought about it since is gone, except what you can remember.

How do you like git-notes?

For a second I thought you found something I didn’t know about git but then I realized I dismissed notes out of hand. They’re not managed automatically so it’s pointless for me to try to sell a large team on using them. We already work with multiple repos and doubling the workflow won’t be appreciated.

And if I recall isn’t it a pain to add additional notes?

"Change 357" could be a sufficient message if there is some other tool to track changes where I can look up what #357 is all about.

I'd argue that for any piece of software where a failure requires a root cause investigation the VCS history is a critical artifact and a great deal of care should be taken to make it easy to understand for what reasons changes happened and how they interact.

There are a lot of very sophisticated things you can do with and to a body of code to fix extremely complicated problems, but the information needed to do so is at times quite delicate.

The overlap of people who believe in Bad Luck and don’t care about transparency is pretty high. Things just are, there’s no one to blame and certainly no lessons to be learned.

They don’t get how a breaking the commit history with a mangled move operation or shitty merge will fuck is over eighteen months from now. Hell half of these people think they’ll be retired or working someplace else 18 months from now anyway.

> "Change 357" could be a sufficient message if there is some other tool to track changes where I can look up what #357 is all about.

Realistically, though, you won't be able to figure out to which task management system this issue number refers, out of the five that your team used in the last 3 years. We have been through two different JIRAs and two different Github trackers in the last 3 years. Sometimes multiple simultaenously.

Also, whenever you write /#\d+/ in a Git commit, GitHub will stubbornly assume that the number refers to Github issues and PRs, even if it doesn't. And some of our repos use both Github issues (for external input) and JIRA issues (for internal planning).

If you switch issue trackers every ten months without a migration strategy for old issues that's a pretty serious organizational problem. I hope that's not a mature company.

I think in feature branching workflow it would be more useful for the branch to have a message not the commit. Commit is way too small of a unit to be meaningful more often than not.

> The general sentiment of this article is in things like:

> > A commit message is already too annoying for many users!

You have misrepresented the article. It actually says:

> [Commit messages] can be annoying. But we generally accept that as the price you pay for version control: that commit message has value to others (or even your future self).

Maybe you misunderstood "generally accept"; it could be taken to mean "this is what people normally think (but actually they're wrong)". But it's clear from the context he doesn't mean that: it's saying that commit messages really are worth the effort (but it's OK to admit that they do take some effort). It's just context for contrast against saying that a separate staging step is not (always/by default) worth the effort.

> 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/

... 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.

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).

You can use Git for things other than open source software development.

Reply on news.ycombinator.com