git svn dcommit <branch> committed to trunk anyway

git svn dcommit <branch> committed to trunk anyway

[Jon Seymour]

I expected git svn dcommit <branch> to push commits into the svn
branch called <branch> (a repo relative URL of
/branches/foobar1/foobar2/<branch>)

However, it decided to push into trunk instead, which was not the
intended effect.

What have I misunderstood about how git svn dcommit is supposed to work?

jon.

Re: git svn dcommit <branch> committed to trunk anyway

[Thomas Rast]

Jon Seymour <jon.seymour@gmail.com> writes:

> I expected git svn dcommit <branch> to push commits into the svn
> branch called <branch> (a repo relative URL of
> /branches/foobar1/foobar2/<branch>)
>
> However, it decided to push into trunk instead, which was not the
> intended effect.
>
> What have I misunderstood about how git svn dcommit is supposed to work?

Did the commits you dcommitted have any git-svn-id lines?  It dcommits
(or at least it's supposed to :-) in the directory listed in the
git-svn-id line found by (roughly)

  git log --first-parent -1 --grep=^git-svn-id:

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: git svn dcommit <branch> committed to trunk anyway

[Jon Seymour]

On Mon, May 7, 2012 at 3:14 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> I expected git svn dcommit <branch> to push commits into the svn
>> branch called <branch> (a repo relative URL of
>> /branches/foobar1/foobar2/<branch>)
>>
>> However, it decided to push into trunk instead, which was not the
>> intended effect.
>>
>> What have I misunderstood about how git svn dcommit is supposed to work?
>
> Did the commits you dcommitted have any git-svn-id lines?  It dcommits
> (or at least it's supposed to :-) in the directory listed in the
> git-svn-id line found by (roughly)
>
>  git log --first-parent -1 --grep=^git-svn-id:
>

None of the commits that dcommit committed to svn had such lines, but
the immediately preceding commit did, and that commit referred to the
trunk URL, rather than the branch URL.

I guess I am confused by this guidance in git-svn(1) in the section on dcommit:

    "An optional revision or branch argument may be specified, and
causes git svn to do all work on that revision/branch instead of
HEAD":

I had assumed that dcommit would respect the optional (SVN branch)
argument that I had specified, but it seems that this is not the case.
What do the words in the man page actually mean, if they don't mean
what I thought they meant.  Do the words "optional revision or branch"
actually refer to the git commit/branch rather than the SVN
revision/branch?

Regards,

jlon.


> --
> Thomas Rast
> trast@{inf,student}.ethz.ch

Re: git svn dcommit <branch> committed to trunk anyway

[Thomas Rast]

Jon Seymour <jon.seymour@gmail.com> writes:

> I guess I am confused by this guidance in git-svn(1) in the section on dcommit:
>
>     "An optional revision or branch argument may be specified, and
> causes git svn to do all work on that revision/branch instead of
> HEAD":
>
> I had assumed that dcommit would respect the optional (SVN branch)
> argument that I had specified, but it seems that this is not the case.
> What do the words in the man page actually mean, if they don't mean
> what I thought they meant.  Do the words "optional revision or branch"
> actually refer to the git commit/branch rather than the SVN
> revision/branch?

Oh, now I understand.  Yes, specifying a revision C there acts mostly as
if you said

  git checkout C^0
  git svn dcommit
  git checkout -

(IIRC, I haven't used it in a while).

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: git svn dcommit <branch> committed to trunk anyway

[Jon Seymour]

On Mon, May 7, 2012 at 5:46 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
> Oh, now I understand.  Yes, specifying a revision C there acts mostly as
> if you said
>
>  git checkout C^0
>  git svn dcommit
>  git checkout -
>

Ok, I see my mistake - I had created the branch in SVN (using external
means, since git svn branch doesn't use an HTTP proxy), had failed to
fetch and then rebase my work onto remotes/<branch> and do the commit
from there. If I had done that, it would have worked as expected.

Thanks for your help.