Hi,
Is it currently possible to specify which branch to check out with GetComponents? For the release, we are planning on making a new branch in each repository which will be the "release branch", called ET_2010_06. For each type of repository (SVN, CVS, git) the einsteintoolkit.th thorn list will be updated to check out this branch. Is this possible?
It seems that git clone has a "-b" option to specify which branch to check out after the repository is cloned, but this doesn't seem to exist in anything but the latest versions of git (for example, it exists in 1.7.1 but not in 1.6.1). So a separate "git checkout" command will have to be run by GetComponents.
On Jun 15, 2010, at 4:54 , Ian Hinder wrote:
Hi,
Is it currently possible to specify which branch to check out with GetComponents? For the release, we are planning on making a new branch in each repository which will be the "release branch", called ET_2010_06. For each type of repository (SVN, CVS, git) the einsteintoolkit.th thorn list will be updated to check out this branch. Is this possible?
Darcs does not support branches. Mercurial does, but they are a somewhat unusual feature; instead, people use a different repository (as far as I can tell).
It seems that git clone has a "-b" option to specify which branch to check out after the repository is cloned, but this doesn't seem to exist in anything but the latest versions of git (for example, it exists in 1.7.1 but not in 1.6.1). So a separate "git checkout" command will have to be run by GetComponents.
We also need to collect on the wiki the commands that we need to execute to create these branches in the first place. It's not trivial for git.
Do you have experience with branches in git? Is it easier to use branches, or to have separate repositories and push/pull changes in between?
-erik
Do you have experience with branches in git? Is it easier to use branches, or to have separate repositories and push/pull changes in between?
I thought that the ease of branching/merging was one of the major selling points of git, but idk if branches would be the preferable method for indicating a stable release (I don't see why not). My question is can you specify a specific branch in the URL as you can in cvs/svn. I think it would be best if we had 2 thornlists, one for the stable release, and one for development. To me this approach makes more sense because in general we can't guarantee that all stable branches will have the same tag, so doing some clever tricks within GetComponents wouldn't work as well.
As far as branching with GetComponents goes, it doesn't do anything beyond checking out from a URL. So branching would work for cvs/svn, but possibly not for git (I'll have to look into that a bit)
On another note, there is a bug in GetComponents that I'm planning to address a bit later today. We're trying to merge all the git-repos/hg-repos etc into one repos folder, but it causes an error if you try to update ET with the newest version of GetComponents from last night. So I would recommend either doing a clean checkout of ET, or wait until a bit later today and I'll try to have GetComponents make the change a bit more elegantly.
Eric
On 15 Jun 2010, at 16:24, Eric Seidel wrote:
Do you have experience with branches in git? Is it easier to use branches, or to have separate repositories and push/pull changes in between?
I thought that the ease of branching/merging was one of the major selling points of git, but idk if branches would be the preferable method for indicating a stable release (I don't see why not). My question is can you specify a specific branch in the URL as you can in cvs/svn.
I don't think you can specify the branch in the URL. After it is cloned, you need to do "git checkout <branchname>" in the repo directory.
I think it would be best if we had 2 thornlists, one for the stable release, and one for development. To me this approach makes more sense because in general we can't guarantee that all stable branches will have the same tag, so doing some clever tricks within GetComponents wouldn't work as well.
Yes, I agree.
As far as branching with GetComponents goes, it doesn't do anything beyond checking out from a URL. So branching would work for cvs/svn, but possibly not for git (I'll have to look into that a bit)
On another note, there is a bug in GetComponents that I'm planning to address a bit later today. We're trying to merge all the git- repos/hg-repos etc into one repos folder, but it causes an error if you try to update ET with the newest version of GetComponents from last night. So I would recommend either doing a clean checkout of ET, or wait until a bit later today and I'll try to have GetComponents make the change a bit more elegantly.
Eric
I don't think you can specify the branch in the URL. After it is cloned, you need to do "git checkout <branchname>" in the repo directory.
Ok, then I would suggest adding an optional !BRANCH directive to be used with git and mercurial. That would be easy to understand and implement.
Eric
Hi,
On 15/06/2010 16:09, Erik Schnetter wrote:
It seems that git clone has a "-b" option to specify which branch to check out after the repository is cloned, but this doesn't seem to exist in anything but the latest versions of git (for example, it exists in 1.7.1 but not in 1.6.1). So a separate "git checkout" command will have to be run by GetComponents.
We also need to collect on the wiki the commands that we need to execute to create these branches in the first place. It's not trivial for git.
Do you have experience with branches in git? Is it easier to use branches, or to have separate repositories and push/pull changes in between?
I think the best thing is to just have a single repository with a tag and branch for each release. This is quite straightforward to do:
1. Tag the current revision (if you want the revision signed, use something other than -a):
git tag -a ET_2010_06 git push --tags
2. Create a branch for the revision:
git branch ET_2010_06 git push origin refs/heads/ET_2010_06
If you then want to checkout the new branch, you use:
git checkout -b ET_2010_06 origin/ET_2010_06
If you make a mistake and want to remove the remote branch, then you can do so with:
git push origin :refs/heads/ET_2010_06
A good model for a large project working with git is the VLC project. They create a tag and branch for each release. In their case, they have the branches in separate repository, but only because there are so many extensive changes between versions and the single repository was getting quite large. I don't think in this case it is so important, but it can always be done at a later stage anyway. They also have a useful page listing all the useful commands they use for working with their repositories: http://wiki.videolan.org/Git
Regards, Barry
On Jun 15, 2010, at 9:51 , Barry Wardell wrote:
Hi,
On 15/06/2010 16:09, Erik Schnetter wrote:
It seems that git clone has a "-b" option to specify which branch to check out after the repository is cloned, but this doesn't seem to exist in anything but the latest versions of git (for example, it exists in 1.7.1 but not in 1.6.1). So a separate "git checkout" command will have to be run by GetComponents.
We also need to collect on the wiki the commands that we need to execute to create these branches in the first place. It's not trivial for git.
Do you have experience with branches in git? Is it easier to use branches, or to have separate repositories and push/pull changes in between?
I think the best thing is to just have a single repository with a tag and branch for each release. This is quite straightforward to do:
- Tag the current revision (if you want the revision signed, use
something other than -a): git tag -a ET_2010_06 git push --tags 2. Create a branch for the revision: git branch ET_2010_06 git push origin refs/heads/ET_2010_06 If you then want to checkout the new branch, you use: git checkout -b ET_2010_06 origin/ET_2010_06 If you make a mistake and want to remove the remote branch, then you can do so with: git push origin :refs/heads/ET_2010_06
Are you sure that these commands work? I looked at <http://www.zorched.net/2008/04/14/start-a-new-branch-on-your-remote-git-repo...
, and it seemed more complex. In particular, it seems necessary to
create the remote branch before the local branch, because one cannot push local branches to a remote repository.
Can you try this with a git repository of your own, and then update the ET wiki pages accordingly? We should have the exact sequence of commands there (as you are listing them here).
-erik
Barry Wardell wrote:
Hi,
On 15/06/2010 16:09, Erik Schnetter wrote:
It seems that git clone has a "-b" option to specify which branch to check out after the repository is cloned, but this doesn't seem to exist in anything but the latest versions of git (for example, it exists in 1.7.1 but not in 1.6.1). So a separate "git checkout" command will have to be run by GetComponents.
We also need to collect on the wiki the commands that we need to execute to create these branches in the first place. It's not trivial for git.
Do you have experience with branches in git? Is it easier to use branches, or to have separate repositories and push/pull changes in between?
I think the best thing is to just have a single repository with a tag and branch for each release. This is quite straightforward to do:
- Tag the current revision (if you want the revision signed, use
something other than -a):
git tag -a ET_2010_06 git push --tags
Create a branch for the revision:
git branch ET_2010_06 git push origin refs/heads/ET_2010_06
If you then want to checkout the new branch, you use:
git checkout -b ET_2010_06 origin/ET_2010_06
You probably want to checkout with --track so you can follow any possible changes in that branch:
git checkout --track -b ET_2010_06 origin/ET_2010_06
If you make a mistake and want to remove the remote branch, then you can do so with:
git push origin :refs/heads/ET_2010_06A good model for a large project working with git is the VLC project. They create a tag and branch for each release. In their case, they have the branches in separate repository, but only because there are so many extensive changes between versions and the single repository was getting quite large. I don't think in this case it is so important, but it can always be done at a later stage anyway. They also have a useful page listing all the useful commands they use for working with their repositories: http://wiki.videolan.org/Git
Regards, Barry
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 15/06/2010 17:20, Bruno C. Mundim wrote:
You probably want to checkout with --track so you can follow any possible changes in that branch:
git checkout --track -b ET_2010_06 origin/ET_2010_06
In general, yes. Although when you give git checkout a remote branch (origin/ET_2010_06) as a starting point, then it automatically sets up the remote tracking appropriately and so I think --track is not needed in this case.
On Tue, Jun 15, 2010 at 09:09:24AM -0500, Erik Schnetter wrote:
Do you have experience with branches in git? Is it easier to use branches, or to have separate repositories and push/pull changes in between?
If branches in git are such a headache with extra command line arguments and whatnot - what speaks against using two separate repositories? Exchanging patches between repositories is always sold as one of the strong points of a system like git.
Frank
On 15 Jun 2010, at 17:53, Frank Loeffler wrote:
On Tue, Jun 15, 2010 at 09:09:24AM -0500, Erik Schnetter wrote:
Do you have experience with branches in git? Is it easier to use branches, or to have separate repositories and push/pull changes in between?
If branches in git are such a headache with extra command line arguments and whatnot - what speaks against using two separate repositories? Exchanging patches between repositories is always sold as one of the strong points of a system like git.
To summarise (I just talked with Barry about this):
git push origin origin:refs/heads/ET_2010_06
This creates the branch in the remote repository.
Any user can then do
git clone <path to repo> git checkout -b ET_2010_06 origin/ET_2010_06
I agree that this is a little bit more typing than if you could do git clone <path to repo>/branchname, but I think it makes more logical sense to have everything in the same repository. After all, most of the content is shared between the branches.
On 15/06/2010 19:09, Frank Loeffler wrote:
On Tue, Jun 15, 2010 at 06:28:41PM +0200, Ian Hinder wrote:
git clone<path to repo> git checkout -b ET_2010_06 origin/ET_2010_06
And we can still push to those branches then, in the usual way?
Yes, 'git push' will by default push all branches (except local branches which were never pushed to the server).
users@lists.einsteintoolkit.org
-
Barry Wardell -
Bruno C. Mundim -
Eric Seidel -
Erik Schnetter -
Frank Loeffler -
Ian Hinder