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, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
