Ok, I think the key differences in our worklows is that I dont tend to push/pull between repos much and only normally merge between local branches and/or the remote svn branches before dcommiting, and as a result havent run into the merge issues you have because the hashes differing doesnt really matter then.
I seem to recall from previous reading that the different git mirrors ( git.apache.org and github) are actually synced differently, so the behaviour probably also depends on which one you use and how you use it (I only use them for the initial clone, afterwards I'm usually just rebasing against svn rather than the mirror). Robbie On 10 August 2012 20:21, Andrew Stitcher <[email protected]> wrote: > 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] > >
