Re: An alternate model for preparing partial commits

From: Theodore Tso <tytso@mit.edu>
Date: Jun 28, 2008, 01:23 UTC
Message-ID: <20080628012305.GC15463@mit.edu>

On Fri, Jun 27, 2008 at 08:51:41PM -0000, David Jeske wrote:

Show 11 quoted lines

> -- 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