Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 18, 2010, 19:33 UTC
Message-ID: <20101018193311.GE6877@burratino>
In-Reply-To: <AANLkTi=tT=AHWhHUw1tWT777ZPjvmTuMjDJ_orHYYN-x@mail.gmail.com>

Sverre Rabbelier wrote:

> On Mon, Oct 18, 2010 at 13:25, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 6 quoted lines

>> Good question.  Ram, I think there was some discussion of this
>> recently in connection with svnrdump, right?  IIRC the suggested
>> method was to use hooks or mine a commits@ mailing list. :(
>
> Hmmm, in that case perhaps we should instead just ignore changed
> history?

Yeah.  It's unpleasant to imagine that

	git clone svn://whatever
	... sneakily change svn repo ...
	... add some new revs on top ...
	cd whatever && git fetch origin

would produce an origin/trunk that does not match any clone of the svn repo at all, but in practice it is not so different from coping with any other upstream that is incurably willing to rewrite history.

Example: downstream tracking an unstable branch
-----------------------------------------------
Suppose I maintain a patchset in the long term, based, for whatever
reason, on git's "next" branch.  Occasionally there is a need to
merge from upstream.  What can one do?

Simple use of "git merge" produces history that is difficult to follow. Time flowing from left to right, "u" denotes upstream commits:

  u --- u --- u [next-2005-01-03]
  |\           \
  | \           A --- o - o ----- B
   \ \                   /       /
    \ u --- u --- u --- u [next-2006-03-27]
     \                         /
      u --- u --- u --- u --- u [next-2009-11-27]

If a person wants to find what changed downstream between A and B, a simple "git log A..B ^origin/next" will unfortunately include the commits from next-2006-03-27 as well.

One option is to rebase whenever upstream does, but that is dangerous because it prevents users from tracking changes in the project long-term.

Another option is to use a "rebasing merge" [1]. The history can be followed without too much trouble if you set up "git log" commands appropriately. Naïve use of "git log" will list (and git will store) multiple copies of every commit, though.

And lastly, one can say "screw upstream" and produce a long-term "next" branch to build on. :) Like this:

 1. git branch long-term-next next-2005-01-03

 2. When "next" is rebased to clean out cruft, advance long-term-next
    to the pre-rebase state.  Luckily such rebases leave a "before" in
    long-term-next and "after" in next with identical content.  Add a
    replace ref to make history easy to follow.

	git diff <after> <before>; # confirm that they really match
	git replace <after> <before>

 3. To advance long-term-next, rewrite commits from upstream.

	git checkout origin/next
	git filter-branch HEAD
	git diff origin/next; # should match
	git push . HEAD:long-term-next; # should be fast-forward

 4. Only merge long-term-next into downstream branches.
 5. Publish the latest replace ref so others can follow the history
    easily.

[1] http://thread.gmane.org/gmane.comp.version-control.msysgit/10264