Issue 2311 - Track remote Git branches when required

ensure_dependencies.py

Index: ensure_dependencies.py
diff --git a/ensure_dependencies.py b/ensure_dependencies.py
index b6557d051f6661645dea95edfde280ea288f7533..6bf7627872759385d4d636b167b9ed5edc16457b 100755
--- a/ensure_dependencies.py
+++ b/ensure_dependencies.py
@@ -53,7 +53,7 @@ class Mercurial():
     result = subprocess.Popen(command, stdout=subprocess.PIPE, stderr=subprocess.PIPE).communicate()[0]
     return result.strip()
 
-  def pull(self, repo):
+  def pull(self, repo, rev):
     subprocess.check_call(["hg", "pull", "--repository", repo, "--quiet"])
 
   def update(self, repo, rev):
@@ -96,8 +96,9 @@ class Git():
     command = ["git", "rev-parse", "--revs-only", rev + '^{commit}']
     return subprocess.check_output(command, cwd=repo).strip()
 
-  def pull(self, repo):
+  def pull(self, repo, rev):
     subprocess.check_call(["git", "fetch", "--quiet", "--all", "--tags"], cwd=repo)
+    subprocess.check_call(["git", "checkout", rev], cwd=repo)

[Sebastian Noack, 2015/04/30 17:54:34]

Wasn't the problem you try to address here, that branches other than master that
haven't been manually marked as tracking, aren't even fetched?

[kzar, 2015/04/30 19:31:46]

So it turns out the remote branches are fetched, the problem is that local
tracking branches aren't created for them. Checking out the revision here causes
a tracking branch of the same name to be created where relevant.

It seems to work pretty well, only the required remote branch is tracked and it
is only done when required (when the revision isn't resolved already).

[Sebastian Noack, 2015/04/30 20:53:57]

Isn't this call redundant with the one in Git.update()? I don't get how this
should change anything. Are you sure that this is the right thing to do here?

[kzar, 2015/05/01 09:43:55]

As of Git 1.6.6 [1] checking out a local branch when there is no local branch by
that name but there is a remote branch of that name creates a local tracking
branch before checking it out. We need to make sure the tracking branch is
created here, before the later checkout, because without it the revision_id
can't be resolved.

This approach seems to work fine, only difference really is that should the
revision not be found by this checkout a `subprocess.CalledProcessError`
exception will be thrown instead of the later "Failed to resolve revision"
exception. (If that's an issue I can catch the `subprocess.CalledProcessError`
here.)

The other difference is that the branch is checked out now, but that doesn't
really matter IMHO. If it works here the later one would have worked too.
(Actually the later check out uses the resolved revision ID instead of the
branch name, so they both do something. My point is that they either both work
or both fail.)

[1]
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/1.6.6...

[Sebastian Noack, 2015/05/04 11:44:31]

If I understand the issue correctly, this change is rather pointless. As it
merely makes sure the Git.pull() fails if Git.update() would fail, to generate a
different output in an error scenario. But in the end of the day, either
ensure_dependency succeeds or fails regardless of this change. But on the other
hand this change would mess up the abstraction, and duplicates code that is even
executed redundantly.

[kzar, 2015/05/05 13:33:55]

Then you do not understand this change properly. Without this change if I set a
branch name as repository revision ensure_dependencies will fail.

The reason it fails is because we do not tell Git to checkout the revision until
we ensure it exists and that we can resolve it to a commit hash. The problem is
that the checkout in this case _causes_ the revision (branch name) to exist and
to be able to resolve to a commit hash.

We therefore need to attempt the checkout before we ensure the revision
resolves, hence my change.

If you think this change is redundant try it for yourself, create a Git
repository on Github or somewhere that contains a branch. Put the Git URL as the
dependency name and the branch name as the revision in your dependencies file
and see what the script does. Try it with and without my change, you will see
what I mean.

[Sebastian Noack, 2015/05/05 15:08:54]

Ok, got it. But this still seems like a silly hack to me. Why don't you just
change the git fetch command line to "git fetch --quiet origin <rev>" as I
initially suggested? Then we will explicitly fetch the revision we checkout in
the next step, without breaking the abstraction here.

[kzar, 2015/05/05 15:26:52]

The remote branch has already been fetched, we just need to create a tracking
branch for it. `git fetch origin branch-name` does not create a tracking branch
for the remote branch - `git checkout branch-name` does.

(Another way to create the tracking branch would be `git branch --track
branch-name origin/branch-name` but obviously that would fail if the specified
revision was a commit hash instead of a branch name, or if the tracking branch
had already been created. We could do it that way however and just ignore the
exceptions thrown I suppose.)

[Sebastian Noack, 2015/05/05 16:00:54]

I think I'd prefer that one. If something went wrong we still get an exception
indicating the error on "git fetch" or "git checkout". So It should be safe to
ignore errors here.

That way we don't need to mess with the abstraction at least. And .update()
won't behave incosistent for Mercurial and Git, unexpectly checking out a
revision on Git.

[Sebastian Noack, 2015/05/05 16:59:02]

But either way, this will only work if you specify a branch name. If you specify
a commit that isn't in any tracked branch or tag, it won't work as "git fetch
--all --tags" only fetches tracking branches and tags.

[Sebastian Noack, 2015/05/05 17:35:05]

After thinking a little more about the problem and discussing it with Wladimir,
we came to the conclusion that we have to implement Git.pull() like below, to
make it work like "hg pull" and to eliminate all limitations with git branches:

  # Make sure the local list of remote branches is up-to-date
  git fetch

  # Mark all remote branches as tracking
  for remote in `git branch --remotes`; do
    do git branch --track $remote
  done

  # Fetch all tracking branches and tags
  git fetch --all --tags

[kzar, 2015/05/06 11:04:44]

Done.

 
   def update(self, repo, rev):
     subprocess.check_call(["git", "checkout", "--quiet", rev], cwd=repo)
@@ -229,7 +230,7 @@ def update_repo(target, revisions):
   resolved_revision = repo_types[type].get_revision_id(target, revision)
   if not resolved_revision:
     logging.info("Revision %s is unknown, downloading remote changes" % revision)
-    repo_types[type].pull(target)
+    repo_types[type].pull(target, revision)
     resolved_revision = repo_types[type].get_revision_id(target, revision)
     if not resolved_revision:
       raise Exception("Failed to resolve revision %s" % revision)