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

181–190 of 278 posts

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

#181

Post by recursive »

burntsushi wrote: post #179
recursive wrote: post #177

Earlier quoted context omitted.

What do the semantic commit purists do when a rebase causes some arbitrary commit to go from red to green? I've always wondered about that. Commit A becomes A' in a rebase. A is good, but A' is not. A' might be 20 commits ago in a feature branch.

It's hard to follow your example. You say "go from red to green" which I read as "go from failing to passing," but then you go on to say "A becomes A'" where "A is good, but A' is not." Either way, the answer is that if that commit is in your patch series that hasn't been merged yet, that it might make sense to just rewrite A'. But it might not. It could be a ton of work. But also, 20 commits in one branch is rather…

Yeah, that's what I meant.

I guess at the end it's all weighted tradeoffs for me too. I just put less weight on legibility and more on the ability to work on branches co-operatively without force-pushing.

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

#182

Post by lr4444lr »

imp0cat wrote: post #54
boolemancer wrote: post #33

Earlier quoted context omitted.

> At the risk of sounding judgemental, I think this preference for always squashing PRs comes from a place of either not understanding atomic commits, not caring about the benefits of them, or just choosing to be lazy. In any case, the loss of history inevitably comes at a cost of making reverting and cherry-picking changes more difficult later, as well as losing the context of why a change was made. 1) Why are you e…

ad 1) I'd guess it depends on the size of the PR. If they're massive it kinda makes sense.

If only we had a software methodology that championed incremental change...

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

#183

Post by chippiewill »

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.

Amusingly it actually makes you less of a "purist" to not modify commits. Git was created by Linus Torvalds to support Linux Kernel development

The Linux Kernel is heavily built around reviewing each commit individually via patchsets sent as emails and rewriting history to make it cleaner.

Git history is incredibly valuable if its curated, at my previous employer we used Gerrit and pretty much every change would have a well crafted multi-line commit message that explained what was being changed and most importantly _why_. If I wanted to understand why a bit of the codebase had been authored in a particular way it was incredibly easy because I could just git blame the line and there'd be a detailed commit message explaining the rationale.

In the Pull Request world I do agree with what you say - but only if you squash merge. Commits that say "fix typo" or "oops" or "wip" aren't useful long term.

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

#184

Post by cryptonector »

menaerus wrote: post #162
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…

What is wrong with simply pushing a "Fix linting issues" in a new commit? It's self-contained and very well describes the (single) purpose of the commit. I share the sentiment about the "logical small commits", and hence I don't see that adding a new fix commit is problematic as long as it is self-contained and purposeful, but perhaps I don't understand what is the problem that this tool is trying to solve. It says >…

The issue isn't `Fix linting issues`, the issue is a `Fix linting issues` commit for issues you introduced in the code you'll be pushing with that `Fix linting issues` commit. Nobody wants to see you pre-push dev history -- it's not at all interesting. So rebase and squash/fixup such commits, split/merge commits -- do what you have to to make the history you do push to the upstream useful.

Now, if you find linting issues in the upstream and fix those, then a `Fix linting issues` commit is perfectly fine.

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

#185

Post by Gabrys1 »

homebrewer wrote: post #176
menaerus wrote: post #162

Earlier quoted context omitted.

What is wrong with simply pushing a "Fix linting issues" in a new commit? It's self-contained and very well describes the (single) purpose of the commit. I share the sentiment about the "logical small commits", and hence I don't see that adding a new fix commit is problematic as long as it is self-contained and purposeful, but perhaps I don't understand what is the problem that this tool is trying to solve. It says >…

It makes git bisect more difficult than it needs to be.

Exactly this

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

#186

Post by chippiewill »

dclowd9901 wrote: post #64
gorset wrote: post #61

Earlier quoted context omitted.

The use case is when you look at a branch as a series of patches. Reviewing a clean set of commits is much easier than a branch full of mistakes and wrong paths taken. Useful when we optimize for reviewing and good history for future maintenance. This has been important and useful when I’ve worked on big mission critical backend system, but I also understand it might not be the most important factor for a new project…

So this wouldn’t work very well in workflows that flatten merges to a trunk?

Tools where they allow you to squash merge tend to be fairly incompatible with stack diff workflows generally.

It's tricky to review individual commits on Github and Gitlab and they don't even allow you to leave comments on the commit messages.

In areas where people do review individual commits they tend to use tools that support that workflow. Git uses email patches where each commit is sent as a separate email. Tools like Gerrit do code review directly on a commit by commit basis and the usual strategy to get it into trunk is to either "fast forward" (advance the HEAD of the trunk branch to that commit) or to cherry-pick it.

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

#187

Post by cryptonector »

burntsushi wrote: post #143
notlinus wrote: post #69

Earlier quoted context omitted.

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

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…

I think GP is saying that you didn't need to focus on the negativity (which is in itself negativity), just say the substantive thing that you wanted to say without editorializing about negativity. Your complaint (negativity) about negativity might be over-done, and anyways not useful. We can all shake our own heads at others' possibly-unnecessary negativity without having to be calling it out all the time. Meta arguments are not always useful.

Besides, consider this negative comment:

  https://news.ycombinator.com/item?id=41653797
is it one of the negative comments you didn't like? It seems like a possibly-useful negative comment -- "it didn't work for me because ..." is useful unless it was really a matter of undiagnosed PEBKAC. Would you rather than comment not have been posted? Surely not.

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

#189

Post by emersion »

AndrewHampton wrote: post #3

FWIW, I've been using this alias for the past couple years for fixup commits, and I've been happy with it: > gfx='git commit --fixup $(git log $(git merge-base main HEAD)..HEAD --oneline| fzf| cut -d" " -f1)' It shows you the commits on the current branch and lets you select one via fzf. It then creates the fixup commit based on the commit you selected.

With a shell such as fish, one can "git commit --fixup " and a list of commits will be displayed.

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

#190

Post by [deleted] »

johnnypangs wrote: post #117
masklinn wrote: post #60

Earlier quoted context omitted.

Your alias seems like a completely unecessary complexity. If you want to meld new changes into your branch head you can just alias “git commit --amend”, you don’t need that mess. Absorb will find the commits to fix up for each change in the working copy, it doesn’t just merge everything into the head.

I see, the reason it’s that long complicated alias was that I didn’t want to open up the editor to change the commit every time I updated. “git commit —amend” does that. I read the rough how it works and it now makes sense. I might give it a try. Thanks!

[deleted]
Post reply on HN