5 ms·

For this issue and so many others, everyone should just get comfortable with interactive rebase. Crutches like this trap you in this space of never really learn

by hashkb 6y ago

For this issue and so many others, everyone should just get comfortable with interactive rebase. Crutches like this trap you in this space of never really learning git. And that's a tragedy. All because you're impatient? Afraid?

zimmski 6y ago
Learning rebasing is one thing but wasting hours every week on rebasing because you are doing the same thing over and over again is another. When i do a one line fixup i just do not want to figure out the correct commit and then rebase i just want it to happen because i already know how i would rebase that: you just use git-autofixup or other similar tools discussed here to get it done.
- tomxor 6y ago
  It's possible the other reason is trying to manipulate git history too frequently. Keep in mind this comes from a prolific git history abuser and rebaser... if hacking on a branch, a trail of messy commits is fine, it's your work in progress, it's also useful if you messed up otherwise you are forced to use reflog. Rebase when you are at the final stage of tidying things up and squashing commits down into a legible history, not on every single amendment... for this style of history rewriting rebase is perfect because you have the full power to rearrange rewrite and squash commits.
  - zimmski 6y ago
    Totally agree. I guess what i am trying to say is that learning rebase is a must and powerful tool but if you are doing the same things again and again you should think about automating them and use your thinking-power and time for non-automated things.
  - urxvtcd 6y ago
    I'd disagree. The longer the branch to rebase the larger the chance of conflicts occuring.
  - hashkb 6y ago
    Rebase early and often. Always keep a close eye on upstream while you're working downstream. Otherwise you're making it harder on yourself when you do that final cleanup.
    - tomxor 6y ago
      That's a fair point, if you are working against a fast moving target that forces you to rebase onto it often then you really want a short and simple history... a trail of WIPs or changes on top of changes tend blow up into a cascade of conflicts. However in my original comment I was actually just referring to the scenario where you only want to rewrite history onto the same base, in which case I stand by my suggestion... In fact I find this can be a good strategy if your history has grown and you also need to rebase onto a new upstream - i.e first clean up your history onto the same base with a `git rebase -i current-base` and squash it all down and tidy it up, then do the `git rebase upstream` so you can do conflict resolution with more holistic commit diffs.
- hashkb 6y ago
  Practice. You'll get better and faster. I do it tens of times daily and each fixup takes ten or fifteen seconds.
  - zimmski 6y ago
    Yep. I have that practice too and i thought that was good enough but with git-autofixup and my posted alias i am down to under one second. So it will save you 1-14 sesconds of your life with every fixup you do... unless it cannot be done automatically. Try it and let us know what you think :-)
    - hashkb 6y ago
      Challenge accepted.
      - hashkb 6y ago
        I tried git-absorb (git-autofixup is Perl? Installing things with CPAN needs sudo? Sorry... I don't have a good Perl situation and don't care to have one.) and it did not immediately work correctly. Maybe git-autofixup is better; idk. Also I misunderstood; I'm expected to `git add` before using these tools - after that, the commit/rebase only takes me a few seconds; I already knew what commit it was bound for when I staged the changes.
        torbiak 6y ago
        git-autofixup can also be installed by simply downloading the script[1], giving it execute permissions, and putting it somewhere in your PATH. It needs perl 5.8.4+, which is very old, and only depends on the standard library. Git ships with a Perl interpreter on Windows. If there are any staged changes, git-autofixup only fixes those up and ignores any unstaged ones; otherwise it tries to autofixup all unstaged changes. [1]: https://github.com/torbiak/git-autofixup/blob/master/git-autofixup https://github.com/torbiak/git-autofixup/blob/master/git-aut...
quesera 6y ago
Coming from the other direction, I am very familiar with interactive rebase, and I use it on my working branch all the time before pushing. I am struggling to understand the use case for autofixup and absorb. The descriptions talk about post-code-review changes, which means the branch has been pushed. So are these tools only for a flow that uses force-pushing regularly? I don't think that would be a feature for my teams. We think of code review as an event in time, and changes post-code review should be clearly differentiated from changes pre-code review. Am I missing the point?
- Vinnl 6y ago
  I generally use autosquash when a code review of a PR turns up things I missed, which should have been part of a particular commit on that PR's branch. However, I don't want to amend the previous commit right away if I'd like another review for the new changes. Thus, I do a `git commit --fixup <HEAD|hash>` and push it. I can then ask the review to only look at the new commit, I won't break their local checkouts of the branch, and only when everything's been approved I run `git rebase --autosquash` and then merge it in. (Before I started using autosquash for this, I'd do the same, except I had to figure out at the time of merging onto which commit every new commit had to be fixed up, rather than at the time of writing it.)
  - smaddox 6y ago
    Thanks for the tip!
- vlovich123 6y ago
  I rely on code review tools that can show me the difference between two patch sets. I really love Phabricator for that ability - push a set of commits and each gets a review. Absorb any fixes, push and suddenly each commit has a new version that you can diff against old ones if you care. It makes reviewing the patch set in totality trickier. However, since I’m practice you want individual commits within a set to be standalone ones, I’ve rarely missed the ability.
  - 6y ago
Vinnl 6y ago
This whole article seems to hinge on the fact that you already know how to run an interactive rebase though? As in, I'm very comfortable doing an interactive rebase, but have to figure out the correct commit to fixup on is tedious, so it sounds very useful to me if a tool can help me with that.
- globular-toast 6y ago
  Unfortunately I think fixup commits are one of the least understood parts of git. People seem to confuse them with rebasing. They support rebasing but don't replace it.

by hashkb 6y ago

zimmski 6y ago

Learning rebasing is one thing but wasting hours every week on rebasing because you are doing the same thing over and over again is another. When i do a one line fixup i just do not want to figure out the correct commit and then rebase i just want it to happen because i already know how i would rebase that: you just use git-autofixup or other similar tools discussed here to get it done.

tomxor 6y ago
It's possible the other reason is trying to manipulate git history too frequently. Keep in mind this comes from a prolific git history abuser and rebaser... if hacking on a branch, a trail of messy commits is fine, it's your work in progress, it's also useful if you messed up otherwise you are forced to use reflog. Rebase when you are at the final stage of tidying things up and squashing commits down into a legible history, not on every single amendment... for this style of history rewriting rebase is perfect because you have the full power to rearrange rewrite and squash commits.
- zimmski 6y ago
  Totally agree. I guess what i am trying to say is that learning rebase is a must and powerful tool but if you are doing the same things again and again you should think about automating them and use your thinking-power and time for non-automated things.
- urxvtcd 6y ago
  I'd disagree. The longer the branch to rebase the larger the chance of conflicts occuring.
- hashkb 6y ago
  Rebase early and often. Always keep a close eye on upstream while you're working downstream. Otherwise you're making it harder on yourself when you do that final cleanup.
  - tomxor 6y ago
    That's a fair point, if you are working against a fast moving target that forces you to rebase onto it often then you really want a short and simple history... a trail of WIPs or changes on top of changes tend blow up into a cascade of conflicts. However in my original comment I was actually just referring to the scenario where you only want to rewrite history onto the same base, in which case I stand by my suggestion... In fact I find this can be a good strategy if your history has grown and you also need to rebase onto a new upstream - i.e first clean up your history onto the same base with a `git rebase -i current-base` and squash it all down and tidy it up, then do the `git rebase upstream` so you can do conflict resolution with more holistic commit diffs.
hashkb 6y ago
Practice. You'll get better and faster. I do it tens of times daily and each fixup takes ten or fifteen seconds.
- zimmski 6y ago
  Yep. I have that practice too and i thought that was good enough but with git-autofixup and my posted alias i am down to under one second. So it will save you 1-14 sesconds of your life with every fixup you do... unless it cannot be done automatically. Try it and let us know what you think :-)
  - hashkb 6y ago
    Challenge accepted.
    - hashkb 6y ago
      I tried git-absorb (git-autofixup is Perl? Installing things with CPAN needs sudo? Sorry... I don't have a good Perl situation and don't care to have one.) and it did not immediately work correctly. Maybe git-autofixup is better; idk. Also I misunderstood; I'm expected to `git add` before using these tools - after that, the commit/rebase only takes me a few seconds; I already knew what commit it was bound for when I staged the changes.
      - torbiak 6y ago
        git-autofixup can also be installed by simply downloading the script[1], giving it execute permissions, and putting it somewhere in your PATH. It needs perl 5.8.4+, which is very old, and only depends on the standard library. Git ships with a Perl interpreter on Windows. If there are any staged changes, git-autofixup only fixes those up and ignores any unstaged ones; otherwise it tries to autofixup all unstaged changes. [1]: https://github.com/torbiak/git-autofixup/blob/master/git-autofixup https://github.com/torbiak/git-autofixup/blob/master/git-aut...

quesera 6y ago

Coming from the other direction, I am very familiar with interactive rebase, and I use it on my working branch all the time before pushing. I am struggling to understand the use case for autofixup and absorb. The descriptions talk about post-code-review changes, which means the branch has been pushed. So are these tools only for a flow that uses force-pushing regularly? I don't think that would be a feature for my teams. We think of code review as an event in time, and changes post-code review should be clearly differentiated from changes pre-code review. Am I missing the point?

Vinnl 6y ago
I generally use autosquash when a code review of a PR turns up things I missed, which should have been part of a particular commit on that PR's branch. However, I don't want to amend the previous commit right away if I'd like another review for the new changes. Thus, I do a `git commit --fixup <HEAD|hash>` and push it. I can then ask the review to only look at the new commit, I won't break their local checkouts of the branch, and only when everything's been approved I run `git rebase --autosquash` and then merge it in. (Before I started using autosquash for this, I'd do the same, except I had to figure out at the time of merging onto which commit every new commit had to be fixed up, rather than at the time of writing it.)
- smaddox 6y ago
  Thanks for the tip!
vlovich123 6y ago
I rely on code review tools that can show me the difference between two patch sets. I really love Phabricator for that ability - push a set of commits and each gets a review. Absorb any fixes, push and suddenly each commit has a new version that you can diff against old ones if you care. It makes reviewing the patch set in totality trickier. However, since I’m practice you want individual commits within a set to be standalone ones, I’ve rarely missed the ability.
- 6y ago

Vinnl 6y ago

This whole article seems to hinge on the fact that you already know how to run an interactive rebase though? As in, I'm very comfortable doing an interactive rebase, but have to figure out the correct commit to fixup on is tedious, so it sounds very useful to me if a tool can help me with that.

globular-toast 6y ago
Unfortunately I think fixup commits are one of the least understood parts of git. People seem to confuse them with rebasing. They support rebasing but don't replace it.