[seba_dos1]

> (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it)

Not sure if you realize, but a commit is a state of all files in the repository, not a patch. Patches are calculated for you at display time (and can be calculated against any other commit, not just a parent). Sounds like you may be confused because of trying to apply a wrong mental model of how the repository represents things.

I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard.

[tempay]

> I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard.

I agree that the model does but I’m not aware of any good way of using such a workflow with the CLI either. Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?

[pravus]

> Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?

This is the problem. You cannot rebase with a stacked PR flow. The correct way to do this is use the merge command as intended.

One of the most powerful features of git is the ability to understand a common history between multiple parties and everyone throws this away entirely with a rebase and causes non-stop conflicts. I simply do not understand the preference for it, especially in shared repos.

Do not use a rebase workflow with any work that is shared with others unless you are communicating regularly and understand how obliterating your commit history will change how git views what is changed between two repositories. Rebase only works well if you are in a leaf branch you control and even then I prefer a single squash merge back into upstream rather than multiple rebases if possible.

I can't even tell you how much of my life has been lost correcting merge conflicts caused by bad rebasing of my commits by others.

[kps]

> Not sure if you realize, but a commit is a state of all files in the repository, not a patch.

I think that's a core problem. It's not just that git calculates a patch to show you, it's that — in every git-using project I've seen — a developer writes a patch, and writes a commit message describing that patch. It's not just github. And then developers make the incorrect assumption that git's later presentation of the commit as a patch matches the original patch and is accurately described by the commit message.

[seba_dos1]

The developer never writes a patch when using git. The developer creates a new repository state, links it to a parent state (or multiple parent states) and describes the difference between these states in the commit message. A patch form is just a handy way to visualize these changes.

You can dump commits into patches and then apply them onto different repositories, but in order to do that you still have to convert such patch into a new repository state first.

Many people "learn" git by learning which commands to use to do some things and in turn don't understand what's going on at all. It's like learning how to write a letter by reading Word's manual.