www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Follow up questions for git-svn users
Date Fri, 29 Apr 2011 12:56:46 GMT
On Fri, Apr 29, 2011 at 6:40 AM, Daniel Shahaf <d.s@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.

Mime
View raw message