* Change in git-svn dcommit semantics?
@ 2006-12-19 21:12 Seth Falcon
2006-12-19 22:09 ` Eric Wong
2006-12-19 23:02 ` Brian Gernhardt
0 siblings, 2 replies; 13+ messages in thread
From: Seth Falcon @ 2006-12-19 21:12 UTC (permalink / raw)
To: git; +Cc: Eric Wong
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-19 21:12 Change in git-svn dcommit semantics? Seth Falcon
@ 2006-12-19 22:09 ` Eric Wong
2006-12-20 3:05 ` Seth Falcon
2006-12-19 23:02 ` Brian Gernhardt
1 sibling, 1 reply; 13+ messages in thread
From: Eric Wong @ 2006-12-19 22:09 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
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'
--
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-19 21:12 Change in git-svn dcommit semantics? Seth Falcon
2006-12-19 22:09 ` Eric Wong
@ 2006-12-19 23:02 ` Brian Gernhardt
2006-12-19 23:57 ` Johannes Schindelin
2006-12-20 3:07 ` Seth Falcon
1 sibling, 2 replies; 13+ messages in thread
From: Brian Gernhardt @ 2006-12-19 23:02 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
On Dec 19, 2006, at 4:12 PM, Seth Falcon wrote:
> git version 1.4.4.2.gee60-dirty
> (the dirty is a hand edit to Makefile for prefix)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-19 23:02 ` Brian Gernhardt
@ 2006-12-19 23:57 ` Johannes Schindelin
2006-12-20 0:38 ` Brian Gernhardt
2006-12-20 3:07 ` Seth Falcon
1 sibling, 1 reply; 13+ messages in thread
From: Johannes Schindelin @ 2006-12-19 23:57 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Seth Falcon, git
Hi,
On Tue, 19 Dec 2006, Brian Gernhardt wrote:
> Mine also has a few variables like "COLLISION_CHECK=paranoid" and my own
> prefix.
Just to wake sleeping tigers: have you done a "grep COLLISION_CHECK *"
recently (where recently means any date after May 3rd, 2005)?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-19 23:57 ` Johannes Schindelin
@ 2006-12-20 0:38 ` Brian Gernhardt
2006-12-20 0:52 ` Jakub Narebski
2006-12-20 1:17 ` Junio C Hamano
0 siblings, 2 replies; 13+ messages in thread
From: Brian Gernhardt @ 2006-12-20 0:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Seth Falcon, git
On Dec 19, 2006, at 6:57 PM, Johannes Schindelin wrote:
>> Mine also has a few variables like "COLLISION_CHECK=paranoid" and
>> my own
>> prefix.
>
> Just to wake sleeping tigers: have you done a "grep COLLISION_CHECK *"
> recently (where recently means any date after May 3rd, 2005)?
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).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-20 0:38 ` Brian Gernhardt
@ 2006-12-20 0:52 ` Jakub Narebski
2006-12-20 1:17 ` Junio C Hamano
1 sibling, 0 replies; 13+ messages in thread
From: Jakub Narebski @ 2006-12-20 0:52 UTC (permalink / raw)
To: git
Brian Gernhardt wrote:
> 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).
git log -p -SCOLLISIONS ?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-20 0:38 ` Brian Gernhardt
2006-12-20 0:52 ` Jakub Narebski
@ 2006-12-20 1:17 ` Junio C Hamano
2006-12-20 11:38 ` Jakub Narebski
1 sibling, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2006-12-20 1:17 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Johannes Schindelin, Seth Falcon, git
Brian Gernhardt <benji@silverinsanity.com> writes:
> 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).
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-19 22:09 ` Eric Wong
@ 2006-12-20 3:05 ` Seth Falcon
0 siblings, 0 replies; 13+ messages in thread
From: Seth Falcon @ 2006-12-20 3:05 UTC (permalink / raw)
To: Eric Wong; +Cc: git
Eric Wong <normalperson@yhbt.net> writes:
> 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...
*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.
> 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
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-19 23:02 ` Brian Gernhardt
2006-12-19 23:57 ` Johannes Schindelin
@ 2006-12-20 3:07 ` Seth Falcon
1 sibling, 0 replies; 13+ messages in thread
From: Seth Falcon @ 2006-12-20 3:07 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
Brian Gernhardt <benji@silverinsanity.com> writes:
> On Dec 19, 2006, at 4:12 PM, Seth Falcon wrote:
>
>> git version 1.4.4.2.gee60-dirty
>> (the dirty is a hand edit to Makefile for prefix)
>
> 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:
Hey, thanks, that's much nicer :-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-20 1:17 ` Junio C Hamano
@ 2006-12-20 11:38 ` Jakub Narebski
2006-12-20 11:47 ` Brian Gernhardt
0 siblings, 1 reply; 13+ messages in thread
From: Jakub Narebski @ 2006-12-20 11:38 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> 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).
>
> 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.
Yet another undocumented option. Sigh...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-20 11:38 ` Jakub Narebski
@ 2006-12-20 11:47 ` Brian Gernhardt
2006-12-20 11:57 ` Jeff King
0 siblings, 1 reply; 13+ messages in thread
From: Brian Gernhardt @ 2006-12-20 11:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Dec 20, 2006, at 6:38 AM, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>> 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.
>
> Yet another undocumented option. Sigh...
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-20 11:47 ` Brian Gernhardt
@ 2006-12-20 11:57 ` Jeff King
2006-12-22 14:09 ` Brian Gernhardt
0 siblings, 1 reply; 13+ messages in thread
From: Jeff King @ 2006-12-20 11:57 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Jakub Narebski, git
On Wed, Dec 20, 2006 at 06:47:45AM -0500, Brian Gernhardt wrote:
> >>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.
> >
> >Yet another undocumented option. Sigh...
>
> 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?
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Change in git-svn dcommit semantics?
2006-12-20 11:57 ` Jeff King
@ 2006-12-22 14:09 ` Brian Gernhardt
0 siblings, 0 replies; 13+ messages in thread
From: Brian Gernhardt @ 2006-12-22 14:09 UTC (permalink / raw)
To: Jakub Narebski, git
On Dec 20, 2006, at 6:57 AM, Jeff King wrote:
> On Wed, Dec 20, 2006 at 06:47:45AM -0500, Brian Gernhardt wrote:
>
>>>> 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.
>>>
>>> Yet another undocumented option. Sigh...
>>
>> 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?
>
> Please read the rest of the thread for some explanation from Junio on
> how this option works.
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2006-12-22 14:09 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-19 21:12 Change in git-svn dcommit semantics? Seth Falcon
2006-12-19 22:09 ` Eric Wong
2006-12-20 3:05 ` Seth Falcon
2006-12-19 23:02 ` Brian Gernhardt
2006-12-19 23:57 ` Johannes Schindelin
2006-12-20 0:38 ` Brian Gernhardt
2006-12-20 0:52 ` Jakub Narebski
2006-12-20 1:17 ` Junio C Hamano
2006-12-20 11:38 ` Jakub Narebski
2006-12-20 11:47 ` Brian Gernhardt
2006-12-20 11:57 ` Jeff King
2006-12-22 14:09 ` Brian Gernhardt
2006-12-20 3:07 ` Seth Falcon
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).