I assume you refer to https://github.com/torbiak/git-autofixup. I have also used it, and its ok but not perfect.

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.

> 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.

you're probably using an old version

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.

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).

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.

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

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.

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

> 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.

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.