Re: missing git features

From: Andreas Ericsson <ae@op5.se>
Date: Mar 24, 2006, 18:55 UTC
Message-ID: <4424409A.80503@op5.se>
In-Reply-To: <871wwrztaz.wl%cworth@cworth.org>

Carl Worth wrote:

Show 11 quoted lines

> On Fri, 24 Mar 2006 13:59:02 +0100, Andreas Ericsson wrote:
> 
>>See how Junio does with next and pu and recommend your users to do the 
>>same. There's no way of pulling a rebased branch, because the rebasing 
>>destroys ancestry information, meaning the original commits other people 
>>have cease to exist in your repository.
> 
> 
> But the "other people" still have those commits, so it should be
> rather straightforward for a tool to also perform a rebase for them
> when doing this kind of "rebased pull".

Yes they do, but you don't, so their tip won't match yours, meaning their git will try a merge, which will fail since lots of commits are already applied. Perhaps it would be possible to try the blobs against each other, if anyone's interested.

Show 8 quoted lines

> I think there's just a single
> arc of data missing showing where a rebased commit object came from.
> 
> So this sounds solvable, and it is something I would very much enjoy
> having, (call me funny, but I prefer to rebase and avoid a merge
> commit when looking at independent lines of development for which
> logically there shouldn't be any "merge" required).
>

For the cases where no merge is required you could rebase several branches on top of one and simply publish that one. If that's the case, git would need the ability to know what branches are exported and which arne't, which should be a lot simpler than implementing a rebased-merge strategy.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231