Re: Bazaar migration status?

[Stephen J. Turnbull]

Ken Raeburn writes:

 > I may have overstated it a little, but the general recommendation is  
 > that it's a bad idea and should be avoided if possible.  For example,  
 > "git help rebase" tells me so:
 > 
 >         Rebasing (or any other form of rewriting) a branch that
 >         others have based work on is a bad idea:

"Based work on" is the key phrase.  If you *know* nobody has done so,
if you know who has done so and coordinate with them, it's no big
deal, and often the best way to proceed because everybody agrees that
the branch should be rebased, it's just a question of coordinating on
*when*.

In these cases, fixing is a no-op (if there are no downstream users)
or often trivial (just rebase your working branch using the three-head
form of rebase).  And it's cheap to try, just create a temporary
branch or tag to record the head of the branch you've been working on.

Note that eventually you *are* going to have to rebase, too, because
the mainline *will* proceed to use a merged branch even if they rename
it instead of rebasing it.  git can (and now does) automatically warn
you about the situation if there is a rebase: you'll be told that you
can't pull because it's not a fast forward.

It's not clear to me that this is a bad thing.  The alternative is
that upstream creates a new branch to avoid rebasing issues, and some
weeks later you realize that you haven't pulled any new content for
some weeks, and discover that not only have they rebased into conflict
with your work, but also the new branch itself contains a bunch of new
conflicts that you have to catch up to.  Sure, you could carefully
follow the mailing list(s) to find announcements of branches related
to the one you're based off of, but IMHO this is the kind of thing I'd
like to delegate to my VCS.

 >         anyone downstream of it is forced to manually fix their
 >         history. This section explains how to do the fix from the
 >         downstream's point of view. The real fix, however, would be
 >         to avoid rebasing the upstream in the first place.
 > 
 > This sort of ripple effect requiring manual intervention for everyone  
 > downstream seems... rude.

If done without coordination, sure, it's rude.  Somebody who's done
the amount of work that Andreas has done to preserve history is
anything but likely to be rude, though.

 > [I]t seems to be that we *do* want the content to be the same, and
 > all the history info... but we're going to have a complete new
 > version history anyways, because it's how the tools work today.

Hm?  Uh, if the content is the same, then you haven't rebased at all.
In that case, somebody has deliberately changed the metadata of
history (eg, git-filter-branch).  But you can analyze this with the
tools git (uniquely, AFAIK, cf Miles's "Tribute to a VCS" post :-)
provides:

    find-tree () { git log --all --pretty='%T %H' | grep ^$1; }

which you probably want to invoke as

    find-tree `git cat-file commit HEAD | grep ^tree | cut -b6-`

which will find out if there's any commit whose tree is identical to
HEAD's.  Note that if this is the case, you probably can find a whole
branch which is identical to HEAD's branch in terms of content.


Footnotes: 
[1]  I haven't tested it properly, but that's my reading of the docs
for "git-fetch -f".