4 ms·

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

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.

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.