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

Einstein Toolkit trac-noreply at einsteintoolkit.org
Sun Jan 30 11:45:18 CST 2011


#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 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]]
 > 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?

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


More information about the Trac mailing list