Re: missing git features

[Andreas Ericsson <ae@op5.se>]

Carl Worth wrote:
> 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.


> 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