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

201–210 of 278 posts

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

#201

Post by mdaniel »

psadauskas wrote: post #178
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.

I have this one in mine: https://github.com/paul/dotfiles/blob/master/git/.gitconfig#... # make a fixup commit for the last time the file was modified cff = "!f() { [ -n $@ ] && git add $@ && git commit --fixup $(git last-sha $@); }; f" # Get latest sha for file(s) last-sha = log -n1 --pretty=format:%h --grep 'fixup!' --invert-grep Given a file like `git cff path/to/file.rb`, It'll find the last commit that touched t…

It won't matter until it does, but $@ expands arguments into separate words but those expansions are themselves only word-preserved if the $@ is itself quoted. The [ will probably get away with what you want, but its use in $(git add) and $(git last-sha) almost certainly will not

  $ cat > tmp.sh

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

#202

Post by codetrotter »

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.

Yeah. But for that we can squash everything into a single commit on merge. Instead of spending a bunch on time making every single commit in an MR perfect both in isolation and all-together. And if squashing everything in the MR causes a problem with the git history being too coarse, then that is almost certainly because the MR itself should have been split up into multiple MRs. Not because of how you organized the individual commits that belonged to one MR.

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

#203

Post by codetrotter »

beart wrote: post #163
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 >…

In some teams, you are not allowed to submit any commit that breaks the build, and a lint failure would be considered a broken build.

Do these teams run the pipeline on all the commits when you push multiple commits at the same time to your branch?

Say I have an open MR from a branch that I’ve pushed three commits to so far. I pushed these three commits individually and the pipeline ran green each time.

A coworker of mine points out some errors to me.

I have to touch files that I previously touched in the past three commits again.

I am tempted to commit these changes in one commit. But I decide to try git absorb instead.

So instead of adding one fourth, green commit to my MR, my use of git absorb rewrites all three of my previous commits.

But actually, the changes I was about to put in the fourth commit only work when taken together.

Splitting them up and rewriting the previous three commits will result in build failure if you try to build from the new first commit or the new second commit.

I don’t notice that because I’m on the new third commit.

I force push the three new commits to my branch for my MR. Gitlab runs the pipeline on the last of the commits. Everything looks fine to me.

Your team lead approves the MR and pushes the merge button.

Three months later he scolds me for a broken bisect.

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

#204

Post by menaerus »

beart wrote: post #163
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 >…

In some teams, you are not allowed to submit any commit that breaks the build, and a lint failure would be considered a broken build.

We are talking about the commit, or series of commits thereof, during the development of code in feature/bug-fix branch and not about the commit that you push as a post-fix because one of your previous commits broke something. That was not the discussion as far as my understanding goes.

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

#205

Post by JeremyNT »

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…

I am (what I assumed to be) an extensive user of fixup (usually invoked via interactive rebase). I'm intrigued by this but curious as to how it can really save so much time.

Are people fixup'ing a lot more than I do? I might do it once or twice per MR and it's never a large burden to fix the right commit.

If things get really out of hand such that the whole thing is a mess I just squash. Whatever history I had before is almost by definition gross and wrong in this scenario, and I don't mind losing it.

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

#206

Post by menaerus »

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.

merge-commits or patch-series are already making it vastly more difficult for git-bisect than linear history with single self-contained commits. I used both and git-bisect on merge-commits is a nightmare.

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

#207

Post by menaerus »

baq wrote: post #164
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 >…

> What is wrong with simply pushing a "Fix linting issues" in a new commit? if you want every individual commit be buildable then it is a no-go. it's also a no-go if you don't squash your prs.

Red main branch is not what I am talking about at all. I am referring to the code being developed in a feature/bug-fix branch that is yet to be merged with main branch. OP believes that even in the development branch you should not fix your WIP code by adding "Fix linting issues". I thought that was implied by the nature of discussion since rewriting history of the code that resides already on the main branch would be beyond my understanding.

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

#208

Post by burntsushi »

JeremyNT wrote: post #205
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…

I am (what I assumed to be) an extensive user of fixup (usually invoked via interactive rebase). I'm intrigued by this but curious as to how it can really save so much time. Are people fixup'ing a lot more than I do? I might do it once or twice per MR and it's never a large burden to fix the right commit. If things get really out of hand such that the whole thing is a mess I just squash. Whatever history I had before…

It's same kind of thing people tell me about ripgrep. "Why bother with ripgrep, grep has always been fast enough for me." That might well be true. Or maybe we value time differently. Or maybe none of your use cases involve searching more than 100K lines of code, in which case, the speed difference between GNU grep and ripgrep is likely imperceptible. Or maybe being faster unlocks different workflows. (The last one is my favorite. I think it's super common but little is written about it. Once something becomes fast enough, it often changes the way you interact with it in fundamental and powerful ways.)

Because I have git-absorb, I tend to be a bit more fearless when it comes to fixups. It works well enough that I can be pretty confident that it will take most of the tedium away. So in practice, maybe git-absorb means I wind up with fewer squashes and fewer "fix lint" commits because I don't want to deal with finding the right commit.

My use of git-absorb tends to be bursty. Usually when I'm trying to prepare a PR for review or something along those lines. It is especially useful when I have changes that I want to be fixed up into more than one distinct commit. git-absorb will just do it automatically for me. The manual approach is not just about finding the right commit. It also means I need to go through git-add in patch mode to select the right things to put into a fixup commit, and then select the other things for the other commits. So it actually winds up saving a fair bit of work in some cases.

Another example is renaming. Maybe PR review revealed the names of some functions were bad. Maybe I introduced two functions to be renamed in two distinct commits. I could do

first rename -> first commit -> second rename -> second commit

Or I could do:

both renames -> git add -p -> first commit -> second commit

Or I could do:

both renames -> git absorb

In practice, my workflow involves all three of these things. But that last git-absorb option eats into some of the first two options and makes it much nicer.

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

#210

Post by burntsushi »

codetrotter wrote: post #202
homebrewer wrote: post #176

Earlier quoted context omitted.

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

Yeah. But for that we can squash everything into a single commit on merge. Instead of spending a bunch on time making every single commit in an MR perfect both in isolation and all-together. And if squashing everything in the MR causes a problem with the git history being too coarse, then that is almost certainly because the MR itself should have been split up into multiple MRs. Not because of how you organized the i…

The goal isn't perfection. Splitting PRs has overhead, especially depending on what code hosting platform you're using.

Do you advocate for making code easier to read and understand by humans? What would you do if someone told you, "no I don't want to waste my time trying to make it perfect." It's the same misunderstanding. I try to treat code history like I treat code: I do my best to make it comprehensible to humans. And yes, sometimes multiple PRs is better. But sometimes multiple commits in one PR are better. I use both strategies.

Post reply on HN