Re: An alternate model for preparing partial commits

[Theodore Tso <tytso@mit.edu>]

On Fri, Jun 27, 2008 at 08:51:41PM -0000, David Jeske wrote:
> -- Jakub Narebski wrote:
> > git rebase --interactive?
> > Any patch management interface (StGIT, Guilt)?
> 
> Yes, as I said, that set of operations can be performed with git today.
> 
> What git can't do, is let me "supercede" the old DAG-subset, so
> people I shared them with can get my new changes without hurting
> their world. Currently git seems to rely on the idea that "if you
> accept changes into your tree that will be later rebased, it's up to
> you to figure it out". I don't see why that is the case

Because it's fundamentally hard and fraught with danger --- especially
since with git-rebase --interactive you actually can *edit* an
intervening patch, so commits that are based off of a rebased branch
have absolutely no guarantee of correctly applying against the rebased
branch.

If they do apply cleanly, you can use git rebase --onto, but the
possibility of merge conflicts are endless.

The general workflow here is that you simply don't share your git
state until it's been refactored and you're positive that it you've
gotten it right.  Or if you do share, it you do so in a branch where
you tell people --- don't base work off of this!  (i.e., a "pu" branch
like git has.)

As I said earlier, premature sharing is highly over-rated.  And having
people develop against an unstable branch is just extra work for them
anyway.  So commit frequently, and if you want to backup your local
hard drive, push regularly to your own private git repository located
off-machine.  Just don't ask people base any branches off your private
branch until you're ready to publish it in a form after which you
don't do rebase operations.  This works quite well for many projects
and many developers.

						- Ted