Alexander Lamaison wrote:
> >>> The branch, HEAD has been created
> >>
> >> Alexander, that was a mistake, or wasn't it?
> >
> > Already being taken care of. :)
>
> Sorry, it was a mistake. That'll teach me to use TortoiseGit.
Did this happen using TortoiseGit?
> Thanks for telling me how to fix it Peter. Though it worries me
> that I have no idea why those commands work, they just do. That's
> git all over.
It can be complex because of git's distributed nature, which is
what allows code to flow in and out of branches asymmectrically.
Some background that may explain what happened:
When using git clone, the default remote name is "origin" (but could
be anything) and the default branch name is "master" (but could also
be anything).
When pushing to a remote repo, git needs to know which remote to push
to, which local commits to push, and which branch it should be pushed
into at the remote.
If using HEAD where a commit id can be specified then git translates
it to the most recent commit on the currently checked out branch.
It's also possible to specify a branch name instead of a commit id,
then the last commit on that branch will be used regardless of what
is checked out.
Thus, the canonical "default" push command would be:
git push origin master:master
"origin" is the remote nickname
The first "master" is the local branch name
The second "master" is the branch name at the remote
This is tedious to type, so git has shortcuts.
git push origin master
When only one branch name is specified, git uses it for both local
commit id(s) and remote branch, so master == master:master.
So if running:
git push origin HEAD
Then "HEAD" is used both as the local id (meaning the last commit on
currently checked out branch) as well as the branch name on the
remote. Pushing creates branches as neccessary. This could explain
the HEAD branch.
It's annoying to deal with these branch relationships on every push,
so it's possible to use .git/config to specify how local branches
relate to remote branches. For example:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://git.libssh2.org/var/lib/git/libssh2.git
push = master
[branch "master"]
remote = origin
merge = refs/heads/master
rebase = true
This explicitly says that when I try to pull when my local branch
named master ([branch "master"]) is checked out then I want stuff
from the libssh2.git repo (remote=origin) and specifically the branch
in that repo called master (merge=refs/heads/master) and finally that
any local changes should not be merged with what I fetch, but rather
"forward ported" or rebased (rebase=true).
When I try to push from my local branch master ([branch "master"]) I
will push my local branch named master into the branch named master
at the remote (push=master in the [remote] in remote=origin).
If more complex rules for what should be pushed to where is needed
then merge= together with [push] default=tracking can be used
instead, to specify that each of my local branches relate to a
particular remote branch with a different name. It should also be
possible to set [remote] push=local:remote in order to describe what
should go where.
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-02-22