It just so happens that I'm one of the guys working on git. So I'll
see what I can do to help you. :-D I don't know how extensive your
git experience is, so bear with me if I'm saying things you already
know.
On Apr 9, 2009, at 2:50 PM, N. Turnage wrote:
I've cloned (I think I should have pulled it instead) my main
project from my repo, created a branch and have been updating that
branch to 0.7.1.
Clone is, basically, just init, fetch, then checkout. Pull is a fetch
followed by a merge. The typical setup after a clone is that the
branches from the remote (site you pulled from) is saved as origin/*,
with your local master set up to track origin/master.
Pulling is useful to bring your local (already started) repository up
to date with a remote server. Cloning is what you do to start working
on something.
My extensions are set up as submodules, and work beautifully, but
the tag showing which version of the extensions I am using shows the
original tag/commit sha - (dash) the new tag/commit sha. Like this:
Submodules are useful, but are also a little bit bleeding edge. They
are not widely used, and as such, sometimes have odd problems. If you
encounter any serious problems, feel free to poke the git mailing list
<[email protected]>. The list is both for development and users and
we try to be friendly to everyone.
6906bb369339fa74674d41b638ad134a70980cc2 vendor/extensions/blog
(radiant069-5-g6906bb3)
782918fda1c2b3d5a659f1ea507aaa7c5cb2e410 vendor/extensions/comments
(0.6.9-1-g782918f)
07015cd85bca4af44a182775e7979e965f1acc94 vendor/extensions/copy_move
(heads/master)
b7e64f11037ccd0a0d07eb1a70fc90240ab6ec6e vendor/extensions/
page_attachments (0.6.9-4-gb7e64f1)
e4bd92f52b35222c1316f5b3c275534b5ad3407d vendor/extensions/search
(heads/master)
3302f3f7187b7d22924502e5cca3e57496c262be vendor/extensions/
share_layouts (heads/master)
e4bc04ebe6eb4f6946131f42248f181dea676439 vendor/extensions/sns
(radiant0.6.9-10-ge4bc04e)
b99e2cbf3689bd5074517c2a17b6e1ed5e6063b9 vendor/extensions/tags (pre-
radiant-0.7-5-gb99e2cb)
743a95be0f01696530f558e7f4934cc7e57d3ab8 vendor/plugins/
attachment_fu (743a95b)
Why is it displaying this way instead of just telling me which
commit I am using?
The short answer is: These are the commits you're using. The format is
as follows:
<full SHA-1> <pathname> (<description>)
The full SHA-1 is similar to SVN revision numbers, but longer. They
don't start at one and move up because a) there's no central place to
track that in git and b) it provides a form of security because the
SHA-1 is based on it's contents.
The description is either a branch name or something in the following
format: <tag>-<#>-g<SHA>. The tag is the most recent tag that
_doesn't_ contain the commit. # is the number of commits between the
commit in question and the tag. And SHA is the beginning of the full
SHA-1 (usually 6 characters). (This is the result of running `git
describe HEAD` in each submodule.)
It looks like copy/move, page attachments, and share layouts are all
on their master branch while blog, comments, page_attachments, sns,
and tags are all a commit of their own. This can happen if the origin
repo for them moved ahead of where your submodule has them. If you
want, you can (usually) update them by going into the submodule and
running `git pull`. Then you can `git add` the submodule and `git
commit` in the supermodule to update it's records.
I'm not sure what you were expecting to see, since I don't know the
details of your setup. But if this description isn't enough, I'll try
to help you get where you need to be.
Also, because I cloned my repo, instead of pulling it, how can I get
the branch on the server? Right now when I try and git push I get
the message that everything it up to date. Any info is appreciated.
Cloning should have set up the appropriate tracking information, but
would not have set up any push information. You might want to run a
command like the following, assuming the clone URL is also something
you can push to (i.e. not git:// or http://)
git config remote.origin.push refs/heads/*:refs/heads/*
Note that pushing to a non-bare repository (one that has a working
directory attached to it) isn't recommended, as it will change the
respository out from under you. You might want to change the push
line to something like "refs/heads/*:refs/remotes/home/*" and then
`git merge home/master` on the server instead. Or set up a bare
repository that both sides can clone from. (git --bare clone <URL>
site.git)
~~ Brian
_______________________________________________
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
