What does HackerNews think of git-absorb?

Nice, no need to look up past commits ! Didn't know about this, I had to look it up.

It's a separate project from git [0].

[0]: https://github.com/tummychow/git-absorb

Boy have I got the thing for you. git absorb - https://github.com/tummychow/git-absorb

The way to work with it is:

    git add file1
    git commit -m "Fix some bug in file1"
    git add file2
    git commit -m "Add a feature flag for file1"
    # Oh no, first commit was borked, need to fix it
    git add file1
    git absorb
    # this will now automatically create one or more fixup commits
    git rebase -i --autosquash $(git merge-base master)
    # voila, tidy history and each commit works

I agree the parent comment is making a great point, but I disagree with its conclusion that "curating the past is wasted effort", because it is tremendously useful if done right, whereas thinking that way creates the problem --a bad history is useless. You can argue the same about documentation, bad documentation is not read, so it is useless to write it (well, in fact you have to write it properly).

The definition of curate is 'to apply selectivity and taste to' a collection, so I'd say it does mean both. I have not built a theory of what is the most useful, but let's take the two extremes. On the one end you have "push only development", that commit bad program states and all their fixes. It's bad because it adds way to much noise to the history. On the other end, you have 'squash only' development, where one polished feature is pushed in one commit. It's a huge diff that carry little more information than the code itself, and loses all subfeatures milestones and discussions, therefore it is mostly useless.

In a way, imagine you have to teach something by demonstration. You don't want the student to get lost by you screwing up the details. You also need to chunk that information into a set of simpler and well-articulated parts. If done well, your git history carries the information of your process in a very similar way.

You have to be somewhere in the middle, so I'd say to do a semantic rebase at last step before merge. A fantastic tool that is not so well-known is git-absorb, which helps a lot doing that cleanly and automatically.

https://github.com/tummychow/git-absorb

Absorb is amazing! Even if you don't take up Sapling, there's a 'git absorb' plugin which I have found absolutely invaluable: https://github.com/tummychow/git-absorb

That sounds much like git absorb. See https://github.com/tummychow/git-absorb

if you do this often and want some automation, `git absorb` [1] may be worth a look. it will try to find lines that can be unambiguously attributed to a diff based on when the line and its surrounding lines are last modified, and then generate fix-up commits or amend existing ones.

[1]: https://github.com/tummychow/git-absorb

Just looked at hg absorb. It seems like a very useful feature but I understand it is an extension by Facebook. Can't someone make a similar extension for git?

...and I just found it: https://github.com/tummychow/git-absorb

Untangling is what I mostly do. I consider the untangling my own internal code review. I need to read my own diff and figure out what goes where and what each part does and why it's necessary. My commit messages are then my own code review comments.

I figure if I don't carefully read my own diff, why would anyone else? And once it's untangled, I am hoping others will find it easier to read too.

Git doesn't provide as many tools as I would like to make this process easier. It's partly why I don't use git. Mercurial's absorb command helps a lot: it absorbs changes from your working directory into the appropriate draft commit that corresponds to the same context:

https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...

Wait, it appears someone finally ported it to git:

https://github.com/tummychow/git-absorb