Jakub Narebski wrote:
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 ;-)
"git pull --rebase" already has an implementation. Dscho cooked one up
which I've been using since then. It works nicely.
--
Andreas Ericsson andreas.ericsson@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
