On Fri, 02 Sep 2011 12:01:09 -0700 Sam Vilain <sam@xxxxxxxxxx> wrote: > That's one way to do it; in fact, if the trees match you don't need > to do anything complicated like cherry-pick. > > ie, say you're committing > > r1---A---B---C---D > > and it blows up at > > r1--r2--r3--C---D > > So long as the tree from the fetched r3 == the tree from B, then you > can just go ahead and write out new commits for C and D without doing > any merging (ie cherry-pick or rebase). You could also put merge > commits back the way they were, too. When you say "write out new commits" you mean create a commit object with the same contents, but a different parent? Does git-svn do this somewhere already? > If they don't match, then something went wrong with the push really, > or there is something weird going on. I'd try to avoid using cherry > pick automatically in situations like this. There are too many error > modes, and if it only happens when you don't know what's going on, > it's not a good idea to try to fix that. If it /is/ a sufficiently > unlikely error (ie, the trees not matching as above), then it would > be better to simply bomb out and provide two commands: > > * a 'git reset' command to restore to previous state (ie, before the > dcommit) > * a 'git rebase' command to attempt to put the new history on top of > the new upstream. Rebase doesn't work with merges of course but it > still should help the user figure out what to do. > > Another benefit of this approach is that you don't need to muck with > the WC + index at all, no matter what happens. All of the above sounds good to me. I haven't taken the time to understand how git-svn sends changesets upstream (I only know it mucks with the WC from empirical experience) so I don't know how easy it would be to change the methodology, though. Would this also mean we could dcommit from a dirty checkout? Having to stash/unstash is a nuisance. > Sam > -- 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