Strange message "already on master"

Create issue
Issue #392 closed
Erik Schnetter created an issue

GetComponents outputs "already on master" for every git repository. This message should not appear.


Comments (13)

  1. Frank Löffler
    • 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.

  2. Roland Haas
    • 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)

  3. Frank Löffler
    • 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.

  4. Roland Haas
    • removed comment

    I think requiring /dev/null is probably fine, our build system also uses /dev/null it seems, eg in lib/make/configure.

  5. Frank Löffler
    • 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.

  6. Barry Wardell
    • 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.

  7. Roland Haas
    • 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.

  8. Barry Wardell
    • 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.

  9. Roland Haas
    • 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.

  10. Log in to comment