Follow up questions for git-svn users

[Brian M Dube <bd...@apache.org>]

I think my setup is standard, from what I gleaned from the GitHub
thread (although github is not part of my workflow). My trunk branch
is remote-tracking, where I use git svn rebase and git svn dcommit.

My first question is about keeping topic branches around and updated
for multiple uses. Perhaps this is a bad idea, but it seems like it
should work. I create my topic branch topic1 with trunk as the
starting point. I do the work, committing along the way, and merge
topic1 into trunk when I'm ready for git svn dcommit. Now I'd like to
continue working from topic1, especially if I squashed the merge to
trunk, so that I have access to the history lost by the squash. But
when I use git svn rebase to update trunk, a merge from trunk back
into topic1 makes my history look wrong in gitk.

What I'm trying to do is get the changes that were not part of my own
commit (anything I pulled down with git svn rebase) back into my topic
branch. It seems like it should be a normal fast-forward, but it's
recursive and the history doesn't look right. I abandon the branch at
this point and start a new one for further work.

The second question, what are you doing about svn properties? If my
commits add any files, I then have to switch to my pure svn checkout
and set svn:eol-style and commit from svn.

-Brian

Re: Follow up questions for git-svn users

[Daniel Shahaf <d....@daniel.shahaf.name>]

Paul Davis wrote on Fri, Apr 29, 2011 at 08:56:46 -0400:
> In CouchDB we just check in our .gitignore files to SVN. Anything that

+1

> needs prop editing I do from a direct SVN check out. git-svn doesn't
> create .gitignore files from svn:ignore properties, but it seems to
> respect svn:exectuable. I've got no idea about other svn:properties,
> but my guess would be probably not if normal git doesn't have a
> corresponding feature.

Thanks for the information.

(I won't ask about properties outside of the svn:* namespace.)

Re: Follow up questions for git-svn users

[Kristian Rosenvold <kr...@gmail.com>]

fr., 29.04.2011 kl. 08.56 -0400, skrev Paul Davis:
> On Fri, Apr 29, 2011 at 6:40 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Kristian Rosenvold wrote on Fri, Apr 29, 2011 at 07:34:11 +0200:
> >> Den 29.04.2011 05:53, skrev Brian M Dube:
> >> >I think my setup is standard, from what I gleaned from the GitHub
> >> >thread (although github is not part of my workflow). My trunk branch
> >> >is remote-tracking, where I use git svn rebase and git svn dcommit.
> >> >
> >> >My first question is about keeping topic branches around and updated
> >> >for multiple uses. Perhaps this is a bad idea, but it seems like it
> >> >should work. I create my topic branch topic1 with trunk as the
> >> >starting point. I do the work, committing along the way, and merge
> >> >topic1 into trunk when I'm ready for git svn dcommit. Now I'd like to
> >> >continue working from topic1, especially if I squashed the merge to
> >> >trunk, so that I have access to the history lost by the squash. But
> >> >when I use git svn rebase to update trunk, a merge from trunk back
> >> >into topic1 makes my history look wrong in gitk.
> >> >
> >> >What I'm trying to do is get the changes that were not part of my own
> >> >commit (anything I pulled down with git svn rebase) back into my topic
> >> >branch. It seems like it should be a normal fast-forward, but it's
> >> >recursive and the history doesn't look right. I abandon the branch at
> >> >this point and start a new one for further work.
> >> >
> >> This is just the classic rebasing game as far as I can see. If you
> >> have related topic brances you just have to rebase all of them at
> >> once and keep their existing relationships. It's described under
> >> "RECOVERING FROM UPSTREAM REBASE" in man git-rebase
> >>
> >>
> >> >The second question, what are you doing about svn properties? If my
> >> >commits add any files, I then have to switch to my pure svn checkout
> >> >and set svn:eol-style and commit from svn.
> >> >
> >> git-svn uses svn through the standard svn configuration. As long as
> >> you keep the svn setup correct, git-svn will use that.
> >>
> >
> > In more concrete terms: are you saying that git-svn respects ~/.subversion/config[auto-props]?
> >
> > The man page doesn't talk either about setting properties manually or
> > about auto-props, so I'm not sure how much of that git-svn supports.
> >
> >> Kristian
> >>
> >> >-Brian
> >>
> >
> 
> In CouchDB we just check in our .gitignore files to SVN. Anything that
> needs prop editing I do from a direct SVN check out. git-svn doesn't
> create .gitignore files from svn:ignore properties, but it seems to
> respect svn:exectuable. I've got no idea about other svn:properties,
> but my guess would be probably not if normal git doesn't have a
> corresponding feature.

git-svn actually *uses* your local svn installation to commit, they did
not reimplement subversion.

I have my local svn environment set up as per asf guidelines and have
not had a single complaint about my file attributes being wrong (and I
*would* get them ;) That's all I can tell.

.gitignore is a totally different beast; most projects I work on have
manually maintained .gitignores checked into svn.


Kristian

Re: Follow up questions for git-svn users

[Paul Davis <pa...@gmail.com>]

On Fri, Apr 29, 2011 at 6:40 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Kristian Rosenvold wrote on Fri, Apr 29, 2011 at 07:34:11 +0200:
>> Den 29.04.2011 05:53, skrev Brian M Dube:
>> >I think my setup is standard, from what I gleaned from the GitHub
>> >thread (although github is not part of my workflow). My trunk branch
>> >is remote-tracking, where I use git svn rebase and git svn dcommit.
>> >
>> >My first question is about keeping topic branches around and updated
>> >for multiple uses. Perhaps this is a bad idea, but it seems like it
>> >should work. I create my topic branch topic1 with trunk as the
>> >starting point. I do the work, committing along the way, and merge
>> >topic1 into trunk when I'm ready for git svn dcommit. Now I'd like to
>> >continue working from topic1, especially if I squashed the merge to
>> >trunk, so that I have access to the history lost by the squash. But
>> >when I use git svn rebase to update trunk, a merge from trunk back
>> >into topic1 makes my history look wrong in gitk.
>> >
>> >What I'm trying to do is get the changes that were not part of my own
>> >commit (anything I pulled down with git svn rebase) back into my topic
>> >branch. It seems like it should be a normal fast-forward, but it's
>> >recursive and the history doesn't look right. I abandon the branch at
>> >this point and start a new one for further work.
>> >
>> This is just the classic rebasing game as far as I can see. If you
>> have related topic brances you just have to rebase all of them at
>> once and keep their existing relationships. It's described under
>> "RECOVERING FROM UPSTREAM REBASE" in man git-rebase
>>
>>
>> >The second question, what are you doing about svn properties? If my
>> >commits add any files, I then have to switch to my pure svn checkout
>> >and set svn:eol-style and commit from svn.
>> >
>> git-svn uses svn through the standard svn configuration. As long as
>> you keep the svn setup correct, git-svn will use that.
>>
>
> In more concrete terms: are you saying that git-svn respects ~/.subversion/config[auto-props]?
>
> The man page doesn't talk either about setting properties manually or
> about auto-props, so I'm not sure how much of that git-svn supports.
>
>> Kristian
>>
>> >-Brian
>>
>

In CouchDB we just check in our .gitignore files to SVN. Anything that
needs prop editing I do from a direct SVN check out. git-svn doesn't
create .gitignore files from svn:ignore properties, but it seems to
respect svn:exectuable. I've got no idea about other svn:properties,
but my guess would be probably not if normal git doesn't have a
corresponding feature.

Re: Follow up questions for git-svn users

[Daniel Shahaf <d....@daniel.shahaf.name>]

Kristian Rosenvold wrote on Fri, Apr 29, 2011 at 07:34:11 +0200:
> Den 29.04.2011 05:53, skrev Brian M Dube:
> >I think my setup is standard, from what I gleaned from the GitHub
> >thread (although github is not part of my workflow). My trunk branch
> >is remote-tracking, where I use git svn rebase and git svn dcommit.
> >
> >My first question is about keeping topic branches around and updated
> >for multiple uses. Perhaps this is a bad idea, but it seems like it
> >should work. I create my topic branch topic1 with trunk as the
> >starting point. I do the work, committing along the way, and merge
> >topic1 into trunk when I'm ready for git svn dcommit. Now I'd like to
> >continue working from topic1, especially if I squashed the merge to
> >trunk, so that I have access to the history lost by the squash. But
> >when I use git svn rebase to update trunk, a merge from trunk back
> >into topic1 makes my history look wrong in gitk.
> >
> >What I'm trying to do is get the changes that were not part of my own
> >commit (anything I pulled down with git svn rebase) back into my topic
> >branch. It seems like it should be a normal fast-forward, but it's
> >recursive and the history doesn't look right. I abandon the branch at
> >this point and start a new one for further work.
> >
> This is just the classic rebasing game as far as I can see. If you
> have related topic brances you just have to rebase all of them at
> once and keep their existing relationships. It's described under
> "RECOVERING FROM UPSTREAM REBASE" in man git-rebase
> 
> 
> >The second question, what are you doing about svn properties? If my
> >commits add any files, I then have to switch to my pure svn checkout
> >and set svn:eol-style and commit from svn.
> >
> git-svn uses svn through the standard svn configuration. As long as
> you keep the svn setup correct, git-svn will use that.
> 

In more concrete terms: are you saying that git-svn respects ~/.subversion/config[auto-props]?  

The man page doesn't talk either about setting properties manually or
about auto-props, so I'm not sure how much of that git-svn supports.

> Kristian
> 
> >-Brian
> 

Re: Follow up questions for git-svn users

[Brian M Dube <bd...@apache.org>]

On Fri, Apr 29, 2011 at 07:34:11AM +0200, Kristian Rosenvold wrote:
> Den 29.04.2011 05:53, skrev Brian M Dube:
> >What I'm trying to do is get the changes that were not part of my own
> >commit (anything I pulled down with git svn rebase) back into my topic
> >branch. It seems like it should be a normal fast-forward, but it's
> >recursive and the history doesn't look right. I abandon the branch at
> >this point and start a new one for further work.
> >
> This is just the classic rebasing game as far as I can see. If you
> have related topic brances you just have to rebase all of them at
> once and keep their existing relationships. It's described under
> "RECOVERING FROM UPSTREAM REBASE" in man git-rebase

That's a very helpful section of the man page, thank you. I think I
dismissed it earlier as not applicable to git-svn, but it very much is
and appears to have solved my issue.

> git-svn uses svn through the standard svn configuration. As long as
> you keep the svn setup correct, git-svn will use that.

Ah, I lost my svn configuration at some point, which included
http://www.apache.org/dev/svn-eol-style.txt. I've added that
again. Thanks.

-Brian

Re: Follow up questions for git-svn users

[Kristian Rosenvold <kr...@gmail.com>]

Den 29.04.2011 05:53, skrev Brian M Dube:
> I think my setup is standard, from what I gleaned from the GitHub
> thread (although github is not part of my workflow). My trunk branch
> is remote-tracking, where I use git svn rebase and git svn dcommit.
>
> My first question is about keeping topic branches around and updated
> for multiple uses. Perhaps this is a bad idea, but it seems like it
> should work. I create my topic branch topic1 with trunk as the
> starting point. I do the work, committing along the way, and merge
> topic1 into trunk when I'm ready for git svn dcommit. Now I'd like to
> continue working from topic1, especially if I squashed the merge to
> trunk, so that I have access to the history lost by the squash. But
> when I use git svn rebase to update trunk, a merge from trunk back
> into topic1 makes my history look wrong in gitk.
>
> What I'm trying to do is get the changes that were not part of my own
> commit (anything I pulled down with git svn rebase) back into my topic
> branch. It seems like it should be a normal fast-forward, but it's
> recursive and the history doesn't look right. I abandon the branch at
> this point and start a new one for further work.
>
This is just the classic rebasing game as far as I can see. If you have 
related topic brances you just have to rebase all of them at once and 
keep their existing relationships. It's described under "RECOVERING FROM 
UPSTREAM REBASE" in man git-rebase


> The second question, what are you doing about svn properties? If my
> commits add any files, I then have to switch to my pure svn checkout
> and set svn:eol-style and commit from svn.
>
git-svn uses svn through the standard svn configuration. As long as you 
keep the svn setup correct, git-svn will use that.

Kristian

> -Brian