1. 54
  1. 13

    The clarity of writing in that “Elevator Pitch” section at the start of the readme is wonderful.

    1. 13

      It made no sense to me because I had never heard of the git commit --fixup feature that this simplifies, nor its accompanying feature git rebase -i --autosquash. I have used interactive rebases many times, but knowing only that absorb is an alternative to “running a manual interactive rebase” doesn’t narrow it down much.

      After reading the man pages for those features and reading the three example commands in the README, it makes a little more sense. It wasn’t clear what the README meant by “You have fixes for the bugs” – are those fixes in multiple local commits? – but from the example command git add $FILES_YOU_FIXED I infer that the fixes are in multiple files in my working directory. Then I guess the way absorb breaks apart “each of those changes” is by assuming that each hunk is a separate fix. Anyway, I can figure it out, but it is the opposite of “wonderfully clear” to me.

      Edit: Now that I know that absorb is an alternative to making commits and writing fixup instructions in an interactive rebase (which I have done many times), the linked description of hg absorb on mozilla.dev.version-control seems like a better overview to me:

      Facebook demoed hg absorb which is probably the coolest workflow enhancement I’ve seen to version control in years. Essentially, when your working directory has uncommitted changes on top of draft changesets, you can run hg absorb and the uncommitted modifications are automagically folded (“absorbed”) into the appropriate draft ancestor changesets. […] 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. If the changes can’t be made without conflicts, they remain uncommitted. This workflow is insanely useful for things like applying review feedback. You just make file changes, run hg absorb and the mapping of changes to commits sorts itself out. It is magical.

      1. 3

        This indeed looks amazing, stated in this way.

        1. 1

          Same here. The git description seems too much in terms of various git features which I don’t know while the Mercurial description from Mozilla explains what it actually does.

        2. 5

          Haha, it doesn’t make a lot of sense to me because I don’t know git commands very well, but I’m glad it worked for you. The only reason I know what it’s talking about is because I’ve had it explained to me in Mercurial terms.

        3. 8

          I was having trouble understanding the Elevator Pitch, and then I realized it’s because I use Magit and there is nothing painful to me about squashing or fixing up commits ;)

          1. 3

            Does magit already let you automatically decide which commit should be fixed up based on which commit matches your working directory changes? You don’t have to choose the commit to fixup yourself?

            1. 7

              No, that’s a fair point. There’s no automation to the interface, so there is that. But I also generally only have two or three primary commits that a fix could be targeting, so the cognitive overhead is not great to remember which commit I should be fixing up.

              Really didn’t mean to disparage the work. This is a neat tool, it’s just not relevant to my usual git workflow so I was having trouble grokking the immediate benefit. I get it now, and will surely recommend it to co-workers :)

              1. 4

                And a quote from my engineering lead, “This is awesome.” … which he doesn’t say about a lot things, so high praise, indeed :)

                1. 2

                  Actually it does. Check magit-commit-instant-fixup https://magit.vc/manual/magit/Initiating-a-Commit.html#Initiating-a-Commit

                  But as you said, rebasing is so fast that one tends to just use the default interface

                  1. 2

                    I believe instant-fixup is only for the current commit or one commit at a time. git absorb does more than that: it spreads your working directory changes across all of the appropriate ancestor commits depending on which ancestor corresponds to which part of your working directory changes.

            2. 3

              Oh great, I was thinking about writing this port, but I only was thinking about it. This should get me way closer to the clean commit history I’ve always longed for

              1. 2

                git config --global alias.fixup 'commit --amend -C HEAD' once and then a git fixup after adding new changes has never failed me.

                1. 5

                  That indeed works if you only want to change the last commit; this automatically merges changes into multiple (“draft”) commits.

                  1. 2

                    I hadn’t heard of the -C argument for git commit before. It seems its long form is --reuse-message, and it is one of three related flags that are useful with --amend:

                    • --no-edit – use the same commit message as the amended commit; update the author and timestamp
                    • -c <commit>, --reedit-message=<commit> – use the same commit message as the specified commit; update the author and timestamp
                    • -C <commit>, --reuse-message=<commit> – use the same commit message, author, and timestamp as the specified commit