5 ms·

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 ma

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.
    - masklinn 2y ago
      > that's what it should do No it is not. > How? I don’t know, that’s just an observation from using it, semi regularly I autofixup changes and it takes a while to do anything.
      - krobelus 2y ago
        you're probably using an old version
- Degorath 2y ago
  GitHub's quirks definitely make life much harder than it needs to be, but I've been using `git machete` for months now with great success in my team. The __one__ thing GitHub has that makes it all work is the fact that if you merge the parentmost branch, its immediate child will retarget its base branch. I think if I had full "control" over my company's SCM workflows I would use a tool that considers a branch as a workspace and every commit in the branch becomes its own PR (personal preference, but in my experience it also motivates people to split changes more), but alas.
- keybored 2y ago
  The term Stacked PRs already sounds like a term that was invented specifically in order to communicate in a GitHub-influenced context. Because Stacked PRs are just a reinvention of being able to review a commit at a time (the stack part is straightforward).
  - masklinn 2y ago
    Stacked PRs is a way to surface the lifetime of the proposition as they get fixed or updated following reviews. It has nothing to do with github.
    - keybored 2y ago
      It has nothing to do with GitHub in the sense that GitHub does not support it (I guess, I’m not up to touch). It does have something to do with GitHub in the sense that the name (PRs) and the benefits are framed from the standpoint of This is What GitHub Lacks. Which is a GitHub-centric perspective. https://news.ycombinator.com/item?id=41514663 https://news.ycombinator.com/item?id=41514663
  - travisb 2y ago
    Stacked PRs are like being able to review a commit at a time, but add an additional layer of sequencing. It's most simply thought of as a patch series, where the evolution of each 'patch' is retained. That additional layer allows finer grained history and to mostly avoid (unreviewed) rebasing. Many teams find those properties valuable.
    - keybored 2y ago
      In this day and age I don’t understand why we just can’t call tings commits instead of patches or changesets. I guess another pet peeve for me. https://news.ycombinator.com/item?id=41659650 https://news.ycombinator.com/item?id=41659650
- burntsushi 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? I haven't used autofixup, but: * git-absorb has always been pretty snappy. I don't think it scales with repository size. * If there's no match, then the things that don't match stay in the staging area and don't make it into a commit. git-absorb will also note this in its output after running it.
- dawg 2y ago
  Same workflow here, and it's become a breeze with autofix, rebase --update-refs, and a small command to push the whole stack. I'm using magit, so I directly see what could not be matched and remains staged.
notlinus 2y ago
Criticism isn't negativity. We're not Pollyannas here, we're adults who can handle critique.
- tpoacher 2y ago
  I had to look up the reference, and based on the wikipedia plot summary at least, I admit I don't quite get the relevance. I expected a plot where someone handles criticism quite badly and suffers as a result, but in fact the plot was actually about someone who handled criticism very well instead, and improved the lives of others as a result? So now I'm curious! In what way does Pollyanna relate to adults who can't handle critique? Have I got the wrong Pollyanna by any chance? xD
  - unkulunkulu 2y ago
    I’ve also thought about that based on the same info, i.e. not reading the source completely. There is a notion of a “Pollyanna mode” in schematherapy. What it means is ignoring negative facts and challenges with an outwardly positive attitude and avoiding addressing the issues themselves. This certainly can be harmful to oneself. Another harmful thing is hating and bashing oneself for mistakes and faults and I won’t make a comparative judgement, but a healthy way is supposed to be along the lines of speaking up openly about what bothers you and thinking what can be done about it if at all.
    - tpoacher 2y ago
      This makes sense. Thank you for your comment! Learnt something new today :)
  - talideon 2y ago
    A Pollyanna is somebody who's cheerful and optimistic to a fault, i.e., even when it's unjustified. The plot summary of the book is likely not what you should be reading as it's become an idiom. Something like Wiktionary or another dictionary would be a better place to look it up. In this case, it's not about being able to receive criticism, but about being reticent about _giving_ it.
menaerus 2y ago
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 > You have fixes for the bugs, but you don't want to shove them all into an opaque commit that says fixes So my understanding is that bugs were found in the PR and now you want to fix those bugs by not introducing separate "Fix A", "Fix B" and "Fix C" commits but you want to rewrite the history of existing N commits into N' commits so that it blends those A, B and C fixes in. Maybe I can see this being somewhat useful only ever if those N commits are pushed either directly as series as patches to the main branch or as a single merge commit, and you want to keep the S/N ratio reasonable. But otherwise I think it's a little bit problematic since it makes it harder for the reviewer to inspect and understand what changes have been done. But it also makes it harder for a developer since not all fixes are context-free, e.g. a fix for an issue found in the PR cannot always be attributed to the self-contained and single commit in your branch but it's the composition of multiple commits that actually makes this bug appear.
- beart 2y ago
  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.
  - barbazoo 2y ago
    You're right, most places I've worked this applies only to a subset of branches, usually main/master and sometimes other branches considered "stable" such as for the staging env.
  - codetrotter 2y ago
    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.
JeremyNT 2y ago
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.
- burntsushi 2y ago
  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.

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.
  - masklinn 2y ago
    > that's what it should do No it is not. > How? I don’t know, that’s just an observation from using it, semi regularly I autofixup changes and it takes a while to do anything.
    - krobelus 2y ago
      you're probably using an old version
Degorath 2y ago
GitHub's quirks definitely make life much harder than it needs to be, but I've been using `git machete` for months now with great success in my team. The __one__ thing GitHub has that makes it all work is the fact that if you merge the parentmost branch, its immediate child will retarget its base branch. I think if I had full "control" over my company's SCM workflows I would use a tool that considers a branch as a workspace and every commit in the branch becomes its own PR (personal preference, but in my experience it also motivates people to split changes more), but alas.
keybored 2y ago
The term Stacked PRs already sounds like a term that was invented specifically in order to communicate in a GitHub-influenced context. Because Stacked PRs are just a reinvention of being able to review a commit at a time (the stack part is straightforward).
- masklinn 2y ago
  Stacked PRs is a way to surface the lifetime of the proposition as they get fixed or updated following reviews. It has nothing to do with github.
  - keybored 2y ago
    It has nothing to do with GitHub in the sense that GitHub does not support it (I guess, I’m not up to touch). It does have something to do with GitHub in the sense that the name (PRs) and the benefits are framed from the standpoint of This is What GitHub Lacks. Which is a GitHub-centric perspective. https://news.ycombinator.com/item?id=41514663 https://news.ycombinator.com/item?id=41514663
- travisb 2y ago
  Stacked PRs are like being able to review a commit at a time, but add an additional layer of sequencing. It's most simply thought of as a patch series, where the evolution of each 'patch' is retained. That additional layer allows finer grained history and to mostly avoid (unreviewed) rebasing. Many teams find those properties valuable.
  - keybored 2y ago
    In this day and age I don’t understand why we just can’t call tings commits instead of patches or changesets. I guess another pet peeve for me. https://news.ycombinator.com/item?id=41659650 https://news.ycombinator.com/item?id=41659650
burntsushi 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? I haven't used autofixup, but: * git-absorb has always been pretty snappy. I don't think it scales with repository size. * If there's no match, then the things that don't match stay in the staging area and don't make it into a commit. git-absorb will also note this in its output after running it.
dawg 2y ago
Same workflow here, and it's become a breeze with autofix, rebase --update-refs, and a small command to push the whole stack. I'm using magit, so I directly see what could not be matched and remains staged.

notlinus 2y ago

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

tpoacher 2y ago
I had to look up the reference, and based on the wikipedia plot summary at least, I admit I don't quite get the relevance. I expected a plot where someone handles criticism quite badly and suffers as a result, but in fact the plot was actually about someone who handled criticism very well instead, and improved the lives of others as a result? So now I'm curious! In what way does Pollyanna relate to adults who can't handle critique? Have I got the wrong Pollyanna by any chance? xD
- unkulunkulu 2y ago
  I’ve also thought about that based on the same info, i.e. not reading the source completely. There is a notion of a “Pollyanna mode” in schematherapy. What it means is ignoring negative facts and challenges with an outwardly positive attitude and avoiding addressing the issues themselves. This certainly can be harmful to oneself. Another harmful thing is hating and bashing oneself for mistakes and faults and I won’t make a comparative judgement, but a healthy way is supposed to be along the lines of speaking up openly about what bothers you and thinking what can be done about it if at all.
  - tpoacher 2y ago
    This makes sense. Thank you for your comment! Learnt something new today :)
- talideon 2y ago
  A Pollyanna is somebody who's cheerful and optimistic to a fault, i.e., even when it's unjustified. The plot summary of the book is likely not what you should be reading as it's become an idiom. Something like Wiktionary or another dictionary would be a better place to look it up. In this case, it's not about being able to receive criticism, but about being reticent about _giving_ it.

menaerus 2y ago

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 > You have fixes for the bugs, but you don't want to shove them all into an opaque commit that says fixes So my understanding is that bugs were found in the PR and now you want to fix those bugs by not introducing separate "Fix A", "Fix B" and "Fix C" commits but you want to rewrite the history of existing N commits into N' commits so that it blends those A, B and C fixes in. Maybe I can see this being somewhat useful only ever if those N commits are pushed either directly as series as patches to the main branch or as a single merge commit, and you want to keep the S/N ratio reasonable. But otherwise I think it's a little bit problematic since it makes it harder for the reviewer to inspect and understand what changes have been done. But it also makes it harder for a developer since not all fixes are context-free, e.g. a fix for an issue found in the PR cannot always be attributed to the self-contained and single commit in your branch but it's the composition of multiple commits that actually makes this bug appear.

beart 2y ago
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.
- barbazoo 2y ago
  You're right, most places I've worked this applies only to a subset of branches, usually main/master and sometimes other branches considered "stable" such as for the staging env.
- codetrotter 2y ago
  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.

JeremyNT 2y ago

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.

burntsushi 2y ago
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.