Is rebase always destructive?

Is rebase always destructive?

[Csaba Henk]

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?

Thanks
Csaba

Re: Is rebase always destructive?

[Johan Herland]

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

Re: Is rebase always destructive?

[Nick Andrew]

On Mon, Dec 01, 2008 at 11:41:39AM +0000, Csaba Henk wrote:
> 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).

[...]

> I can't see any option for rebase which would yield this cp-like
> behaviour. Am I missing something?

How about this:

git checkout topic
git branch keepme
git rebase master

Your 'topic' branch will now be rebased against master, and due
to the 'keepme' branch pointer at the original topic HEAD, you can
see the original commits before rebasing.

Nick.

Re: Is rebase always destructive?

[Csaba Henk]

On 2008-12-01, Nick Andrew <nick@nick-andrew.net> wrote:
> On Mon, Dec 01, 2008 at 11:41:39AM +0000, Csaba Henk wrote:
>> I can't see any option for rebase which would yield this cp-like
>> behaviour. Am I missing something?
>
> How about this:
>
> git checkout topic
> git branch keepme
> git rebase master

OK, thanks guys, now I'm enlightened (a little bit more than before).

Regards,
Csaba

Re: Is rebase always destructive?

[Robin Rosenberg]

måndag 01 december 2008 18:37:43 skrev Csaba Henk:
> On 2008-12-01, Nick Andrew <nick@nick-andrew.net> wrote:
> > On Mon, Dec 01, 2008 at 11:41:39AM +0000, Csaba Henk wrote:
> >> I can't see any option for rebase which would yield this cp-like
> >> behaviour. Am I missing something?
> >
> > How about this:
> >
> > git checkout topic
> > git branch keepme
> > git rebase master
> 
> OK, thanks guys, now I'm enlightened (a little bit more than before).

And if you forgot to create the keepme branch you can access the previous
version using the topic@{1} or topic@{'1 hour ago'} etc. This uses the reflog
that tracks all "versions" of your branch. Keeping gitk running is nice way
to see previous versions (press F5 after rebase).

-- robin

Re: Is rebase always destructive?

[Andreas Ericsson]

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?
> 

When I feel I'm in any danger of ending up with mis-compiles or whatnot,
I usually do
  git checkout -b try-rebase
  git rebase $target
which does exactly what you want.

For almost all other operations, it's possible to get your previous
branch-pointer back, either by referencing ORIG_HEAD, or the reflogs.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231