Comment by Nursie | Hacker News Reader

Comment by Nursie | Hacker News Reader

Parent Full thread

> people take the limitations of git and existing OSS tooling as a given and project those failings onto whichever paradigm they are arguing against.

Very much agree. We have the whole "rebase to a single commit for your PR" vs. "keep a history of what actually happened" argument. One side wants to view concise, comprehensible change histories and be able to bisect them to see the origins of bugs etc, the other wants to use an rcs/vcs for one of the primary tasks an rcs/vcs is supposed to undertake - recording and keeping safe a version history of code as it is developed. To each the other side is wrong to even want that.

There have been source control systems in the past that would cater to both quite happily. Nightmarish, terrible, slow, heavyweight source control systems that involved learning an entire configuration language to use effectively, and which I certainly wouldn't recommend using today! (Rational Clearcase, I'm looking at you). They have existed and conceivably could do so again.

But the debate is always in the context of git.

Who wants to record typos or patch after patch in your private branch? That has absolutely no value.

There is a middle ground between "retain the history of every typo anyone ever made" and "squash a month's worth of work into a single commit". Without having to learn a huge amount you can rebase your private branch now and again to squash all those typos and "fix the tests" commits into a single coherent commit describing the step towards the feature you're working on.

What I'd really love in that context is for Github's PR interface to surface individual commits better. I want to be able to step through each commit, reviewing the incremental changes towards a fully working feature, rather than have to review the entire thing as one big blob.

It already does that. Click on the individual commit to only see those changes, then click next to continue. That's the only way I review commits, and it has been available for at least a few years

> Who wants to record typos or patch after patch in your private branch? That has absolutely no value.

A couple of years ago I wrote most of a custom X509 validation stack in java before realising we didn't need one after all, there was a way to do what we needed with the standard stuff, so it wasn't in the final PR. Three months later things changed, I did need one and being able to look it up saved me several days work.

It can have a huge amount of value.

Who cares about revision history being neat and atomic? It's not been of the slightest consequence to me. It's not like there's a realistic maximum number of revisions you can store in your repo.

But to the original point, clearly both of these features have a use-case, and people want them. Other source control systems in the past (which were much worse in many other ways) catered for this. But the current tension only exists because the dominant source control system doesn't really allow you to pick and choose how you see the data.

(Unless it does, see other thread)

I'm so glad that the days of ClearCase are over, managing multisite replicated vobs and whatever bullshit viewspec required to make releases work was a nightmare that I wouldn't wish on my worst enemy. <big tech company> also had some horrendous frontend to clearcase that was actually used by the engineers that had strange and wonderful interactions that only the guy that left 5 years ago knew about and left for us to re-discover.

Git _can_ accomodate both! Just use merge commits, and collapse them when you want the simplified "linear list of merged PRs" history.

Collapse? Are we talking about a particular UI?

I'm firmly in the "record everything" camp myself but if I can point the 'other' team to an easy way to fulfil their needs it'll be a benefit.

Yes, the git CLI! Try `git log --first-parent`. Not sure about which other frontends support it, but they should (if only to shut the squashers up).

One reason I like cleaning up the history before merging is that anyone can then `git blame` and land on a commit that shows the feature/bugfix as a whole and hopefully with a clear explanation in the commit message. Not a bunch of "Fix typo" kind of commits.

Any solution for that?

It looks like git blame supports the same flag, and explicitly calls this out as a use case in the documentation!

I always used this but how do you add patches to the same output?

Reply on news.ycombinator.com