[ET Trac] [Einstein Toolkit] #248: Enhance GetComponents functionality when dealing with git branches

[Einstein Toolkit]

#248: Enhance GetComponents functionality when dealing with git branches
----------------------------+-----------------------------------------------
  Reporter:  bmundim        |       Owner:  eric9       
      Type:  enhancement    |      Status:  accepted    
  Priority:  minor          |   Milestone:              
 Component:  GetComponents  |     Version:              
Resolution:                 |    Keywords:  git branches
----------------------------+-----------------------------------------------

Comment (by bmundim):

 Replying to [comment:9 eric9]:
 > Replying to [comment:8 hinder]:
 > > Do you mean that local branches should be created for all remote
 branches?  There is a --mirror option to git clone which does this, but it
 only works for bare repositories.  I seem to remember some advice which
 said that cloning all remote branches by default, while it sounds like a
 good idea, is in practice more trouble than it is worth, because you have
 to keep them all up-to-date.  I'm not sure of the details, but maybe
 google a bit to read up on it.
 > [[BR]]
 > I see. I guess part of the reasoning is that git is designed for easy
 branching, so it's quite possible that a repository could have a very
 large number of branches. That could become a bit unwieldy I suppose.
 > [[BR]]
 > > I think users of GetComponents would expect git repositories to behave
 as "standardly" as possible, so it might not be a good idea to do too much
 "extra" work.  Cloning the repository pulls in all data, and we can select
 the default branch to check out in the CRL file.  If a user wants to check
 out another branch, they can use the appropriate git command to do that.
 > [[BR]]
 > Right, so I'll maintain the current behavior of doing a regular clone
 with the master branch, and then allow users to specify additional
 branches to track. This will sidestep the issue I mentioned in my last
 post. !REPO_BRANCH is serving as a branch and tag indicator for git since
 I didn't want to add yet another directive, but I can't determine if I'm
 dealing with a branch or a tag until the repository has been cloned.
 > [[BR]]
 That sounds good to me!

 > > The way that I usually work with multiple branches is to have a
 different arrangement for each branch.  I would have two separate
 repositories, each with one of the branches checked out, and the symbolic
 links in the arrangements directory would point to the appropriate thorns.
 So for example, for the Kranc Examples arrangement, I have
 > >
 > >   KrancExamples -> ../repos/Kranc/Examples
 > >   KrancExamplesVector -> ../repos/KrancVector/Examples
 > >
 > > I don't have this configured in my thornlist, I do it by hand.  But I
 think it would be possible to have this work in a thornlist if you could
 specify the arrangement name and the branch to check out, and just have
 two entries for the arrangement.
 > [[BR]]
 > Currently, this is not possible because GetComponents will automatically
 clone the repository using the same name; however, we could use the !NAME
 directive to specify an alternative name for the clone. This would leave
 us with the following syntax
 > [[BR]]
 >
 > {{{
 > # this will setup stable and experimental as remote-tracking branches,
 > # and then checkout the ET_2010_11 tagged commit
 > !TARGET = $ROOT/bin
 > !TYPE = git
 > !URL =  git://github.com/gridaphobe/CRL.git
 > !REPO_BRANCH = stable, experimental, ET_2010_11
 > !CHECKOUT = GetComponents
 >
 > # this will clone into CRL-experimental, and checkout the experimental
 branch
 > !TARGET = $ROOT/bin
 > !TYPE = git
 > !URL =  git://github.com/gridaphobe/CRL.git
 > !REPO_BRANCH = experimental
 > !CHECKOUT = GetComponents
 > !NAME = CRL-experimental
 > }}}
 > [[BR]]
 > How does that sound?

 The first set of directives is fine for me.

 Unless Ian has a strong opinion about it, I would suggest not to implement
 this last set of directives. I don't think it is a good idea to have
 multiple copies of git repos, each one corresponding to different
 branches. I would stick with the standard way of using git: one repo with
 several different branches pulled from the remote repo.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/248#comment:12>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit