Git resource branch vs revision vs reference


#1

in the deploy resource, it seems that branch, revision, and reference
are all references to each other.

on one system, I would like to deploy the HEAD revision of the prod branch
on another system, I would like to deploy the HEAD revision of the dev branch
on a third system, I would like to deploy a specific revision
(specified by hash) within the prod branch

I’ve noticed that if I specify HEAD, it will pull the latest head, but
if I specify prod or dev, it sometimes pulls the latest code, and
sometimes does not.
If I specify the hash, how will I know that it is pulling from the right branch?

yay.

in git, branch and revision are wholly different things… is there a
reason the resource treats them identically? how should I be doing
what I want here?

thanks all in advance!


#2

On Sunday, September 9, 2012 at 6:37 AM, Jesse Campbell wrote:

in the deploy resource, it seems that branch, revision, and reference
are all references to each other.

on one system, I would like to deploy the HEAD revision of the prod branch
on another system, I would like to deploy the HEAD revision of the dev branch
on a third system, I would like to deploy a specific revision
(specified by hash) within the prod branch

I’ve noticed that if I specify HEAD, it will pull the latest head, but
if I specify prod or dev, it sometimes pulls the latest code, and
sometimes does not.
If I specify the hash, how will I know that it is pulling from the right branch?

The way git works, the code will be the same if the revision SHA is the same. The branch is irrelevant.

yay.

in git, branch and revision are wholly different things… is there a
reason the resource treats them identically? how should I be doing
what I want here?

A branch is just a layer of indirection (i.e., a pointer) around a SHA. The git provider uses git ls-remote to resolve a branch or tag to a SHA (you can do this on a local git repo with git rev-parse THING). If you read the git manual pages you’ll often see references to a “commit-ish”, because git treats branches and tags as ways to name a particular commit.

If you look at the debug logs while running the git resource you can see the commands it runs and the results.

thanks all in advance!
HTH,


Daniel DeLeo


#3

So what am I getting when I specify “HEAD”, and how is that different
from specifying “master” ?
It was reverting to an old commit when I used “master”, and when I
switched over to HEAD it pulled the latest…
or will it only download HEAD or master once, do I need to get in the
habit of always specifying an SHA for it to actually update each time?

$ git ls-remote origin
8413dcd5b4fb91206f5d86c55bb3b67fc43509e2 HEAD
ba13b94837b48851543f383ec61bcc8ba08a2b98 refs/heads/atl_prod
8413dcd5b4fb91206f5d86c55bb3b67fc43509e2 refs/heads/master
ba13b94837b48851543f383ec61bcc8ba08a2b98 refs/pull/1/head
98780812f695c3f1fda6e6dbfdc398153a7042ef refs/pull/1/merge

On Sun, Sep 9, 2012 at 2:44 PM, Daniel DeLeo dan@kallistec.com wrote:

On Sunday, September 9, 2012 at 6:37 AM, Jesse Campbell wrote:

in the deploy resource, it seems that branch, revision, and reference
are all references to each other.

on one system, I would like to deploy the HEAD revision of the prod branch
on another system, I would like to deploy the HEAD revision of the dev
branch
on a third system, I would like to deploy a specific revision
(specified by hash) within the prod branch

I’ve noticed that if I specify HEAD, it will pull the latest head, but
if I specify prod or dev, it sometimes pulls the latest code, and
sometimes does not.
If I specify the hash, how will I know that it is pulling from the right
branch?

The way git works, the code will be the same if the revision SHA is the
same. The branch is irrelevant.

yay.

in git, branch and revision are wholly different things… is there a
reason the resource treats them identically? how should I be doing
what I want here?

A branch is just a layer of indirection (i.e., a pointer) around a SHA. The
git provider uses git ls-remote to resolve a branch or tag to a SHA (you
can do this on a local git repo with git rev-parse THING). If you read the
git manual pages you’ll often see references to a “commit-ish”, because git
treats branches and tags as ways to name a particular commit.

If you look at the debug logs while running the git resource you can see the
commands it runs and the results.

thanks all in advance!

HTH,


Daniel DeLeo


#4

On Monday, September 10, 2012 at 8:38 AM, Jesse Campbell wrote:

So what am I getting when I specify “HEAD”, and how is that different
from specifying “master” ?
It was reverting to an old commit when I used “master”, and when I
switched over to HEAD it pulled the latest…
or will it only download HEAD or master once, do I need to get in the
habit of always specifying an SHA for it to actually update each time?

$ git ls-remote origin
8413dcd5b4fb91206f5d86c55bb3b67fc43509e2 HEAD
ba13b94837b48851543f383ec61bcc8ba08a2b98 refs/heads/atl_prod
8413dcd5b4fb91206f5d86c55bb3b67fc43509e2 refs/heads/master
ba13b94837b48851543f383ec61bcc8ba08a2b98 refs/pull/1/head
98780812f695c3f1fda6e6dbfdc398153a7042ef refs/pull/1/merge

HEAD is the tip of the current branch. Example from my clone of the Chef source:

ddeleo@lorentz chef git:(master)> git rev-parse HEAD
722bc99041b03aaf98c099ee46e14f724cc33018
ddeleo@lorentz chef git:(master)> git co 10-stable
Switched to branch '10-stable’
ddeleo@lorentz chef git:(10-stable)> git rev-parse HEAD
a77c5ae6dd24af6c06035fb3df0284b8a4a9c265

My understanding is that HEAD on a github repo will simply be the newest commit on whatever branch is the default, usually master.

As for the behavior you’re describing, the git provider should always put you on the latest revision of a branch. You need to look at the debug logs to see what’s going on. If it’s putting you on the wrong revision, that’s a bug.


Daniel DeLeo