Re: git svn : some feedback and wonder...

Michael J Gruber wrote:

jean-luc malet venit, vidit, dixit 11.05.2009 17:52:
  

quoted

hi
I'm just toying with git svn....
so I have an svn repository and I do a git svn clone -s
http://path.to/my/repository
here all is fine it checkout my trunk into master branch

1) when I do a git branch -a, it show 2 branches : master and trunk,
shouldn't it be master and svn/trunk?
    

No. Not unless you said --prefix=svn during clone.

  

quoted

2) when I create a branch using git svn branch it create an empty
directory and not as expected a branch from the current revision of
trunk
    

I get a branch as you expect. Can you repeat the commands which
generated an unexpected result for you?

  

quoted

3) the branch appears in git branch -a without a remote
information.... not easy to track
    

See 1)

  

quoted

4) you can't do git branch --track newbranch (where new branch is the
svn branch), since the branch name isn't prefixed by svn/ you can't
reuse the same name
    

You certainly can create a local branch with the same name. I just did.
I always do. If b is that name, say

git branch --track b remotes/b

unless you have used --prefix, of course.

  

quoted

5) why having called dcommit instead of push? it would have been more
understable (more coherent) git svn push would have pushed current
branch on corresponding svn branch and git svn push somebranch would
have do a git svn branch followed by the commits...
    

The latter would be inconsistent with git push as well.

Dcommit may be for historical reasons, but keep in mind that dcommit is
not simply pushing. It involves rebasing and a whole git-svn-git
roundtrip. It really is "do the commits" on the svn side.

  

quoted

6) why having called rebase instead of pull? git svn pull would have
fetched svn/trackedbranch and merged into current branch, git svn pull
somebranch would have merged into current branch the svn/somebranch
(without traking info)
    

Because pull does not rebase by default, it uses merge!

Let me just add that with some more git experience, which includes
reading man pages and trying things out, there certainly will be more
insight into the why's and why not's of git-svn ;)

Cheers,
Michael
  

hi,
can't do it from here, will retry tomorrow
I'll try 1)  2) and 3) again tomorrow, however why --prefix=svn isn't 
the default? that's odd behaviour and not really consitent with other 
remote operation I find
for 4) I think that push works more like dcommit, the underlying process 
isn't the same because svn and git don't share the same tree, but if we 
look at the result we have the same : all commit made on host are 
visible on repository, git do it by transfering the content because all 
blob/tree are sha1 name and then can't conflict, on svn we can't because 
there are no uniqueness so you have to replay the commits one by ones... 
git just optimize the process because of the nature of the filetree...
for rebase.... well I know that some people prefer it to merge, as well 
as some people prefer that a merge to be fast forward... I prefer to 
keep the branch information... it's hard to restart a dev from a branch 
that isn't visible anymore... fast forward merge and rebase sadely do 
lose those branch information... however I agree that in case of svn a 
rebase looks more like an svn update...
and yes, sorry I forgot that the opposite of push is... fetch ;) so yes 
it's more clear now in my mind....
thanks
JLM