Re: Change in git-svn dcommit semantics?

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

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 :-)

+ seth

git version 1.4.4.2.gee60-dirty

Seth Falcon <sethfalcon@gmail.com> wrote:

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...

 
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'

Eric Wong <normalperson@yhbt.net> writes:

*shrug* weird. Looking at the code, I don't see how I could have seen what I think I did. Reproducing the error in a sandbox doesn't show the git-reset behavior. So unless I can reproduce it, I must have done something else funny. Sorry for the noise.

That's convenient in that it requires less typing. I will try to retrain my fingers. I'm in the habit of reviewing the commits not in svn with:

  git log remotes/git-svn..HEAD

And then editing the command like to be 'svn dcommit' instead of log.

Cheers,

+ seth

On Dec 19, 2006, at 4:12 PM, Seth Falcon wrote:

Just FYI: You can save Makefile variables in a "config.mak" file instead of having to dirty your working tree (and dealing with conflicts, etc). For example:

cat > config.mak <<EOF prefix=/your/prefix/path/here/ EOF

Mine also has a few variables like "COLLISION_CHECK=paranoid" and my own prefix.

Hi,

On Tue, 19 Dec 2006, Brian Gernhardt wrote:

Just to wake sleeping tigers: have you done a "grep COLLISION_CHECK *" recently (where recently means any date after May 3rd, 2005)?

Ciao, Dscho

On Dec 19, 2006, at 6:57 PM, Johannes Schindelin wrote:

Oh, well, that's cute. It's a configuration option that doesn't touch any code at all... Not that I really cared about the check, I just thought it was a nice paranoid thing to activate and I like a certain amount of paranoia in my SCMs. But maybe the description should be removed from the Makefile then? Or better yet, collision checking could be put back in?

And is there an easier way to find these things than "git rev-list HEAD | git diff-tree -r -s --stdin -SCOLLISION | xargs git show"? I cobbled that together from poking around inside gitk (which mostly works in OS X, but has some issues that make me prefer the command line).

Brian Gernhardt wrote:

git log -p -SCOLLISIONS ? 

Brian Gernhardt <benji@silverinsanity.com> writes:

I typically do:

	git log --full-diff -p -SCOLLISION

The --full-diff option helps because it shows the diff for other files (that do not have different number of substring COLLISION in the pre and postimage) in the same commit as well.

Junio C Hamano wrote:

Yet another undocumented option. Sigh...

On Dec 20, 2006, at 6:38 AM, Jakub Narebski wrote:

I'd send in a patch to fix that (little gnome work is what I do in Wikipedia, and seems to be what I do here), but the option seems to be in setup_revision.c:setup_revisions, which is used in several places. Is there a central place to put that in the documentation? Should there be?

On Wed, Dec 20, 2006 at 06:47:45AM -0500, Brian Gernhardt wrote:

Please read the rest of the thread for some explanation from Junio on how this option works.

I think it makes sense to group the porcelain-ish options together for git-log/git-whatchanged (and potentially git-show). Really, they can take any of the diff-options or any of the rev-list options. The rev-list options are not currently grouped for inclusion in another man page. The diff options are available in diff-options.txt, but are not included by the log manpages. They probably should be.

On Dec 20, 2006, at 6:57 AM, Jeff King wrote:

I was trying to write quick documentation for this option, placing it in Documentation/diff-options.txt (is that the right place for it?), when I ran across --pickaxe-all. How do the two options differ?

~~ Brian

Brian Gernhardt <benji@silverinsanity.com> writes:

Hey, thanks, that's much nicer :-)