threads / discuss / 16533

Is rebase always destructive?

Subject: Is rebase always destructive?

## tl;dr

6 messages between Dec 1, 2008 and Dec 1, 2008.

replies: 5people: 5as markdown or json

Csaba Henk· Dec 1, 2008, 11:41 UTC · lore
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

Johan Herland· Dec 1, 2008, 11:54 UTC · re: Csaba Henk · lore

Re: Is rebase always destructive?

On Monday 01 December 2008, Csaba Henk wrote:
Show 22 quoted lines
> 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
Nick Andrew· Dec 1, 2008, 12:11 UTC · re: Csaba Henk · lore

Re: Is rebase always destructive?

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.
Csaba Henk· Dec 1, 2008, 17:37 UTC · re: Nick Andrew · lore

Re: Is rebase always destructive?

On 2008-12-01, Nick Andrew <nick@nick-andrew.net> wrote:
Show 9 quoted lines
> 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

Robin Rosenberg· Dec 1, 2008, 20:19 UTC · re: Csaba Henk · lore

Re: Is rebase always destructive?

måndag 01 december 2008 18:37:43 skrev Csaba Henk:
Show 12 quoted lines
> 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
Andreas Ericsson· Dec 1, 2008, 16:45 UTC · re: Csaba Henk · lore

Re: Is rebase always destructive?

Csaba Henk wrote:
Show 23 quoted lines
> 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

← back to recent threads