Re: An alternate model for preparing partial commits

From: David Jeske <jeske@willowmail.com>
Date: Aug 13, 2016, 23:23 UTC
Message-ID: <willow-jeske-01l83mS5FEDjCcUW>
In-Reply-To: <9af502e50806281125v5459f7deuc14256044b3e726@mail.gmail.com>

-- Robert Anderson wrote:

> If I come back to a branch on which there are several
> commits which have not been pushed yet, how do I know which are
> "temporary" and which are "for real" commits?  I cannot.  It is
> impossible.  The information is not there.

This comment resonates with me Robert. Because git's concept of a workspace is a "non-tracking branch", git doesn't automate having "temporary" and "for real" commits intermixed in the workspace, or having more than one "named set of temporary commits".

Imagine if we use git's mechanisms to setup a "p4 change" style workflow. In that workflow, we can have multiple outstanding named changes in the same working-files. This seems simple and reasonable to me, I use it quite a bit in p4. My most common use of it is to prevent myself from accidentally publishing a set of edited files that are supposed to remain local as I'm iterating (I throw them in a "don't submit this yet" pending change).

If we dynamically compose a "workspace" out of 2 temporary "changes" it might look like this:

: /---PQ workspace/1 : |<- Q / change/feature1 : |<---- P change/feature2 : | : --A<--B master

You're working in workspace 1, and you could pretty easily make the equivilant of "git commit -c change/feature2". That would say, "hey, commit this change, and then merge it down to "change/feature2 branch" as R'.

: /---PQ---R workspace/1 : |<- Q / / change/feature1 : |<---- P<---R' change/feature2 : | : --A<--B master

This seems doable, and git's mechanisms would make it pretty easy (though it feels dangerous to me).

You can then merge either change onto the master when it's done. Your little wrapper could give you a "workspace rebase" which could destroy the workspace, rebase all the features, and recompose the workspace. If you want to rebase one of the changes onto the master, again, your wrapper destroys the workspace, rebases and pushes the change, rebases the rest of the changes, and recreates your workspace.

All of that "destroying the workspace" is required because rebase is a change operation which does not contain merge-history. In the setup above, your "change/*" branches are effectively "published to your workspace", so if you rebase either of them, you're technically rebasing something that's published, and "workspace" will be in a world of hurt. Therefore, one solution is to destroy the workspace, making the rebase a valid operation, then recompose it. Personally, I'd like to see rebase made to have merge history, using some kind of "soft-dag-link" that would cause it to work for anyone who had those changes, while not causing the history to show or hold onto those parents.