Hacker News Reader

Comment by ikawe | Hacker News Reader

On the other hand, a couple years down the road, a generic pull-request-level comment (added feature foo) can be more useful than a bunch of noisy commits like

    - WIP: feature foo
    - fixed typo
    - whoops! 
    - working
    - reformatted

As is often the case with new contributors to open source projects.

In theory --no-ff merges give you the best of both worlds, but in practice, I traverse git history with 'git blame' or 'git log -p <filename>' neither of which do a good job of surfacing "this commit was merged as part of feature/foo".

Of course, all the info is there... But I haven't yet found a good UI for it.

View on HN

I have the following aliases in ~/.gitconfig:

    [alias]
        log0 = log --first-parent -m
        show0 = show --first-parent -m
        blame0 = blame --first-parent -m

These aliases treat history as if each merge commit introduced the changes directly, and didn't have the individual history. (Even for one-patch PRs, this means that the log/blame view will point me to a commit with a link to the pull request, which means I can see any discussion of the PR.) For instance, `git show` on a merge commit will typically show no output (unless there was a merge conflict), but `git show0` will show all changes introduced by the branch being merged in, as if they had all been squashed down.

My experience is that I've really appreciated projects with a policy of mandatory merge commits (e.g. Rust; every commit is tested and merged by the CI bot, and humans only push to master in emergencies) with these in place.

Aha! This is what I need to make merge-based workflows palatable! Now if only the Github UI could do the same...

This is the real solution here, updating github's ui so it does it like this, but still allows viewing the individual commits if needed.

In theory, this is why we rebase our history and make an elegant series of coherent patches. At least if "we" are the Linux dev team or something.

Yup, I agree that would be ideal. I think squash commits are a pragmatic way to deal with messy incoherent commits.

Plus it's easier to revert a squashed commit than a merge. (which is the index number of the parent I want?!)

I think everyone would agree that the above commit history is bad, and should be avoided.

But solving that issue by adopting a squash-on-merge policy is like doing surgery with a chainsaw. There are better tools for the job.

There is definite value in having more granular commits, but at the same time, there are commits that don't really belong in the commit history.

While it might take more time than squashing everything, git rebase -i really helps a ton in these situations. I can fixup all the "fixed typo" type of commits into a meaningful commit, and even reword commits if necessary.

I've had exactly this experience multiple times. Having nice logical commits makes it a heck of a lot easier to port features around to different branches later on (if you decide you want to). It makes 'git annotate' much more useful. It makes 'git bisect' more useful. It makes backing out a feature easier.

I don't want to see some massive 3 month worth of feature hacking, 5000 line modification get squashed down into a single commit. I want it broken into the smallest possible working and incremental changes that transform the old code into the new. Each step should make sense for the code maintainers who come along later and try to figure out what you did and why something unexpected broke. ;-)

I don't want to see 200 noisy commits like you say. I've worked with code bases that used both of these styles. The former is vastly superior in my experience.

The problem I find is that squashing those commits together will mean I can't easily figure out what typo was fixed in commit 2, because of the diff-spam reformatting of commit 5. This makes it that much harder to figure out that the typo was a variable name in a dynamic language where all use cases on-branch were fixed, but other use cases (e.g. in my own personal private branch) were not.

I care much more about the actual mechanical code change which broke my stuff, than the feature or branch that happened to contain that mechanical code change.

The same problems apply to reviewing the code in the first place. I'll gladly review 10x the code if it's split into nice tiny micro-commits, even messy ones, than try and suss out exactly all the moving parts that changed from a squashed diff to make sure all potential concerns are addressed. Commit #2 might trigger a "email your coworkers to alert them of the breaking change when submitting" review note, whereas I'm liable to miss the fact that you fixed a typo in the first place in a squashed commit.

As I understood the example, the typo was meant to have been introduced in the "WIP feature foo" commit, and the reformatting was meant to be of the changed code as well.

Reply on news.ycombinator.com