On Fri, 2012-08-10 at 20:05 +0100, Robbie Gemmell wrote:
> I've seen this mentioned on here in the past, either by yourself or maybe
> Alan, and I'm a bit curious as to what actually happens?
> 
> I cant say I have seen it cause me any problems so far when using git-svn
> (git cloned from the git mirror, then git-svn initialised and rebased
> against svn). Indeed, git-svn doesnt seem to care at all when an incoming
> commit log doesnt match the message for a local commit of the same changes,
> which is a situation I often tend to provoke in checkouts im using by
> changing a message before dcommitting it from another workspace I have
> applied it to. Do you have any special sauce in your git workflow? not
> using git-svn?

I think our definitions of screwed up may be different.

If you rewrite svn history then anyone who has git mirrored on the
previous history gets an entirely different branch from someone who has
history based on the the rewritten history. They will diverge at the
rewrite. In effect git branches are based on a hash of the changes and
the comments. So you lose the ability to simply pull changes from one
repo to the other without some (usually trivial but irritating) merging
going on. We've had this happen in the past to the qpid tree and it
usually takes a while to figure out what's going on and why there are
merges where you didn't expect them.

This situation won't stop the git-svn mirror from working it will just
make the history in some repos different from in some others and make
them somewhat incompatible (ie there will be different SHAs for the same
upstream change.)

I'll note that if you get the change in before the git mirror gets the
changes then all is well, because git never sees the old changes at all,
but it's not clear to me whether the mirroring process is on a fixed
interval basis or whether it is on demand driven by the changes
themselves.

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to