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