Hacker News Reader

Hacker News

Comment by cjhanks | Hacker News Reader

Parent Full thread

cjhanks

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

View on HN

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

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

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.

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.

Reply on news.ycombinator.com