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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Mar 25 05:56:08 2006
This archive was generated by hypermail 2.1.8 : 2006-03-25 05:56:30 EST