From: Johan Herland Date: Mon, 01 Dec 2008 11:54:35 GMT Subject: Re: Is rebase always destructive? Message-ID: <200812011254.36109.johan@herland.net> In-Reply-To: On Monday 01 December 2008, Csaba Henk wrote: > Hi, > > When doing a rebase, I can find a number of reasons for which one > might feel like to preserve the rebased branch (that is, perform an > operation which copies the branch over a new base, not moves). > > - For example, a successful rebase doesn't necessarily mean that the > code, as of the rebased branch, is consistent and compiles. That > is, the rebase can be broken even if git can put things together > diff-wise. In such a case I wouldn't be happy to lose the original > instance of the branch. > > - Or I might want to build different versions of the program, and > each version of it needs a given set of fixes (the same one). Then > rebasing my bugfix branch is not a good idea, I'd much rather copy it > over all those versions. > > I can't see any option for rebase which would yield this cp-like > behaviour. Am I missing something? Or people don't need such a > feature? (Then give me some LART please, my mind is not yet gittified > enough to see why is this not needed.) Or is it usually done by other > means, not rebase? The operation you refer to as "cp-like" rebase behaviour is equivalent to cherry-picking a range of commits. The latter has been discussed extensively on this list, although I'm not sure any conclusion has been reached. I would also very much like to have this operation available in either form ("git rebase --copy" or "git cherry-pick from..to"), although I'd probably prefer the "git cherry-pick from..to" form. Have fun! :) ...Johan -- Johan Herland, www.herland.net