Fortunately, I don't squash my commits • Hacker News Board

Re: Fortunately, I don't squash my commits

#321

Post by cutemonster » Tue, Oct 06, 2020, 4:47 AM UTC

stormbrew wrote: post #257

MaxBarraclough wrote: post #241

Earlier quoted context omitted.

Perhaps we could 'have it all' if git introduced a way of bundling commits, a bit like code-folding in an IDE. The bundles could be expanded when you need fine-grain detail of development history, but by default would be unexpanded and would behave like a single big commit, avoiding the issue of always seeing overwhelming detail.

git has that, it's called a merge commit. You can use `git log --first-parent` to see them unexpanded and then find what you want to expand. A lot of higher level tools don't expose this functionality but it's not like it's not there.

Is there any high level tool that does expose that functionality?

Re: Fortunately, I don't squash my commits

#322

Post by sixstringtheory » Tue, Oct 06, 2020, 4:53 AM UTC

Vinnl wrote: post #273

sixstringtheory wrote: post #230

Earlier quoted context omitted.

If you haven’t yet, check out rebase’s --autosquash option, along with git commit --fixup or the commit message directives “fixup!” and “squash!”

I just learned about that recently, but haven't been able to put it in practice yet. The problem I encounter is having to specify which commit to fixup to when calling `--fixup`, which I think means having to look at my commit history. Instead, my process so far includes just describing the commit I want to fixup in my commit message, in a way that makes sense to me when I'm going through the interactive rebase. Do y…

Unfortunately the best way I’ve found is pulling up the log to copy either the commit hash for --fixup, or the message for fixup!/squash!

My one liner for viewing the git log is: git log --oneline --all --decorate [--graph]

I haven't tried, but I bet HEAD~n works for --fixup, or some quick rev-parse magic (which I don’t know much of).

Re: Fortunately, I don't squash my commits

#323

Post by aayjaychan » Tue, Oct 06, 2020, 6:30 AM UTC

BeetleB wrote: post #315

aayjaychan wrote: post #227

Earlier quoted context omitted.

Git does hide the old commits as well. What git doesn't do is track which commits are replaced by which. So sharing mutable history and seeing how a commit evolved over time requires more heuristic than necessary.

I was under the impression that those individual commits eventually get lost (i.e. may be in the reflog or not sent to the server, etc). With Mercurial's evolve, the hidden commits are always there. When you push/clone, etc they get sent around.

Yes, unreachable commits in Git are GC'd eventually, but you can disable it.

In Mercurial, hidden changesets are kept locally indefinitely, but they are not exchanged; only their obsolescence makers are. So you always know the meta-history of a changeset, but not necessarily their original content.

Re: Fortunately, I don't squash my commits

#324

Post by Vinnl » Tue, Oct 06, 2020, 7:28 AM UTC

kelnos wrote: post #298

Vinnl wrote: post #275

Earlier quoted context omitted.

But you need to deal with those conflicts before merging anyway? And they're a lot easier to deal with in the context of the individual commits than when dealing with one big merge commit, I find.

The issue is that when you rebase, each commit in the chain gets re-applied, one by one. If you change something in an earlier commit that affects later commits, you could end up having to fix the same or similar conflicts several times before the rebase finishes (even with git's conflict resolution cache). In contrast, if you instead merge, you only have to resolve conflicts once, for the merge commit. That being sa…

I think that can be resolved by rebasing onto the first commit of your branch to first make sure all the commits are minimal, and only then to rebase onto your main branch.

That said, I must say that I've personally experienced as a pain, so I don't actually do that.

Re: Fortunately, I don't squash my commits

#325

Post by Nursie » Tue, Oct 06, 2020, 8:47 AM UTC

FeepingCreature wrote: post #320

Nursie wrote: post #271

Earlier quoted context omitted.

When I read the commit history I want to see what was committed. "Hmm, I had a half working X509 chain resolver there that turned out to be unnecessary at the time but would save me a day's work now..."

Keep it on a local branch?

I'd moved workstation by then. If distributed source control is good for anything, surely it's reducing reliance on local state!

I don't think there's an easy answer here. I think there are good things to be said for a readable and bisect-able version history, but also that if you're not preserving your real commit history in a way that's backed up remotely then something's probably wrong.

I'm beginning to think this area, this schism into two schools of thought, is really a signpost that there's something lacking in git's branching. Or something everyone is missing, including me :)

Re: Fortunately, I don't squash my commits

#326

Post by cutemonster » Tue, Oct 06, 2020, 12:46 PM UTC

nemetroid wrote: post #304

ezst wrote: post #265

Earlier quoted context omitted.

This is where you realize that what's killing git is that git has no concept of branches whatsoever. Such a merge isn't "merging A into B (plus shove metadata as string into the commit message)", it is "merging A and B together", which is topologically identical, but semantically very distinct. That's why Mercurial (esp. with evolve and topics) has forever my preference over git.

That's not completely true. There's an order to the parents of a merge commit, and by convention the first parent is the one that was merged "into".

So if I'm on master, and 'git merge feature-x', then the parent commit on the master branch will be the first parent? (Not the feature-x last commit)

Re: Fortunately, I don't squash my commits

#327

Post by corytheboyd » Tue, Oct 06, 2020, 3:16 PM UTC

mixmastamyk wrote: post #294

corytheboyd wrote: post #217

Earlier quoted context omitted.

I wish more people would naturally come to this conclusion in their careers, but many people I have worked with just don’t care about maturing their git disciplines. All it takes is one teammate who thinks it’s a waste of time to undo the progress of everyone else. For context, my career has been in web development start ups, which generally reward the cavalier and tolerate the careful.

> All it takes is one teammate who thinks it’s a waste of time to undo the progress of everyone else. If a strategy demands perfection, it sounds like wishful thinking honestly.

Oh yeah I completely agree. It’s really not something that gets me down, or makes me loathe working with others, it’s exactly that— wishful thinking

Re: Fortunately, I don't squash my commits

#328

Post by nimblegorilla » Tue, Oct 06, 2020, 7:28 PM UTC

acdha wrote: post #319

nimblegorilla wrote: post #313

Earlier quoted context omitted.

Point is that `squash` is a useful tool used by many other successful professionals. I'm allowed to disagree with the author's opinion of the root cause of his bug and the factors that made it hard or easy to debug.

Nobody is saying you can’t disagree. My point was just that you should focus on the topic rather than attacking someone you aren’t familiar with. Doing so was a distraction which didn’t make your argument stronger.

Seems like a form of thought policing which didn't apply to yourself. Hyperbole that I trashed his career and "not a good look" also appears like an off topic attack.

Re: Fortunately, I don't squash my commits

#329

Post by NateEag » Wed, Oct 07, 2020, 4:17 AM UTC

mixmastamyk wrote: post #297

NateEag wrote: post #177

Earlier quoted context omitted.

Because with a test suite, git bisect, and a history that's been reasonably well cared for, I can just tell git "find me the bug" and go do something else until it's done. I don't like having to go fiddle manually for that to work. Ideally you have CI set up so the average test failure email points you to the small patch that broke it. For bugs from the wild that doesn't work, obviously, but I still prefer less frict…

Sounds like you've moved the work forward, where it always has to be done. Rather than doing it in a lazy manner, where most instances can be avoided. Is that a good trade-off?

Like most tradeoffs, it depends on the particular circumstances, I think.

I don't have this set up in my current gig, because we have more pressing priorities.

It is incredibly useful when you do have it, though.

Generally it's more important for really large projects - IIRC Android is really strict about not merging branches containing any commits that break tests, for exactly this reason.

As that implies, you wind up rewriting branches in this approach, too, but for different reasons.

Re: Fortunately, I don't squash my commits

#330

Post by nemetroid » Wed, Oct 07, 2020, 8:38 AM UTC

cutemonster wrote: post #326

nemetroid wrote: post #304

Earlier quoted context omitted.

That's not completely true. There's an order to the parents of a merge commit, and by convention the first parent is the one that was merged "into".

So if I'm on master, and 'git merge feature-x', then the parent commit on the master branch will be the first parent? (Not the feature-x last commit)

Correct.