Re: Change in git-svn dcommit semantics?

[Eric Wong <normalperson@yhbt.net>]

Seth Falcon <sethfalcon@gmail.com> wrote:
> Hi Eric,
> 
> I just updated to the latest git/git-svn (on branch 'master') and the
> workflow I've been using no longer seems to work:
> 
>    # review the commits I'm going to send to svn
>    ziti:~/proj/bioc-2.0-git seth$ git log remotes/git-svn..HEAD
>    
>    # now send them
>    ziti:~/proj/bioc-2.0-git seth$ git svn dcommit remotes/git-svn..HEAD
> 
>    fatal: ambiguous argument
>    'refs/remotes/git-svn..remotes/git-svn..HEAD': unknown revision or
>    path not in the working tree.  Use '--' to separate paths from
>    revisions 32768 at /Users/seth/scm/bin/git-svn line 2190
>            main::safe_qx('git-rev-list', '--no-merges', 'refs/remotes/git-svn..remotes/git-svn..HEAD') called at /Users/seth/scm/bin/git-svn line 610
>            main::dcommit('remotes/git-svn..HEAD') called at /Users/seth/scm/bin/git-svn line 197
> 
> 
> At this point, my last commit seems to have been reset (although the
> changes are thankfully still in my working tree).  If this happens to
> you, you can recover the last commit like:
> 
>   git commit -a -v -c ORIG_HEAD

Huh?  safe_qx should've croaked or died, causing git-svn to exit before
it could do any damage (via git-reset or git-rebase).  dcommit is not
called inside any eval blocks, either...

> And it seems that the new interface requires no extra args:
> 
>  git svn dcommit
> 
> The new interface seems ok until things like 
> 
>   git svn dcommit remotes/git-svn..HEAD~2
> 
> are allowed (if ever).  But it would be nice for the failure mode to
> not undo commits :-)
 
Before, the 'remotes/git-svn..HEAD' argument meant absolutely nothing to
dcommit (it silently ignored it).  Nowadays, you only need 'HEAD~2', the
'remotes/git-svn..' is already implied.

	git-svn dcommit HEAD~2

Not specifying any argument implies that it is called with 'HEAD'

--