Bug#557477: git-svn: git svn dcommit doesn't handle network failure
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jan 9, 2010, 07:57 UTC
- Message-ID
- <20100109075743.GA3377@progeny.tock>
- In-Reply-To
- <20100109021347.GA26520@dcvr.yhbt.net>
Eric Wong wrote:
Show 5 quoted lines
> 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