Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git-absorb: Git commit –fixup, but automatic

github.com

Post reply on HN
Print view View original

151–160 of 278 posts

Re: Git-absorb: Git commit –fixup, but automatic

#151

Post by mst »

ssijak wrote: post #125

Do people actually check commit history in detail so often that they absolutely find so much value in ultra clean commit history? I never understood that obsession with 100% clean history.

When I'm hunting a mistake (even/especially my own) finding the commit that introduced the bad line via blame and then looking at that specific diff is extremely handy. Also being able to bounce back and forth between the first broken one and the one before running tests while I work out exactly what I messed up and how.

I wouldn't say I put the effort in to get to 100% clean but something like 95% clean makes future me significantly less enraged at past me's mistakes.

Re: Git-absorb: Git commit –fixup, but automatic

#152

Post by mst »

parasti wrote: post #79

TIL about `git commit --fixup` and `git rebase --autosquash`. Interactive git rebase is by far my favorite Git tool to use, it scratches a particular itch to create perfect logically atomic commits. That said, sometimes this kind of history editing tends to backfire spectacularly because these crafted perfect commits have actually never been compiled and tested.

I tend to go back through and build+test each of my newly crafted commits locally (and for preference have CI set up such that it'll go "hey, haven't seen these commits" and do it again itself).

Some people find doing so this boring and annoying. For whatever reason my brain finds it zen and satisfying.

Re: Git-absorb: Git commit –fixup, but automatic

#153

Post by [deleted] »

notlinus wrote: post #69
burntsushi wrote: post #36

The negativity in the comments here is unwarranted in my opinion. I've been using `git absorb` for years and it works amazingly well. I use it in addition to manual fixups. My most common uses of git-absorb, but definitely not the only, are when I submit a PR with multiple commits and it fails CI for whatever reason. If fixing CI requires changes across multiple commits (say, lint violations), then git-absorb will al…

Criticism isn't negativity. We're not Pollyannas here, we're adults who can handle critique.

[deleted]

Re: Git-absorb: Git commit –fixup, but automatic

#154

Post by insane_dreamer »

3eb7988a1663 wrote: post #17
imiric wrote: post #14

I tried using this tool after seeing recommendations for it, but IME it got the parent commit wrong enough times that the work to undo the damage was more than if I had looked up the commit myself and used `--fixup` instead. So I moved back to this manual workflow pretty quickly. I prefer having full control over my commit history, and this tool is too much magic for my taste. I'm sure that it could be improved so th…

I use lazygit for this. Keyboard driven TUI which lets you easily re-order/squash commits with minimum fuss. Being able to see them all laid out means no futzing with identifying the right ids.

lazygit also my go-to for this and git in general

Re: Git-absorb: Git commit –fixup, but automatic

#155

Post by dpkirchner »

theptip wrote: post #142
bradley13 wrote: post #56

Maybe I am being to much of a purist, but retroactively modifying commits and history? Why? Stuff happens, so do mistakes. Fix the mistakes, make another commit, and go on with your life.

It sounds like you have never heard of the Stacked Diffs workflow. Here is an overview: https://newsletter.pragmaticengineer.com/p/stacked-diffs It’s a perfectly reasonable preference to eschew this workflow, but definitely worth understanding the pros and cons.

Every explanation of stacked diffs I've seen (including this one) makes me think there is some secret magic not being shared that will make the whole idea "click".

If the problem is devs having to wait too long for PRs to be reviewed, breaking tasks up in to smaller diffs should exacerbate the problem, wouldn't it?

If diff 2..n follow diff 1 then a review of 1 blocks everything else you're doing, eh? At least the traditional route, branching everything straight off of main, means you can merge 2..n and rebase 1 once it passes, leaving you less blocked.

There must be something I'm missing because there are a lot of people promoting stacking diffs.

Re: Git-absorb: Git commit –fixup, but automatic

#156

Post by burntsushi »

j_maffe wrote: post #147
burntsushi wrote: post #143

Earlier quoted context omitted.

Can you give me an example of criticism that is not negative? As far as I know, all forms of criticisms involve pointing out a flaw or fault. There's constructive criticism, but it's still fundamentally negative. Either way, feel free to replace the word "negative" with "criticism" in my comment if you want. It expresses the same thing I intended to express: I disagree with the criticism. If we're not Pollyannas and…

Negative comments are not always a product of negativity. Sometimes it's positive feedback to improve something that has potential.

I think that can be true and my top-level comment can be true simultaneously. I've also clarified what I meant at this point.

Re: Git-absorb: Git commit –fixup, but automatic

#157

Post by OJFord »

This makes no sense to me, why would a conflict-free modifiable commit within the last 10 be the one I want to fixup any more often than roughly 1 in 10?

I fixup^ frequently, often often with conflict to resolve in the process, and I have never ever thought 'if only something would automatically choose the target commit for me', even if it was advanced AI why would I trust it to be what I wanted?

^my alias is:

    !f(){ target="$(test -n "$1" && git rev-parse "$1" || git fzsha rev-parse)"; git commit --fixup="$target" ${@:2} && EDITOR=true git rebase -i --autostash --autosquash "$target^"; }; f
`git fzsha` being another alias of mine to choose the target commit with fzf if not given. I rarely use that though, because usually I know it's HEAD~5 or whatever from doing it a second ago, or I've already been looking at the log to work out what I want.

Re: Git-absorb: Git commit –fixup, but automatic

#158

Post by enw »

In what situations does this solve a problem?

In our projects we only enable squash merge in GitHub and the PRs can have any commits you want. The squashed commit includes link to PR, and PR has detailed summary (which wouldn’t be practical in the commit message).

Re: Git-absorb: Git commit –fixup, but automatic

#159

Post by PhilipRoman »

ssijak wrote: post #125

Do people actually check commit history in detail so often that they absolutely find so much value in ultra clean commit history? I never understood that obsession with 100% clean history.

Doesn't have to be 100% clean, but history has tremendous value to me. Often the most important question for me when fixing a problem is "was this intentional" (aka did that guy (who left 10 years before I arrived) know what he was doing?).

As far as I remember, I've had to check history for about 2/3 of bugs I've fixed.

In a perfect world each system would be documented and tested well enough that correctness could be derived from first principles, but we do not live in a perfect world :(

Re: Git-absorb: Git commit –fixup, but automatic

#160

Post by radlad »

dpkirchner wrote: post #155
theptip wrote: post #142

Earlier quoted context omitted.

It sounds like you have never heard of the Stacked Diffs workflow. Here is an overview: https://newsletter.pragmaticengineer.com/p/stacked-diffs It’s a perfectly reasonable preference to eschew this workflow, but definitely worth understanding the pros and cons.

Every explanation of stacked diffs I've seen (including this one) makes me think there is some secret magic not being shared that will make the whole idea "click". If the problem is devs having to wait too long for PRs to be reviewed, breaking tasks up in to smaller diffs should exacerbate the problem, wouldn't it? If diff 2..n follow diff 1 then a review of 1 blocks everything else you're doing, eh? At least the tra…

> If the problem is devs having to wait too long for PRs to be reviewed, breaking tasks up in to smaller diffs should exacerbate the problem, wouldn't it?

I find small diffs to be much easier to review and as a result I review them much practically as soon as they are posted. And I'm less likely to miss something.

Post reply on HN