Re: Problems setting up bare repository (git 1.5.3.3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Carl Worth <cworth@xxxxxxxxxx> wrote:
> $ git push /pub/git/foo.git master
> 
> Is there any reason that that shouldn't be interpreted as
> "master:master" and that that would in turn be interpreted as "create
> a remote refs/heads/master" ?

This is actually read more as:

 1) Expand "master" to "refs/heads/master"
 2) Expand "refs/heads/master" to "refs/heads/master:refs/heads/master"

We first try to expand the local name to an "absolute" local name,
then if the remote name is missing default it to the same as the
(now expanded) local name.  So "push origin master" is not read as
"push origin refs/haeds/master:master".

> PS. As someone who has written some new-user documentation for git,
> there are a few low-level git notions that I would like to avoid in
> that documentation. For example, one is FETCH_HEAD. In my first
> attempt at porting hgbook-chapter2 to git I found myself using
> FETCH_HEAD to simulate "hg incoming". Thankfully, I was able to
> rewrite it by taking advantage of remotes and using "master..origin"
> instead.

How about:

  git config alias.incoming 'log ..FETCH_HEAD'

?  Or do we need --reverse in there too to simulate "hg incoming"?
The thing is, FETCH_HEAD is a lot more powerful than a tracking
branch.  It can contain objects randomly pulled from another
repository (e.g. one shot pulls).
 
> Another example is "refs/heads". I avoided this partially by inly
> documenting how to push all branches with "--all", but I'd much rather
> be able to say that the user could git push URL branch
> another-branch..." or "git push URL --all" for convenience. Finally,
> git-push itself spews quite a bit of output with "refs/heads" in it
> that I don't think is useful at all. For talking with the user, git
> should say "branch master" not "refs/heads/master".

Agreed.  We do that in fetch.  We should do that in push.  We should
only mention "refs/*" if the user is pushing something funny, e.g.
pushing into the remote tracking branch space.  Or the stash.  Etc.
Tags and normal branches should be denoted as such.

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux