#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 :)