repo start not working as expected

[Mark Hamilton]

Hi,

We seem to have a fundamental misunderstanding of what 'repo start' does. I'm hoping someone can correct us.

Recently we split our single repository into multiple repositories for better access control, and adopted repo as the tool to pull them back together again. Things have been working well, until yesterday when we created a release branch. We expected that 'repo start X.Y --all' would create a local X.Y branch to track the remote origin/X.Y. That does not seem to be the case.  It's clearly creating a new, local X.Y branch starting wherever the projects are currently checked out from. Where does it put those commits when the users push them back to the central repository?

Is there a different repo command that does the equivalent of a 'git checkout  X.Y' in the sub-projects?

[Mark Hamilton]

So I tried this to get the repositories on the branch I wanted

$ repo forall -c 'git checkout master ; git branch -D 4.40 ; git checkout 4.40'

This did what I expected in that it checked out the right branch

$ git branch
* 4.40
  master

but repo info still shows 'master' for the current revision, which is not what I expected.

$ repo info              
Manifest branch: master                                        
Manifest merge branch: refs/heads/master                        
Manifest groups: all,-notdefault                                
----------------------------
Project: sierra.base.git
Mount path: /projects/sierra/darwin_13/nightly/Sierra.code.4.40/.
Current revision: master
Local Branches: 2 [4.40, master]

[Dan Willemsen]

The intended mechanism is to create a new branch X.Y in the manifest branch, that has any of the revisions changed, then you can switch branches using:

  repo init -b X.Y && repo sync

  repo init -b master && repo sync

"repo start" creates local development branches against the revisions that the manifest is tracking.

- Dan

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Hamilton]

Dan,

Thanks for the quick reply.

On Thursday, April 7, 2016 at 2:27:54 PM UTC-6, Dan Willemsen wrote:

The intended mechanism is to create a new branch X.Y in the manifest branch, that has any of the revisions changed, then you can switch branches using:

  repo init -b X.Y && repo sync

  repo init -b master && repo sync

"repo start" creates local development branches against the revisions that the manifest is tracking.

If I understand what you said I need to create  a X.Y branch in my manifests repository, modify the manifests in that branch to refer to X.Y rather than master, and then use init/sync. Is that correct?

IAE, I did that, but I'm still getting unexpected results. Starting from scratch I tried initing with master first, but all sub-projects still show as '(no branch)'

% repo init -b master && repo sync    
...                                                                                    
% repo forall -c git branch
* (no branch)
* (no branch)
* (no branch)
* (no branch)
* (no branch)
* (no branch)

So I tried switching to our 4.40 branch (after creating a manifest branch for it) and got this

% repo init -b 4.40 && repo sync

% repo forall -c git branch
* (HEAD detached at db57bfa)
* (no branch)
* (no branch)
* (no branch)
* (HEAD detached at 264179a)
* (no branch)

I don't understand why some are detached, some are no branch, but none are 4.40. If it helps my manifest looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<!-- This is the google repo manifest file for a Sierra default (ie, developer)
     project. From the command line enter this command to get information on
     what fields can be set in this file.

     repo help manifest
-->
  <default remote="origin"
           sync-j="4"
           sync-s="true"
           dest-branch="4.40"
           revision="4.40" />

  <remote name="origin"
          fetch="sierra-git:/git/" />

<!-- Projects are cloned as if they were this:

git clone ${remote.fetch}/${project.name} ${project.path}

Projects without a remote use the default remote's fetch attribute;
projects with a remote use that remote's fetch attribute.
-->

  <project name="sierra.base.git" path="." />
  <project name="sierra.navy.git" path="navy" />
  <project name="sierra.awe.git" path="awe" />
  <project name="sierra.goodyear.git" path="goodyear" />
  <project name="sierra.itar.git" path="itar" />
  <project name="sierra.cth.git" path="itar/TPLs_src/cth" />
</manifest>

[Dan Willemsen]

On Thu, Apr 7, 2016 at 2:21 PM Mark Hamilton <mha...@sandia.gov> wrote:

On Thursday, April 7, 2016 at 2:27:54 PM UTC-6, Dan Willemsen wrote:

The intended mechanism is to create a new branch X.Y in the manifest branch, that has any of the revisions changed, then you can switch branches using:

  repo init -b X.Y && repo sync

  repo init -b master && repo sync

"repo start" creates local development branches against the revisions that the manifest is tracking.

If I understand what you said I need to create  a X.Y branch in my manifests repository, modify the manifests in that branch to refer to X.Y rather than master, and then use init/sync. Is that correct?

 

Yes, that's correct.

IAE, I did that, but I'm still getting unexpected results. Starting from scratch I tried initing with master first, but all sub-projects still show as '(no branch)'

Yes, unless you've started a local development branch with 'repo start' (or other git commands), repo keeps each repository checked out in a "detached head" state (with the same sha1 as the remote branch at the time of the last sync).

When you create a local development branch with "repo start", you'll see that the upstream for that branch is set the the remote branch.

 

I don't understand why some are detached, some are no branch, but none are 4.40.

It looks like "(no branch)" vs detached are effectively the same, just a difference with how repo checked things out, and what got inserted into the reflog.

As mentioned above, we don't create local branches unless created with "repo start". If you use `git branch -r --points-at HEAD`, you'll see all the branches that share that same sha1. You can use `repo info` to get user-readable information about which branch repo is tracking for a particular project. If you want to script around it, repo forall exports a number of environment variables that may be useful.

- Dan

[Mark E. Hamilton]

Thanks, Dan,

As you suggested the following does what we expect

repo init -b <branch> && repo sync

followed by one of these, depending on whether the branch exists or not:

repo start --all <branch>
repo checkout <branch>

I did notice that repo checkout will switch back and forth between two
branches (X.Y or master, for instance,) but repo info continues to
report whatever was passed to the init. Is this likely to be problematic?

Also, our version of git (2.6.1) doesn't have the --points-at option for
branch. Is that relatively new?

--
----------------
Mark E. Hamilton
Engineering Sciences Center
Senior Member of Technical Staff
Sandia National Laboratories
505-844-7666

[Mark E. Hamilton]

Okay, I hate to keep cropping up like a bad penny, but I've encountered
another issue related to this.

As you had suggested previously, I did the following in a new directory:

% repo init -b 4.40 && repo sync

% repo start --all 4.40

% git log --oneline -n2 origin/4.40
cf986a5 Adding meaningful tolerance to unit test.
1f78fea Bug fix
% git log --oneline -n2 4.40
cf986a5 Adding meaningful tolerance to unit test.
1f78fea Bug fix
% git status
On branch 4.40
Your branch is up-to-date with 'origin/4.40'.
nothing to commit, working directory clean

So far, so good. I've got the SHA1s I expect and nothing is weird. Now I
want to switch to the master branch (for which I have not yet created a
local tracking branch.)

% repo init -b master && repo sync
% repo start --all master

% git log --oneline -n2 origin/master
b7df477 IOSS: Support for parallel cgns
2e2bce8 EXODUS: Cleanup for removing cbind and forbind level
% git log --oneline -n2 master
b7df477 IOSS: Support for parallel cgns
2e2bce8 EXODUS: Cleanup for removing cbind and forbind level
% git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Again, so far/so good. However, if I check my local 4.40 branch is is
now NOT pointing to origin/4.40 as it should.

% git log --oneline -n2 4.40
b7df477 IOSS: Support for parallel cgns
2e2bce8 EXODUS: Cleanup for removing cbind and forbind level
% git log --oneline -n2 origin/4.40
cf986a5 Adding meaningful tolerance to unit test.
1f78fea Bug fix

What am I not understanding here?

On 04/07/16 16:55, Dan Willemsen wrote:
> On Thu, Apr 7, 2016 at 2:21 PM Mark Hamilton <mha...@sandia.gov
> <mailto:mha...@sandia.gov>> wrote:
e don't create local branches unless created with
> "repo start". If you use `git branch -r --points-at HEAD`, you'll see

FWIW, --points-at doesn't seem to be a valid option to git in our
version (2.6.1). I'll have to see if we can update.