Re: Is rebase always destructive?

[Johan Herland <johan@herland.net>]

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, <johan@herland.net>
www.herland.net