On Mon, Dec 20, 2010 at 11:39 AM, Eric Seidel <e...@webkit.org> wrote:
> WARNING: This setup seems to have a race which can get your
> repository into an inconsistent state. It's happened now 3 times on 2
> of our commit bots:
> https://bugs.webkit.org/show_bug.cgi?id=50825#c16
>
> Your repository gets into a state where git svn rebase fails to apply
> the rebase from upstream. It's unclear what causes this, but once
> your'e in it, you have to:
> git rebase --abort
> git svn reset KNOWN_GOOD_REVISION
> git rebase --hard KNOWN_GOOD_GIT_HASH
>From the mail that you were quoting:
>>>>> There's a catch: if you "git svn fetch", that creates new commits
>>>>> locally. When you later "git pull", you get the commits that were
>>>>> constructed by git.webkit.org, which don't match (due to differing
>>>>> timestamps). This may screw up rebase, but I believe it's smart
>>>>> enough to recognize the commits are "the same" (applied the same diff;
>>>>> in git jargon, they have the same patch-id).
I guess that rebase does get screwed up. It doesn't surprise me too
much, since you're getting commits from two different places
(git.webkit.org, svn.webkit.org) and rebase is throwing away history.
On the other hand, the rebase manpage says:
The commits that were previously saved into the temporary area
are then reapplied to the current
branch, one by one, in order. Note that any commits in HEAD
which introduce the same textual changes
as a commit in HEAD..<upstream> are omitted (i.e., a patch
already accepted upstream with a different
commit message or timestamp will be skipped).
Maybe it's some sort of ChangeLog conflict. Shrug. I've used this
setup to work on Chrome and WebKit for over a year now and it works
fine for me, but I don't use rebase.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
