Multiple branches and git-svn

After having had several embarrassing occurences with git-svn dcommit,
I think it would not be amiss to mention in the docs just how git-svn
happens to figure out which Subversion remote it is associated with.

One surprising relevation was that this association changed after a
git-rebase.

It may be a general git thing, or it may be git-svn specific, but it
was not exactly what I expected.  And the docs were not really that
helpful.

In particular, man git-svn is completely silent about this.

-- 
David Kastrup

On Aug 15, 2007, at 12:17 PM, David Kastrup wrote:

After having had several embarrassing occurences with git-svn dcommit,
I think it would not be amiss to mention in the docs just how git-svn
happens to figure out which Subversion remote it is associated with.

One surprising relevation was that this association changed after a
git-rebase.

It may be a general git thing, or it may be git-svn specific, but it
was not exactly what I expected.  And the docs were not really that
helpful.

In particular, man git-svn is completely silent about this.

What I do usually is that I look in git log until I see a git-svn-id  
line:
git-svn-id: https://svn.foo.com/svn/project/branches/bar@<rev-SVN>  
<Repository UUID>
AFAIK git-svn dcommit will commit in the branch specified in the last  
git-svn-id.  I also dcommitted in the wrong branch after a rebase  
because I imported commits from another branch and the topmost commit  
in git-log was "pointing to" a different branch.

I hope this helps.

Cheers,

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Benoit SIGOURE [off-list ref] writes:

On Aug 15, 2007, at 12:17 PM, David Kastrup wrote:

quoted

After having had several embarrassing occurences with git-svn dcommit,
I think it would not be amiss to mention in the docs just how git-svn
happens to figure out which Subversion remote it is associated with.

One surprising relevation was that this association changed after a
git-rebase.

It may be a general git thing, or it may be git-svn specific, but it
was not exactly what I expected.  And the docs were not really that
helpful.

In particular, man git-svn is completely silent about this.

What I do usually is that I look in git log until I see a git-svn-id
line:
git-svn-id: https://svn.foo.com/svn/project/branches/bar@<rev-SVN>
<Repository UUID>
AFAIK git-svn dcommit will commit in the branch specified in the last
git-svn-id.  I also dcommitted in the wrong branch after a rebase
because I imported commits from another branch and the topmost commit
in git-log was "pointing to" a different branch.

Sounds insane: apparently one result is that when you do a merge and
dcommit, the commit will go to the branch you merged.

The whole point of merging is to stay on one's current branch.

-- 
David Kastrup

Yes, that's quite true. It took me quite a while to figure that out when I
first started using git-svn, and its non-sensicalness nearly put me off using
git entirely. My workflow at this point is to use git-cherry-pick -e to pull in
any changes from other branches, then delete the git-svn-id line. 

Essentially, merging using git-svn is almost entirely broken, since an
inconsistent tool is worthless - you spend more time figuring out if it's going
to break, and working around the breakage, than you save using it.

Now, I'm not sure this is 100% the fault of git-svn. Perhaps keeping its
metadata about which SVN branch it's connected to isn't the best thing, but
git-merge is doing exactly what you ask for. Perhaps we need a merge command in
git-svn that does the right thing? Although what that right thing would be, I'm
not quite sure.  Either way, there needs to be a BIG GIGANTIC WARNING in the
git-svn manual that if you actually use git for what it claims to be great at
(i.e., merging) you may be in for a world of pain, with your coworkers and boss
coming at you with pitchforks and torches. Especially because there are
so many git users who need to interoperate with SVN.

On Tue, Aug 21, 2007 at 01:04:28PM +0200, David Kastrup wrote:

Benoit SIGOURE [off-list ref] writes:

quoted

On Aug 15, 2007, at 12:17 PM, David Kastrup wrote:

quoted

After having had several embarrassing occurences with git-svn dcommit,
I think it would not be amiss to mention in the docs just how git-svn
happens to figure out which Subversion remote it is associated with.

One surprising relevation was that this association changed after a
git-rebase.

It may be a general git thing, or it may be git-svn specific, but it
was not exactly what I expected.  And the docs were not really that
helpful.

In particular, man git-svn is completely silent about this.

What I do usually is that I look in git log until I see a git-svn-id
line:
git-svn-id: https://svn.foo.com/svn/project/branches/bar@<rev-SVN>
<Repository UUID>
AFAIK git-svn dcommit will commit in the branch specified in the last
git-svn-id.  I also dcommitted in the wrong branch after a rebase
because I imported commits from another branch and the topmost commit
in git-log was "pointing to" a different branch.

Sounds insane: apparently one result is that when you do a merge and
dcommit, the commit will go to the branch you merged.

The whole point of merging is to stay on one's current branch.

-- 
David Kastrup

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Dave Watson

David Watson [off-list ref] writes:

Yes, that's quite true. It took me quite a while to figure that out
when I first started using git-svn, and its non-sensicalness nearly
put me off using git entirely. My workflow at this point is to use
git-cherry-pick -e to pull in any changes from other branches, then
delete the git-svn-id line.

Essentially, merging using git-svn is almost entirely broken, since
an inconsistent tool is worthless - you spend more time figuring out
if it's going to break, and working around the breakage, than you
save using it.

Full agreement.

Now, I'm not sure this is 100% the fault of git-svn. Perhaps keeping
its metadata about which SVN branch it's connected to isn't the best
thing, but git-merge is doing exactly what you ask for.  Perhaps we
need a merge command in git-svn that does the right thing?

Git svn needs to recognize a merge for what it is, and has to ignore
the branch which has been merged, looking further for git-svn-id lines
or whatever.  Cherrypicking is harder to contain.  Basically, I think
it is a mistake to use something as fragile as the git-svn-id line in
the log for determining the branch to use for committing.  Instead, a
fixed association of git branches with git-svn should be established.
Even if one needs to write this manually into some configuration file.
Before git-svn does not have reliable information, it should refuse to
commit.  One could specify this on the command line, too: that is a
small price to pay for being sure that one commits where one wants to.

Although what that right thing would be, I'm not quite sure.  Either
way, there needs to be a BIG GIGANTIC WARNING in the git-svn manual
that if you actually use git for what it claims to be great at
(i.e., merging) you may be in for a world of pain, with your
coworkers and boss coming at you with pitchforks and
torches. Especially because there are so many git users who need to
interoperate with SVN.

Yes.

-- 
David Kastrup

David Kastrup [off-list ref] writes:

David Watson [off-list ref] writes:

quoted

Yes, that's quite true. It took me quite a while to figure that out
when I first started using git-svn, and its non-sensicalness nearly
put me off using git entirely. My workflow at this point is to use
git-cherry-pick -e to pull in any changes from other branches, then
delete the git-svn-id line.

Essentially, merging using git-svn is almost entirely broken, since
an inconsistent tool is worthless - you spend more time figuring out
if it's going to break, and working around the breakage, than you
save using it.

Full agreement.

quoted

Now, I'm not sure this is 100% the fault of git-svn. Perhaps keeping
its metadata about which SVN branch it's connected to isn't the best
thing, but git-merge is doing exactly what you ask for.  Perhaps we
need a merge command in git-svn that does the right thing?

Git svn needs to recognize a merge for what it is, and has to ignore
the branch which has been merged, looking further for git-svn-id lines
or whatever.  Cherrypicking is harder to contain.  Basically, I think
it is a mistake to use something as fragile as the git-svn-id line in
the log for determining the branch to use for committing.  Instead, a
fixed association of git branches with git-svn should be established.
Even if one needs to write this manually into some configuration file.
Before git-svn does not have reliable information, it should refuse to
commit.  One could specify this on the command line, too: that is a
small price to pay for being sure that one commits where one wants to.

PostScriptum: that is probably all nonsense.  git-svn fetch knows what
to fetch, and probably also what to merge (this should be quite
similar to git pull's behavior), and git-svn rebase/dcommit should not
do anything different.

-- 
David Kastrup

On Tue, Aug 21, 2007 at 11:56:11AM +0000, David Watson wrote:

Now, I'm not sure this is 100% the fault of git-svn. Perhaps keeping its
metadata about which SVN branch it's connected to isn't the best thing, but
git-merge is doing exactly what you ask for. Perhaps we need a merge command in
git-svn that does the right thing? Although what that right thing would be, I'm
not quite sure.  Either way, there needs to be a BIG GIGANTIC WARNING in the
git-svn manual that if you actually use git for what it claims to be great at
(i.e., merging) you may be in for a world of pain, with your coworkers and boss
coming at you with pitchforks and torches. Especially because there are
so many git users who need to interoperate with SVN.

  IMHO here is what git-svn should do. It should use the not-so-new
remotes mechanism, and have all the svn remotes branches under a remote
namespace, clean, simple, and also knowing which "upstream" svn "thing"
it's following.

  Then, when you just git checkout --track -b <branch> <svn-remote/foo>

  hack hack hack
  git commit
  hack hack hack
  git commit
  git merge <svn-remote/another-branch>
  hack hack hack
  git commit

  and then you just want to:

  git svn dcommit.

  Using the fact that <branch> tracks <svn-remote/foo> and that
<svn-remote/foo> is in fact the plain mirror of upstream's branch foo,
it should be able to know where to actually commit and wrt what it has
to make history clean.


  IMHO a git-$scm gateway just has to feed "remotes" branches, and
provide some plumbing commands (like dcommit) to be able to feed some
changes to the other $scm, with a workflow like this one:

  1. pull $scm into a shadow git repository
  2. import/merge $scm changes into your local branch
  3. make changes / merges whatever
  4. push $scm..<yourbranch> into $scm
  5. goto 1, so that you can "win" your changes from 4. back in the $scm
     local shadow repository.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

On Aug 21, 2007, at 5:12 PM, Pierre Habouzit wrote:

On Tue, Aug 21, 2007 at 11:56:11AM +0000, David Watson wrote:

quoted

Now, I'm not sure this is 100% the fault of git-svn. Perhaps  
keeping its
metadata about which SVN branch it's connected to isn't the best  
thing, but
git-merge is doing exactly what you ask for. Perhaps we need a  
merge command in
git-svn that does the right thing? Although what that right thing  
would be, I'm
not quite sure.  Either way, there needs to be a BIG GIGANTIC  
WARNING in the
git-svn manual that if you actually use git for what it claims to  
be great at
(i.e., merging) you may be in for a world of pain, with your  
coworkers and boss
coming at you with pitchforks and torches. Especially because  
there are
so many git users who need to interoperate with SVN.

  IMHO here is what git-svn should do. It should use the not-so-new
remotes mechanism, and have all the svn remotes branches under a  
remote
namespace, clean, simple, and also knowing which "upstream" svn  
"thing"
it's following.

Isn't what git-svn already does if you git-svn clone with `-T trunk - 
b branches -t tags'?  At least in my git-svn repositories I do see  
the SVN branches as remote branches with `git branch -r'

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

On Aug 21, 2007, at 1:56 PM, David Watson wrote:

Yes, that's quite true. It took me quite a while to figure that out  
when I
first started using git-svn, and its non-sensicalness nearly put me  
off using
git entirely. My workflow at this point is to use git-cherry-pick - 
e to pull in
any changes from other branches, then delete the git-svn-id line.

Essentially, merging using git-svn is almost entirely broken, since an
inconsistent tool is worthless - you spend more time figuring out  
if it's going
to break, and working around the breakage, than you save using it.

To me this sounds exaggerated, I fell in the pitfall once after a git- 
rebase but never had the problem again since then.

Now, I'm not sure this is 100% the fault of git-svn. Perhaps  
keeping its
metadata about which SVN branch it's connected to isn't the best  
thing, but
git-merge is doing exactly what you ask for. Perhaps we need a  
merge command in
git-svn that does the right thing? Although what that right thing  
would be, I'm
not quite sure.  Either way, there needs to be a BIG GIGANTIC  
WARNING in the
git-svn manual that if you actually use git for what it claims to  
be great at
(i.e., merging) you may be in for a world of pain, with your  
coworkers and boss
coming at you with pitchforks and torches. Especially because there  
are
so many git users who need to interoperate with SVN.

IMO the only think that git-svn dcommit needs is an option to specify  
to which SVN branch you want to commit in case you want your commit  
to go in another branch than that specified in the last git-svn-id line.

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory