Re: Bazaar migration status?

[Stephen J. Turnbull]

Ken Raeburn writes:

 > The advice I've seen isn't "don't do it too often", it's "don't do  
 > it".

Rebase a copy of the branch instead of the original, if it worries you
so much:

    git checkout -b rebased-branch original-branch
    git rebase master

If you're worried about this, but have no control over the main repo,
there's always

    # proof of concept; may fail spectacularly if you have defaults
    # configured
    git-my-pull () { git branch save-branch; git pull $@; }

Advocacy:

True, you will see "don't ever rebase" a lot from git-phobes.  It
should be considered to be a litmus test for git-phobia, not as
reflecting VCS reality.

In fact, rebasing is such an important operation that *all* of the
dVCSes have been forced by user demand to provide it, and *only git*
provides facilities (ie, the reflog) for recovery from an ill-advised
rebase that can be used by newbies.[1]  AFAIK, all of hg, bzr, and
darcs can *destroy* some DAG data basically irrecoverably, while git
*always* preserves it (until the next git-gc --prune, which by default
is so far in the future that it's of the same order of magnitude as an
Emacs release cycle ... uh, well, I exaggerate, but you get the
point).

Git-advocate-who-has-helped-advise-two-transitions-to-hg-ly y'rs,

Footnotes: 
[1]  Admittedly, untangling a git-rebase is not for wilting violet
newbies, but anybody who has learned to accept dying in Nethack should
be able to handle it -- it's exactly the same experience: you didn't
want it to happen, it will take time and effort to get back to where
you were, but no permanent harm is ever done.