www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Rosenvold <kristian.rosenv...@gmail.com>
Subject Re: Follow up questions for git-svn users
Date Fri, 29 Apr 2011 13:07:29 GMT
fr., 29.04.2011 kl. 08.56 -0400, skrev Paul Davis:
> 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.

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.


View raw message