17 ms·

Git-absorb: Git commit –fixup, but automatic

• MBlume 2y ago
  I've been using this workflow with hg and it's great, happy to see a git port
  • optymizer 2y ago
    One of my favorite Sapling commands at Meta
    • pdpi 2y ago
      Yeah, it singlehandedly turned me on to Mercurial when I was there, and has massively shaped the way I use git ever since.
  • toastal 2y ago
    Darcs documentation suggests amending & fixing up WIP commits too
• AndrewHampton 2y ago
  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.
  • nickspain 2y ago
    Nice! I use git revise[^1] a lot which does a similar thing but without the fixup commit. I I’ll try using fzf to make it interactive though. Thanks! [^1]: https://github.com/mystor/git-revise https://github.com/mystor/git-revise
  • kccqzy 2y ago
    If it only lets you select one, that's strictly less powerful. What if I want some parts of it into one commit and another parts into another? The `hg absorb` works for this case.
    • kadoban 2y ago
      That sounds like what `git add -p` is for, stage part of the current changes.
      • kccqzy 2y ago
        That still requires you to manually select hunks. The point of `hg absorb` is to automatically select hunks even if these hunks are to be squashed into different commits.
        • account42 2y ago
          "Automatic" sound like it would fail about as often as it would help.
    • k3vinw 2y ago
      Might be able to use the multimode flag in the fzf command above and it should let you select more than one using Tab and Shift+Tab.
    • atq2119 2y ago
      Then you use `git gui`, which is part of the git distribution itself, or `tig` if TUIs are your thing. I have a key binding for `git commit --squash=%(commit)` in my tig config, so I can interactively select lines or hunks to stage and then the target commit for the squash.
    • AndrewHampton 2y ago
      Yeah, it's definitely less powerful that what absorb is doing. I wasn't trying to argue that it was equivalent. I just wanted to share a bash one-liner that I've had success with in case others find it helpful. > What if I want some parts of it into one commit and another parts into another? Looks like absorb will automatically break out every hunk into a separate fixup commit. My one-liner will create 1 fixup commit for everything that's staged. That's typically what I need, but on the occasions it's not, I use `git add -p`, as kadoban mentioned, to stage exactly what I want for each commit.
  • mckn1ght 2y ago
    sounds like how magit lets you create fixup commits in emacs
    • masklinn 2y ago
      Worse in fact, since magit lets you fixup, squash, or instafix.
    • AndrewHampton 2y ago
      This was 100% my inspiration. I used emacs+magit for years. After switching away from emacs for dev work, I still cracked it open for git interactions for another year or so. Eventually, I moved entirely to the shell with a bunch of aliases to replicate my magit workflow.
  • dangitman 2y ago
    [dead]
  • johnnypangs 2y ago
    I’ve been using this: alias gfixup="git commit -v --fixup HEAD && GIT_SEQUENCE_EDITOR=touch git rebase -i --stat --autosquash --autostash HEAD~2" From what I understand it does the same thing as this crate for the most part. All I do after is: git push —force-with-lease Not sure what you get from the crate otherwise
    • johnnypangs 2y ago
      I guess the crate version is easier to soft reset?
    • masklinn 2y ago
      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.
      • johnnypangs 2y ago
        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!
        • johnnypangs 2y ago
          Seems like you can add —no-edit and get the same behavior, now I can delete that alias. Thanks again :) (Edit: typo)
          • masklinn 2y ago
            That is correct, and there is a `--edit` to revert that, so my personal alias is to `git ci --amend --no-edit` such that by default it just merges the staging into the HEAD, and then tacking on `-e` will open the commit message in an editor to expand it.
  • psadauskas 2y ago
    I have this one in mine: https://github.com/paul/dotfiles/blob/master/git/.gitconfig#L59-L60 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 that file, and make a fixup commit for it. Its great for the try-this-change-on-CI cycle: Change the Dockerfile, git cff Dockerfile, push, repeat, without it screwing up because you changed a different file while you were working on it.
    • mdaniel 2y ago
      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 <<'FOO' for a in $@; do echo "a=$a"; done echo for b in "$@"; do echo "b=$b"; done echo for c in $*; do echo "c=$c"; done echo for d in "$*"; do echo "d=$d"; done echo FOO $ bash tmp.sh 'alpha beta' $'charlie\ndelta' a=alpha a=beta a=charlie a=delta b=alpha beta b=charlie delta c=alpha c=beta c=charlie c=delta d=alpha beta charlie delta
      • psadauskas 2y ago
        Yeah, you're probably right. I guess I haven't run it on any files with spaces in the 6 years since I added it to my dotfiles.
  • emersion 2y ago
    With a shell such as fish, one can "git commit --fixup <tab>" and a list of commits will be displayed.
  • jonS90 2y ago
    Funny that I've been doing something nearly identical, but with way more boilerplate. fzfCommit() { local FZF_PROMPT="${FZF_PROMPT:=Commit: }" git log --oneline | fzf --border --prompt="$FZF_PROMPT" --height=10 --preview="git show {+1} --color=always" --no-sort --reverse | cut -d' ' -f1 | tr '\n' ' ' | sed 's/[[:space:]]$//'; } function gfixup { local commit=$(FZF_PROMPT='Fixup Commit: ' fzfCommit) if [[ -z "$commit" ]]; then return 1 fi set -x git commit --fixup "$commit" --allow-empty > /dev/null || return 1 git rebase --interactive "$commit"~ --autosquash || return 1 }
    • deleted 2y ago
      [deleted]
• a1o 2y ago
  Uhm, I do a lot of git rebase -i HEAD~2 where I just squash the commit on the latest or sometimes I need to reorder and move the fix commits in specific commits in Pars that multiple commits, which I then need to push force. Is this for a similar use-case? I am not familiar with fixup or how it works.
  • mckn1ght 2y ago
    fixup works with rebase if you add the -a flag for autosquash. try it and you’ll see the commits already reordered for you in the interactive menu. also you can write HEAD~2 as @^^ if you want to save a couple keystrokes!
    • rom1v 2y ago
      Nit: Or @~2 (@ is HEAD, so @^^ is HEAD^^).
  • AlexCoventry 2y ago
    You can also just press `c`, then `F`, in magit.
  • hoten 2y ago
    fixup lets you mark a change to be rolled back into a previous commit, without changing the history (yet). When you do `git rebase --autosquash` it then automatically moves those commits as `fixup` in the right places. It helps to queue up many fixups at once and only have a single rebase to do when you're done (or for reviewers to see just the changes in a review tool, not have to reassess the entire commit because you already rebased) btw you could be doing `git commit --amend` if you just want to add to the last commit.
  • cryptonector 2y ago
    Yes. This saves you having to `git rebase -i` or `git rebase --autosquash` to get the fixup to be "absorbed" into the commit it is meant to fix up.
• renewiltord 2y ago
  Pretty clever impl of a tool. I'll be using it, thanks.
• taberiand 2y ago
  This sounds very useful, I frequently reset soft and recommit in batches of related changes before PR and this sounds like it streamlines integrating updates quite nicely
• lr4444lr 2y ago
  you don't want to shove them all into an opaque commit that says fixes, because you believe in atomic commits. Sure I do. The whole branch will be squashed anyway before it's merged in, and a single "fixes" commit while still on its own branch will be easier to track in a PR for addressing everything pointed out earlier. I mean, don't let me stop anyone from using this or --fixup if this is your flow, but this solves a problem neither I nor anyone in my last 10 years of working with code has.
  • krick 2y ago
    Good for you, but you (and, apparently, everyone in your last 10 years of working with) would have a problem if I was the one reviewing your commits. I mean, to be fair, I often did let it slide (for political/social/practical reasons) and use autosquash, but I always actively discouraged it, so if you are a junior or a new hire with uncertain usefulness status, I'd at least talk to you about that and ask you to fix it. This is not an ok practice, it's only acceptable because too many people don't have a habit of making their own bed and much bigger kinds of technical debt get ignored because in the end it's about shipping stuff, so you just sigh and say "oh, whatever".
    • hamandcheese 2y ago
      It has always been enough for me to trace a change back to its original pull request. Extra granularity might be nice sometimes but never essential. And I do a fair bit of digging through git history. Not sure what makes it "not an ok practice". Squashing works fine and lets the 80% of people who don't care spend their efforts thinking about something other than a perfect git history.
    • notlinus 2y ago
      For what it's worth, you're right.
    • keybored 2y ago
      I personally agree that what you advocate is better. But apparently people get by without it. It’s better. But not essential. No bridges will collapse because of squash merges. I also disagree with the framing: some policy can always be enforced if you have some kind of authority over the other person. Now we’re veering away from arguing on the technical merits.
• imiric 2y ago
  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 that mistakes are rare, but I'm not sure I would trust it enough to not have to review its work anyway.
  • 3eb7988a1663 2y ago
    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.
    • imiric 2y ago
      I rarely refer to commits by their IDs in these cases, though. More often than not I use the relative `HEAD~n`, when it's easy to determine `n` visually. With a few aliases, the manual fixup workflow really doesn't take much effort.
    • montag 2y ago
      This sounds just right.
    • arcanemachiner 2y ago
      I love lazygit so much. I use it all the time, and it's constantly improving my workflow.
    • insane_dreamer 2y ago
      lazygit also my go-to for this and git in general
  • adastra22 2y ago
    If it just automatically created the fix up commit and moved it to the proper place in the commit tree, I’d be happy with that. You can then run a one-liner to merge the fix up commits after reviewing.
• deleted 2y ago
  [deleted]
• rglynn 2y ago
  As a frequent user of fixups, this feels like a solution for already broken workflows. > Instead of manually finding commit SHAs for git commit --fixup Assuming you are using fixups, is this actually a problem? I could see this being a possibility if you are: A. not practicing atomic commits or B. have so many commits in your branch that this is a chore. A. seems unlikely if you are already using fixups and B. seems like a problem worth solving properly rather than going around. To sum up, I'm not convinced by the elevator pitch. However, I am keenly aware that the workflows of developers differ vastly across industry, company size, technology etc. I'd be interested to understand what problems this or similar tools solve?
  • adastra22 2y ago
    How would you manage long-lived branches that are periodically rebased against the master branch (when there is a release, for example)?
  • seadan83 2y ago
    What solutions have you seen for problem (B)? The open source example is hard to fix AFAIK. Everything needs to be a PR, some changes to older code bases are simply going to be either large or multi-stepped (many commits, and sending them all as stacked PRs is often not efficient enough to be effective). In industry, I think there are more solutions available. Though, overall, I am very curious how you would go about solving B.
  • cryptonector 2y ago
    Tools like this are useful for users who are not power users.
  • keybored 2y ago
    > Assuming you are using fixups, is this actually a problem? No. They made a whole tool around a not-actually problem. Sure you can have a 30-commit branch. Find some OSS project where someone has been doing a large project on a branch for two months because the maintainer hasn’t accepted it yet.
• adastra22 2y ago
  The thing that I never knew I needed, but I predict within a few days I won’t be able to live without. Thank you!
• tcoff91 2y ago
  Just use magit and easily make fixup! commits with like 3 key presses. Even if you don't use emacs keeping it around just to use magit is worth it. Edamagit for vscode users is not as good but it does this particular workflow great.
  • psanford 2y ago
    I use magit. I still use git absorb. The issue for me is not the speed at which I can run the interactive rebase, it is the amount of looking I have to do to find the correct commit to fixup onto in a big stack of commits. git absorb figures that out for me.
  • accelbred 2y ago
    magit supports git-absorb out of the box if its installed; see the magit-commit-absorb command. I find it quite useful.
  • bananapub 2y ago
    magit is fantastic but this isn't at all the same thing. fixup is "stage changes, users selects past commit to fixup, commit staged changes" absorb is "stage changes, git-absorb figures out which past commit to fixup, commit staged changes"
• burntsushi 2y ago
  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 almost always find the right commit for each change automatically. It saves the tedium of finding the right commit for each change. False positives are virtually non-existent in my experience. False negatives do happen, but then you just fall back to the manual approach. It seems like some would reply and say PRs should just be one commit. Or that they will be squashed anyway. And sure, that is sometimes the case. But not always. I tend to prefer logically small commits when possible, and it's not always practical to break them up across multiple PRs. Perhaps partially due to how GitHub works. I use this workflow on all of my projects on GitHub.
  • masklinn 2y ago
    I’ve been using autofixup for this and it’s been ok but not great, it can be quite slow as things grown, and it doesn’t say anything when there was no match so it’s easy to miss. How does absorb surface that? > Perhaps partially due to how GitHub works. That’s definitely a major factor, I’d like to use stacked PRs they sound really neat, but GitHub. Also even with stacked PRs I figure sometimes you’re at the top of the stack and you change things which affect multiple commits / prs anyway, surely in that case you need to fixup other commits than the ToS?
    • Zitrax 2y ago
      I assume you refer to https://github.com/torbiak/git-autofixup https://github.com/torbiak/git-autofixup. I have also used it, and its ok but not perfect.
      • krobelus 2y ago
        I use git autofixup; it was much better than git absorb last time I checked > it doesn’t say anything when there was no match that's what it should do > it can be quite slow as things grown How? All the slowness (on large repos) I've seen has been fixed.
• dmead 2y ago
  This sounds great,but kind of an anti pattern in git. I definitely want to have a "fixes" commit on my feature branch. You should do whatever you want on a feature branch so long as your trunk has a clean history. This sounds like someone wanted to lift a feature of changesets in mercurial into git. I don't think this is safe and probably breaks a lot of people's mental model of git changelogs being an immutable data structure.
  • saagarjha 2y ago
    At some point the changes are going to get merged in, no? And that that point I would really like the commits to be nice.
    • dmead 2y ago
      That's why you squash and make the commit message readable.
      • saagarjha 2y ago
        Squash all the commits I worked so hard to make atomic?
      • cryptonector 2y ago
        No, you don't want to squash everything into one commit. You want logical, clean history.
    • snatchpiesinger 2y ago
      git log --first-parent
  • cryptonector 2y ago
    This is no more nor less safe than `git rebase`.
  • keybored 2y ago
    > I definitely want to have a "fixes" commit on my feature branch. You should do whatever you want on a feature branch so long as your trunk has a clean history. This tool creates `fixup!` commits. These commits aren’t rewrite commits. They are commits which later can be used to rewrite the history. You can use this tool, not rewrite your branch, and then rewrite the branch right before merge. > This sounds like someone wanted to lift a feature of changesets in mercurial into git. I don't think this is safe and probably breaks a lot of people's mental model of git changelogs being an immutable data structure. Rewriting is a huge part of the Git culture (and well-supported). Meanwhile Mercurial seems to have rewriting as a sort of add-on.
• juped 2y ago
  If I understand the logic it uses correctly this will nearly always attach the fixup to the right commit. It's not for me because I do this manually too fluidly but it seems like a good tool.
• psanford 2y ago
  I'm a huge fan of git absorb. I love tools that do-the-right-thing so I can think less. That is what git absorb is.
• saagarjha 2y ago
  This seems neat in theory but I would be perpetually concerned that it is going to pull some change I don't mean to commit and put it into something for review. How well does it do at that, anecdotally?
  • mook 2y ago
    It deals with things that have been staged, so if you don't want to commit then don't stage it. I believe a dirty working tree is fine (and gets ignored).
• bradley13 2y ago
  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.
  • rom1v 2y ago
    https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net...
  • gorset 2y ago
    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’s success.
    • dclowd9901 2y ago
      So this wouldn’t work very well in workflows that flatten merges to a trunk?
      • travisjungroth 2y ago
        It would mostly be unnecessary. The separate commits won’t matter after the PR if they’re getting squashed. Debatably, if you’re making changes during a PR review, it could be helpful to make those changes in relevant commits. That way if someone goes through them during the PR, they get one clean “story”, rather than see the pre-PR commits and the conversation after.
      • mst 2y ago
        I like for non-trivial stuff to have a branch with a series of logical commits, cleanly rebased atop main, then use -no-ff to force a merge commit anyway. That way you can the whole branch appears as a single commit/diff atop main in primary history but you can dig in to the original components of it if/when that's useful. The primary obstacle to doing this for me is, if I'm honest, not having automated it sufficiently that I can't forget to do that.
• DanielHB 2y ago
  Am I the only one who doesn't like atomic commits (or stacked PRs like graphite)? When I work on large PRs I often rewrite and move things around so much that trying to keep all commits in sync is a nightmare. I do try to split the work if it is very clearly isolated, but that usually means less than 3 PRs. I have tried graphite `gt absorb` (which might use this project?) and it still creates a mess. What I do that I wish more people did is that I heavily comment my own PRs with information that doesn't make sense in comments (for example on line X I add a comment: moved here from Y file). > You have fixes for the bugs, but you don't want to shove them all into an opaque commit that says fixes I actually like this, but split each fix in its own commit and during review I answer to comments with: "fixed in commit {commit-sha}". So _often_ bugs are introduced during PR review, if the fixes are isolated it is easier to see what changes between review rounds.
  • alex23478 2y ago
    I think this really boils down how your team is using Git and which code review tool you're using. (I've never used Gerrit personally, but as far as I understand it, we wouldn't have this conversation, since it aims to refine a single change by re-submitting a commit over and over again?) For GitHub/GitLab reviews, I'm totally with you - this makes it more convenient for the reviewer to check that/how you've responded to feedback. But now if you merge this without squashing, your Git history on the main branch contains all your revisions, which makes operations like bisecting or blame more complicated. For me personally, the sweet spot is currently a mix of stacked-commits and the PR workflow: Use a single commit as the unit of review, and polish that commit using a PR, and use the commit descriptions within that PR to tell the story of you responding to feedback. Then, squash merge that commit. This provides both a good review experience and a tidy history. If you find a strange bug later and can't grasp how someone could have come up with that, the PR still has all the history. Together with tools such as git-branchless, this also makes working on stacked-PRs a breeze.
    • usr1106 2y ago
      Why are people talking about stacked PRs/MRs? Shouldn't they be called queued? A stack is LIFO and a queue is FIFO. (Of course in some special case you might want to merge a later one earlier, but I don't think that's the normal case people are talking about.)
• parasti 2y ago
  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.
  • mst 2y ago
    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.
• tripdout 2y ago
  How does it figure out which commit to add each change to?
  • andsens 2y ago
    7 lines into the README buddy: > The command essentially looks at the lines that were modified, finds a changeset modifying those lines, and amends that changeset to include your uncommitted changes.
  • bananapub 2y ago
    it explains it in literally the first paragraph: https://github.com/tummychow/git-absorb?tab=readme-ov-file#git-absorb https://github.com/tummychow/git-absorb?tab=readme-ov-file#g... > The command essentially looks at the lines that were modified, finds a changeset modifying those lines, and amends that changeset to include your uncommitted changes.
• dangsux 2y ago
  [dead]
• globular-toast 2y ago
  There seems to be an alternative implementation called git-autofixup: https://github.com/torbiak/git-autofixup https://github.com/torbiak/git-autofixup Has anyone compared the two?
  • dawg 2y ago
    Yes, I empirically found the hunk-based approach of git autofixup to work more reliably. I use it via magit. Paired with rebase --update-refs, it's particularly helpful to automatically fixup stacked branches.
  • krobelus 2y ago
    https://news.ycombinator.com/item?id=26507205 https://news.ycombinator.com/item?id=26507205
• ssijak 2y ago
  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.
  • baruch 2y ago
    I do. To learn a code base it before tremendously, also to find what happened and why things were done it is off great help. I don't need it every day but I routinely do git archeology.
  • freedomben 2y ago
    Yes, absolutely. Writing out a change log when you have clean commit history is a trivial task. Doing so when it's not clean, can be arduous and take hours, and then still end up being inaccurate. I also frequently try to find when some bug or change was introduced in the get history, so that I can understand why it was done through the context. Context. When it is just thrown in some random commit that doesn't even have much of a commit message, it is utterly useless. When it is part of a commit that is atomic and targeted at one thing, it is trivial to see why it was done. Even when the comment isn't super helpful (which is common despite intentions, because predicting the future and what will be useful in the future is very difficult) it's still valuable because you can see the code in its full context and it's often clear what it's doing. So yes, I am a big believer in clean commit history with atomic, single commits that represent the task someone was doing. For example, If it was a bug fix, then the bug fix will be in its own commit with a commit message describing the bug that is being fixed.
  • playingalong 2y ago
    Do people wash their hands 15 times a day so that they absolutely fine so much value in getting rid of the bugs? The answer is: some do, some don't.
  • jcon321 2y ago
    Yea teams that have poor tracking and no PR practices.
  • asqueella 2y ago
• thecopy 2y ago
  If i understand this will break "changes since my last review" and disconnect PR review comments in GitHub?
  • jeltz 2y ago
    No, why would it?
    • thecopy 2y ago
      Perhaps i misunderstood it... looks to me like squashing commits and would require a force push, which would have this effect.
• Aissen 2y ago
  This looks a lot like git-fixup[1], which I have been using for a few years. I might try git-absorb since it looks quite interesting. [1] https://github.com/keis/git-fixup https://github.com/keis/git-fixup
• OJFord 2y ago
  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.
• enw 2y ago
  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).
  • titusjohnson 2y ago
    Agreed. It's been a decade or more since I and the teams I worked with did anything other than squash-merging a feature branch into main. The PR body becomes the commit body for the squash, and we're done. Developers can be as f'n messy as they want on their branches, no one cares because it never hits main.
  • keybored 2y ago
    Admittedly git absorb solves a smaller problem. Because if you do squash merges and leave the history in GitHub you have much bigger problems.
• cocoto 2y ago
  Small question to anyone with this workflow. Do you (re)run CI on every affected commit? If no, what is the point of small commits if you lose any guarantees? I much prefer the honest linear non-modified history.
  • keybored 2y ago
    Why do you ask that question as if that is the obviously most important factor? My history is read much more than it is checked out. And definitely much more than it is stress-tested by some CI. Readability matters more. I’m having a hard time imagining all the supposed “commit for coffee break” committers who also are die-hard bisect users that go nuts when someone doesn’t run the whole CI on every commit.[1] And if you don’t have that many commits to check because you “squash merge”: `git bisect start --first-parent` gives you exactly the same result.
• gorjusborg 2y ago
  'git rebase -i' meets this need and more. Everyone using git should learn to use it eventually. With it you can squash, fixup, reword, or delete commits interactively.
  • burntsushi 2y ago
    git-absorb is a complementary tool to `git rebase -i`. git-absorb will create the fixup commits (from your staging area) for you and set them up for use with `git rebase -i --autosquash`.
    • gorjusborg 2y ago
      It solves a problem that can be solved better by good habits and a solid understanding of git.
      • burntsushi 2y ago
        That suggests you don't understand what git-absorb does. git-absorb takes a pattern of good habits and makes one part of it faster and easier.
        • gorjusborg 2y ago
          Sure, I guess that's possible. All I see is a tool that guesses where to aggregate a fixup commits when I can't be bothered to view and think about that myself.
          • burntsushi 2y ago
            About grep, all I see is a tool that looks for lines matching a query when I can't be bothered to just read the file myself. I can trivialize useful software too. See how ridiculous you sound? That's what software does! It makes our job easier. It's true that git-absorb guesses, but since you clearly haven't used the tool, you don't know how good it is at guessing. Moreover, false positives and false negatives are not the same in this scenario. A false positive would be very annoying, and I don't think that's ever happened for me in the years I've been using git-absorb. False negatives happen more frequently, but it's fine, because it tells you and then you just fall back to what you would have done manually for whatever it couldn't find a commit for.
• metadat 2y ago
  I haven't used `git --fixup' or `git rebase --autosquash' before, but they sound pretty handy. https://jordanelver.co.uk/blog/2020/06/04/fixing-commits-with-git-commit-fixup-and-git-rebase-autosquash/ https://jordanelver.co.uk/blog/2020/06/04/fixing-commits-wit... git-absorb appears to take it one level further. However from the README I'm not clear on exactly what it will do in specific situations: Does git-absorb automatically associate the most recent commit unique to a branch for a given file and apply the diff to said commit? Or what is the precise workflow and outcome in terms of which edits go into which commits?