git rebase - can hg do that ?

[Theodore Tso]

On Tue, May 29, 2007 at 07:57:45PM +0200, David Jack Olrik wrote:
> 
> On 29/05/2007, at 16.13, TK Soh wrote:
> 
> >so I wonder how git copes with this kind of changes between clones.  
> >The question is that if we rebase a repo, wouldn't it break the  
> >repos that were cloned before the rebase?
> 
> Well, yes it would break those, and git doesn't handle that either.  
> But thats ok! - rebase is a very powerful tool that should be used  
> with caution, plus it is only meant for your local topic branches.  
> E.g. when you have a long lived branch that you pull from multiple  
> times.

In git you can mark a branch as being one where the branches can be
"rewound" and then moved forward.  This is done by marking it with a
'+' in the clone specifier.  For example, in the config file, the
default is to do something like this:

[remote "origin"]
	url = git://git.kernel.org/pub/scm/git/git.git
	fetch = +refs/heads/*:refs/remotes/origin/*

What this means is that all of the heads on the remote repository are
cloned over to origin/*.  So in Junio's git repository, the "pu" (for
proposed updates) branch, which can go backwards in time if it turns
out some commit had a really embarassing brown-paper bag problem, is
mapped to origin/pu in my local repository.  By convention, the "next"
branch never goes backwards in time.  So changesets migrate from "pu"
to "next" to the "master" branch (which is the head of the "unstable"
branch).

The topic branches also can and will get rebased, but as long as they
are marked with a '+', the right thing happens, and the origin/*
convention really works well to avoid people from getting confused.
It makes the internal branch model of git much easier to use, and it's
really not that hard to get the hang of it.

						- Ted