Nicolas Pitre wrote: > On Mon, 26 Nov 2007, J. Bruce Fields wrote: > >> I do find that trying to work on top of a constantly rebased branch is >> annoying no matter how I do it. So I sometimes wonder if we shouldn't >> instead be finding ways to avoid the practice. > > I don't think it can't be avoided in many cases. Some stuff gets > rebased because it has to be refined before it is merged in a more > stable and more "official" repository. Working on top of a rebased > branch could be much easier if there was a dedicated command to perform > the local rebase of one's work after a fetch, just like the pull command > does a merge after a fetch, at which point both work flows would be > almost equivalent wrt ease of use. There was idea of 'rebase' merge strategy (which was in some form implemented once under another name: check archives if you want). And there is an idea of --rebase switch git git-pull. What is left is the implementation ;-) -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: 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
