- changed status to open
- removed comment
Strange message "already on master"
GetComponents outputs "already on master" for every git repository. This message should not appear.
Keyword:
Comments (12)
-
-
- removed comment
Can somebody with more git experience please look into this? With more git repositories in the future we must not get these warnings.
-
repo owner - changed milestone to ET_2013_11
- removed comment
-
repo owner - changed status to open
- removed comment
The attached two patches should take of this. Changes are:
- only call checkout if we are not already on the desired branch (HEAD!=branch)
-
when going back to the current branch, do not try to create it (it already exists since we were on it) and do not reset the local branch to the remote one since this wipes local commits that have not been pushed. If we are not on "branch" the the user did a git checkout manually to switch branches and is likely able to do so again (or rebase) if she wants to do so.
-
work around very old git version on queenbee
the attached patches avoid the warning (and do a proper update) on both my workstation (new git) and on queenbee (ancient)
-
- removed comment
0002-work-around-old-svn-version-on-queenbee.patch looks good, please apply. I also opened a ticket with the qb admins to update the client. The patch has the "problem" that it will fail if /dev/null does not exist though, which might be the case in chroots for instance if /dev isn't loop-mounted there.
-
repo owner - removed comment
I think requiring /dev/null is probably fine, our build system also uses /dev/null it seems, eg in lib/make/configure.
-
- removed comment
0002 isn't necessary anymore. A new version of svn has been installed on queenbee. Use
soft add +subversion-1.8.3-gcc-4.3.2
to get it. This has been added to the new users tutorial as well.
-
repo owner - removed comment
Anyone to review patch 0001? Someone who knows git?
-
- removed comment
0001 doesn't look like it does quite the right thing. It checks that the two hashes (current and branch) are the same and doesn't do the checkout if they are. This could be wrong in a couple of cases: if two branches point to the same commit, or if the repository is on a detached head which also happens to be pointed to by a branch.
I think the following (untested) patch might be a better approach.
-
repo owner - removed comment
I agree. The original solution would have failed in the situations that Barry outlined. git symbolic-ref seems to do the trick, with the exception that it prepends "refs/heads/" to the branch name. The attached patch adjusts the regex patterns for this.
Please note that none of our regex patterns are anchored (to the beginning or end) so that "master" and "master-untested" will both match. This is a bug.
-
- removed comment
The new patch looks good to me. I don't think there would be any bug in this version since string equality is used in place of a regex.
-
repo owner - changed status to resolved
- removed comment
There is indeed no issue with regex in this patch. There are other places in GetComponents (eg line 1711:
# three possibilities: # 1. branch exists locally, needs update # 2. branch exists remotely, needs local tracking branch # 3. branch is actually tag, do nothing if ( `cd $repo_loc && $git branch` =~ /$branch/m ) {
Applied as git hash de0b1dd9feb097591130c33bf7a61862cacf4ff0 of CRL.
- Log in to comment
Noted. It must be trying to change branches one too many times.