From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Fri, 11 Nov 2005 04:58:54 GMT
Subject: Re: tracking a tree that doesn't progress linearly
Message-ID: <46a038f90511102058p6536b17crc7c9f7ce93167934@mail.gmail.com>
In-Reply-To: <17268.3463.252020.591687@cargo.ozlabs.ibm.com>

On 11/11/05, Paul Mackerras <paulus@samba.org> wrote:
> I want to be able to publish a git tree for others to follow but I
> also want to be retain the freedom to remove commits and/or rebase
> commits in the tree.

I sometimes want that too, but git doesn't have a 'rewind' semantics,
and probably for a good reason. The approach I am studying is to
create a thousand throaway short-lived branches. It is safe to publish
them as long as people following your branches _know_ that they'll be
orphaned, and that any commits they have on top of them they'll have
to rebase.

So you could publish your tree with devel-<datestamp> heads, and
announce when you're moving to a newer one. People tracking your
branches can tend register & checkout the new branches, and do a
git-merge to rebase their patches to your new branch, or replay them
with git-format-patch and git-am.

On the other hand, if  StGIT grows better support for sharing patches,
it could make all this look like the stone age.

cheers,


martin