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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html