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