Eric Wong wrote: > I agree that error recovery for dcommit sucks right now. > > I think Brice's idea (creating a temporary branch to dcommit from) > is easier to implement and less likely to break than automatically > unapplying patches. Sounds sane to me. Probably that temporary branch could just be a detached HEAD. Current dcommit: diff-index --quiet HEAD || carp "Cannot dcommit with a dirty index" if head ne 'HEAD': save the old HEAD check out the head find svn upstream decide what commits to push (linearize_history) for each commit d to push: commit diff from d~ to d to the remote repository (this involves applying the diff locally?) remember parents fetch remote revision, using remembered parents for commit unless args include --no-rebase: rebase the current HEAD against fetched revision (or reset if there are no changes) update the list of commits to push if head ne 'HEAD': let the user know the branch or commit id for the finished dcommit check out the old head again If I understand you correctly, before finding the svn upstream, dcommit would save the HEAD ref name (if any) and detach the HEAD; after pushing the relevant commits, update that ref and reattach the HEAD. If pushing fails early, what should git-svn do? Leave the HEAD detached, with a message suggesting to return to the old ref? Check out the old ref, with a message suggesting to 'git svn rebase' and try again? Do the 'git svn rebase' automatically? I guess the safest option is the first one. That would at least be a starting point for experimenting with more friendly behaviors. I should also mention that there seems to be a little race here: if git-svn dies before (or while) fetching the newly commited revision, when it is fetched later it will have the wrong parents. Jonathan -- 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