[bvrmn]

As usual couldn't recommend stacked git [1] enough. If you prefer CLI it greatly reduces cognitive load about branches/rebases especially if your work with review server allowing to see changes between force pushes (gitlab, gerrit).

[1]: https://stacked-git.github.io/

[swozey]

The idea with this seems to be - I'm working on a branch and can't easily switch right now to put out a patch, or MY current branch HAS the patch and I want to push that out before the entire branch is ready so I make the stg commits and pushes and that patch is released.

In their example [1] at the very end they commit --all of their patches into the main patch and I guess merge that into main.

I'm kind of confused on the commit --all part. If you're putting out single patches like stg committing your current file, what benefit do you get by making multiple patches, not pushing them to main immediately, but holding them as a patch series until you're done to then merge all together? Is it mostly for the developer to keep track of X change = Y patch while you're fixing multiple things?

Like, I'm in a branch right now that unfortunately I've got 3 patches doing different unrelated things. But the changes are in a lot of the same files, so to use this patching I would have to pull out the other 2 patches in the same file, stg commit the one patch, then add patch 2, stg commit patch 2, etc that eventually just commit --all into the same file but are now identifiable by X change = Y patch?

Definitely a lot easier if had I had started out using this and stg committed patch 1 before writing patch 2 and 3.

Am I right about all of this or missing anything, or completely off? I wrote it in another comment but I deal with a lot of massive infrastructure changes where one push is deploying basically entire datacenters of load balancers and clusters, etc. a LOT of files are modified at once, so I'm in repos for a WHILE until I do my push and it makes it very hard for me to switch branches if I need to hop around real quick, I'm super apprehensive about stashing and changing branches in the middle of big PRs but I really couldn't explain why. I always worry I'm going to lose something or forget about the branch, etc.

I could definitely patch on things like, "This patch adds the loadbalancers and routing, this patch adds the cluster, this patch adds the security."

[1] https://stacked-git.github.io/guides/usage-example/

[bvrmn]

You are right about conflicting changes. They are hard to manage as order independent changes with any tool. In stgit context I often split big change into multiple ordered patches and yes I know what piece (incremental edit) should be added to what patch. Classic example: doing refactoring around main task. Refactoring goes into one patch, main changes into another. It allows greatly simplify review process.

But common case for me is to have multiple independent patches for different features/bug fixes. For example one current project has 12 patches, another one has 5 patches. Two or three are dedicated to current work. Rest are drafts with ideas.

> I'm kind of confused on the commit --all part.

Me too. Almost always task is represented by a single patch. And I push changes on patch basis. One patch -> one review.