git svn branch tracking + ignore paths

git svn branch tracking + ignore paths

[Lachlan Deck]

Hi there,

(Note: relative newby)

I'm wondering if it's possible to create a branch (starting as local  
but later on pushed to svn) that essentially stays in sync with the  
main branch (svn trunk) but both (a) ignores pulling in certain paths  
from trunk and (b) provides a few extra paths of its own (some of  
which overlap with those ignored from trunk) and (c) only pushes to  
trunk paths that are relevant for trunk (i.e., not specifically  
ignored)?

If someone's able to share how they'd go about setting this up that'd  
be great.

Thanks!

with regards,
--

Lachlan Deck

Re: git svn branch tracking + ignore paths

[Avery Pennarun]

On Tue, Oct 27, 2009 at 7:00 PM, Lachlan Deck <lachlan.deck@gmail.com> wrote:
> I'm wondering if it's possible to create a branch (starting as local but
> later on pushed to svn) that essentially stays in sync with the main branch
> (svn trunk) but both (a) ignores pulling in certain paths from trunk and (b)
> provides a few extra paths of its own (some of which overlap with those
> ignored from trunk) and (c) only pushes to trunk paths that are relevant for
> trunk (i.e., not specifically ignored)?
>
> If someone's able to share how they'd go about setting this up that'd be
> great.

This sounds like a generally scary idea.  Perhaps if you described
your problem at a higher level (what are you really trying to
achieve?) there would be a less scary way to do it.

That said, if you *really* need this... one option that comes to mind is:

1. extract the history from svn into git using 'git svn' as usual.

2. extract the subtree of svn that you're interested in (if you're
lucky enough that you only need one subtree) by using 'git subtree
split'.  This creates a new branch or new git repo, depending how you
do it.

3. Create a third project that will host your new work with extra
subtrees that you don't want.  Use 'git subtree add' and 'git subtree
merge' to keep this up to date with the stuff you extracted in step 2.
 (Repeat steps 1-3 as necessary to keep your project up to date with
the svn project.)

4. When you want to merge your own changes back into svn, first
extract them from your own project (step 3) using 'git subtree split'.
 Then merge those changes into the main project (step 1) using 'git
subtree merge'.  Then use git-svn to upload them to the main svn repo.

You can save yourself some steps if you import the *entire* svn
project into your own project, rather than trying to trim it on
import.  That way you only have to split when going from #3 to #1, not
in the other direction, and you don't need repository #2.

If all this sounds crazy, it probably is.  Maybe see if you can come
up with a way to avoid trying to do this altogether.

Good luck... :)

Avery

[1] http://github.com/apenwarr/git-subtree

Re: git svn branch tracking + ignore paths

[Lachlan Deck]

On 28/10/2009, at 10:16 AM, Avery Pennarun wrote:

> On Tue, Oct 27, 2009 at 7:00 PM, Lachlan Deck  
> <lachlan.deck@gmail.com> wrote:
>> I'm wondering if it's possible to create a branch (starting as  
>> local but
>> later on pushed to svn) that essentially stays in sync with the  
>> main branch
>> (svn trunk) but both (a) ignores pulling in certain paths from  
>> trunk and (b)
>> provides a few extra paths of its own (some of which overlap with  
>> those
>> ignored from trunk) and (c) only pushes to trunk paths that are  
>> relevant for
>> trunk (i.e., not specifically ignored)?
>>
>> If someone's able to share how they'd go about setting this up  
>> that'd be
>> great.
>
> This sounds like a generally scary idea.  Perhaps if you described
> your problem at a higher level (what are you really trying to
> achieve?) there would be a less scary way to do it.

:) Sure. Essentially a project that I'm contributing to has both maven  
poms and ant/lib-based configs (with the ant ones as default for  
eclipse .project etc files). I'd like to be able to import the  
projects with maven into Eclipse to work on things but without  
committing back changes to eclipse .project/.classpath/.settings/*.

So I'm hoping for a fairly transparent process.

> That said, if you *really* need this... one option that comes to  
> mind is:
>
> 1. extract the history from svn into git using 'git svn' as usual.
>
> 2. extract the subtree of svn that you're interested in (if you're
> lucky enough that you only need one subtree) by using 'git subtree
> split'.  This creates a new branch or new git repo, depending how you
> do it.
>
> 3. Create a third project that will host your new work with extra
> subtrees that you don't want.  Use 'git subtree add' and 'git subtree
> merge' to keep this up to date with the stuff you extracted in step 2.
> (Repeat steps 1-3 as necessary to keep your project up to date with
> the svn project.)
>
> 4. When you want to merge your own changes back into svn, first
> extract them from your own project (step 3) using 'git subtree split'.
> Then merge those changes into the main project (step 1) using 'git
> subtree merge'.  Then use git-svn to upload them to the main svn repo.
>
> You can save yourself some steps if you import the *entire* svn
> project into your own project, rather than trying to trim it on
> import.  That way you only have to split when going from #3 to #1, not
> in the other direction, and you don't need repository #2.
>
> If all this sounds crazy, it probably is.  Maybe see if you can come
> up with a way to avoid trying to do this altogether.
>
> Good luck... :)

Sounding scary. But if the above description of what I'm trying to  
achieve helps in finding a simple way to work I'm all ears :)

Thanks.

> Avery
>
> [1] http://github.com/apenwarr/git-subtree

I'll check this out anyway. Thanks.

with regards,
--

Lachlan Deck

Re: git svn branch tracking + ignore paths

[Avery Pennarun]

On Tue, Oct 27, 2009 at 11:00 PM, Lachlan Deck <lachlan.deck@gmail.com> wrote:
> :) Sure. Essentially a project that I'm contributing to has both maven poms
> and ant/lib-based configs (with the ant ones as default for eclipse .project
> etc files). I'd like to be able to import the projects with maven into
> Eclipse to work on things but without committing back changes to eclipse
> .project/.classpath/.settings/*.
>
> So I'm hoping for a fairly transparent process.

So which are the files you don't want to import from trunk?  It
doesn't sound like there are any... so it's getting simpler already.

Also, can you just simply not commit any changes to the other files?
That would be the easiest way to deal with committing back.  The other
option (slightly messier) is to change them in a single commit, and
use git rebase to move that commit out of the way when you're about to
push your changes back into svn.

Have fun,

Avery

Re: git svn branch tracking + ignore paths

[Lachlan Deck]

On 28/10/2009, at 4:20 PM, Avery Pennarun wrote:

> On Tue, Oct 27, 2009 at 11:00 PM, Lachlan Deck  
> <lachlan.deck@gmail.com> wrote:
>> :) Sure. Essentially a project that I'm contributing to has both  
>> maven poms
>> and ant/lib-based configs (with the ant ones as default for  
>> eclipse .project
>> etc files). I'd like to be able to import the projects with maven  
>> into
>> Eclipse to work on things but without committing back changes to  
>> eclipse
>> .project/.classpath/.settings/*.
>>
>> So I'm hoping for a fairly transparent process.
>
> So which are the files you don't want to import from trunk?  It
> doesn't sound like there are any... so it's getting simpler already.

There are. I've currently (as a workaround) done the following within  
the main branch:
add the following to .git/info/exclude
.settings
target
.classpath
.project

The last two of these has no effect of course because .project  
and .classpath files already exist -- and thus are marked as modified.  
So I'm currently doing a git stash && git svn rebase && git svn  
dcommit && git stash pop


I'm also wanting to exclude 'lib' folders from trunk (as these are not  
needed).

> Also, can you just simply not commit any changes to the other files?
> That would be the easiest way to deal with committing back.

That's what I'm doing now I guess - but it means I can't share the  
project setups (specific for maven, for example) with anyone.

> The other
> option (slightly messier) is to change them in a single commit, and
> use git rebase to move that commit out of the way when you're about to
> push your changes back into svn.

Yeah that'd be a bit of a slippery slope.

with regards,
--

Lachlan Deck

Re: git svn branch tracking + ignore paths

[Avery Pennarun]

On Wed, Oct 28, 2009 at 1:59 AM, Lachlan Deck <lachlan.deck@gmail.com> wrote:
> On 28/10/2009, at 4:20 PM, Avery Pennarun wrote:
>> So which are the files you don't want to import from trunk?  It
>> doesn't sound like there are any... so it's getting simpler already.
>
> There are. I've currently (as a workaround) done the following within the
> main branch:
> add the following to .git/info/exclude
> .settings
> target
> .classpath
> .project
>
> The last two of these has no effect of course because .project and
> .classpath files already exist -- and thus are marked as modified. So I'm
> currently doing a git stash && git svn rebase && git svn dcommit && git
> stash pop
>
> I'm also wanting to exclude 'lib' folders from trunk (as these are not
> needed).

The problem is that as your branch diverges from what you *actually*
want to commit, it becomes exponentially more complicated to figure
out what you *do* want to commit.

Note that if you're planning to share your git project with other
people anyway, then you have an additional problem: you're using git
svn rebase, which is almost useless for sharing with other people
(other than through svn, of course), for the same reason any git
rebase is.

One option you have is to maintain two branches:

1. (git-svn) The git-svn trunk, which contains only stuff you want upstream

2. (master) Your live branch, which contains everything from (1) plus
your local customizations.

When you want to fetch from svn, you do this:

  git checkout master
  git svn fetch git-svn
  git merge git-svn

When you want to push to svn, you do this:

  git checkout git-svn
  git merge --squash --no-commit master
    (now undo your local customizations)
  git commit
  git svn dcommit
  git checkout master
  git merge git-svn

Note that master never gets rebased, only merged.  If you can write a
simple script for "undo your local customizations" - such as reverting
a particular commit, for example - then you can put the above in a
shell script and it should work fine most of the time.

Good luck.

Avery

Re: git svn branch tracking + ignore paths

[Lachlan Deck]

On 29/10/2009, at 3:00 AM, Avery Pennarun wrote:

> On Wed, Oct 28, 2009 at 1:59 AM, Lachlan Deck  
> <lachlan.deck@gmail.com> wrote:
>> On 28/10/2009, at 4:20 PM, Avery Pennarun wrote:
>>> So which are the files you don't want to import from trunk?  It
>>> doesn't sound like there are any... so it's getting simpler already.
>>
>> There are. I've currently (as a workaround) done the following  
>> within the
>> main branch:
>> add the following to .git/info/exclude
>> .settings
>> target
>> .classpath
>> .project
>>
>> The last two of these has no effect of course because .project and
>> .classpath files already exist -- and thus are marked as modified.  
>> So I'm
>> currently doing a git stash && git svn rebase && git svn dcommit &&  
>> git
>> stash pop
>>
>> I'm also wanting to exclude 'lib' folders from trunk (as these are  
>> not
>> needed).
>
> The problem is that as your branch diverges from what you *actually*
> want to commit, it becomes exponentially more complicated to figure
> out what you *do* want to commit.

Sure.

> Note that if you're planning to share your git project with other
> people anyway, then you have an additional problem: you're using git
> svn rebase, which is almost useless for sharing with other people
> (other than through svn, of course), for the same reason any git
> rebase is.
>
> One option you have is to maintain two branches:
>
> 1. (git-svn) The git-svn trunk, which contains only stuff you want  
> upstream
>
> 2. (master) Your live branch, which contains everything from (1) plus
> your local customizations.
>
> When you want to fetch from svn, you do this:
>
>  git checkout master
>  git svn fetch git-svn
>  git merge git-svn
>
> When you want to push to svn, you do this:
>
>  git checkout git-svn
>  git merge --squash --no-commit master
>    (now undo your local customizations)
>  git commit
>  git svn dcommit
>  git checkout master
>  git merge git-svn
>
> Note that master never gets rebased, only merged.  If you can write a
> simple script for "undo your local customizations" - such as reverting
> a particular commit, for example - then you can put the above in a
> shell script and it should work fine most of the time.

Thanks Avery!
  - that gives me something to think about.

with regards,
--

Lachlan Deck