Sverre Rabbelier wrote:
> On Mon, Oct 18, 2010 at 13:25, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html