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
On Sun, Sep 9, 2012 at 2:44 PM, Daniel DeLeo firstname.lastname@example.org 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
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
The way git works, the code will be the same if the revision SHA is the
same. The branch is irrelevant.
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!