[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: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.
 >
 All remote branches as specified in the CRL file in the !REPO_BRANCH
 directive. I already do that with a set of shell scripts for each of the
 private git repositories I work with. It is simply a loop over the list of
 branch names on the following command:

 git checkout --track -b $branchname origin/$branchname

 I thought this information could be stored in the CRL file and
 GetComponent could handle the checkout of these different branches. The
 order or which branch should be the default really doesn't matter that
 much to me. I would checkout then the branch I want to use for building my
 new configuration, for example. Regarding the --mirror option, I know
 nothing about it. Unless someone really understands it,
 I would stick with the command I suggested above.

 Why do you think it is trouble to update them all? The list is already in
 the CRL file, all GetComponents has to do is to loop over it with git pull
 --rebase or a similar command.

 > 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.
 >
 Git has powerful tools that allow easy creation, merger or switching of
 branches. Indeed it is good practice and even encouraged that code
 developments happen in different branches. So working with branches is the
 standard practice when using git as a revision control tool. From the
 point of view of the novice, my suggestion to enhance GetComponents would
 not change anything. This user certainly would start using the ET thorn
 lists, either the development or the release branch. The development
 defaults to master branch and it is not even necessary to have it listed
 in the CRL file (as it is already the case). The release branch would be
 referred exactly as it is today: !REPO_BRANCH = ET_20XX_XX. So no
 confusion is added to what is already established. On the other hand, my
 suggestion helps users that end up working with several different git
 repositories, each with different branch names. Sure, this case is not
 part of ET, but it is a situation that users like me already face and has
 a very simple solution.


 > 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.

 Now add 5 different git repos with 5 different branches each one and your
 way to deal with branches just becomes impractical. Besides you have
 unnecessary duplication of git repositories! If you are using svn, then
 yes you have no choice but doing something as you suggested, but git
 provides you with tools to make your life easier when dealing with
 branches. You don't need to make multiple repo copies, you don't need to
 change directories to inspect another branch and in fact you don't need to
 type the different branch paths when diff'ing them. A simple git checkout
 branchname and that's it. So I would not recommend to deal with git
 branches as you suggested. It would subvert git philosophy and best
 practices :)

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