Bug#557477: git-svn: git svn dcommit doesn't handle network failure

[Jonathan Nieder <jrnieder@gmail.com>]

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