Git development
 help / color / mirror / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: when is a remote a branch?
Date: Sun, 12 Nov 2006 17:36:24 +0100	[thread overview]
Message-ID: <20061112163624.GE7201@pasky.or.cz> (raw)
In-Reply-To: <ej7h1n$ed8$1@sea.gmane.org>

On Sun, Nov 12, 2006 at 05:11:41PM CET, Jakub Narebski wrote:
> Read Documentation/repository-layout.txt (ot it's HTML version, either
> locally ot at www.kernel.org).
> 
>  branches::
>          A slightly deprecated way to store shorthands to be used
>          to specify URL to `git fetch`, `git pull` and `git push`
>          commands is to store a file in `branches/'name'` and
>          give 'name' to these commands in place of 'repository'
>          argument.
> 
> You can store only one branch to fetch per shorthand. I'm not sure about
> where it is stored which branch to download, and how to name this branch 
> locally.

I think the above is quite confusing description. This really is not
about any "shorthands" at all, but just about branches (how the name
implies, after all).

Git and Cogito share the same models of branches. These branches are
'heads' with commit pointers stored in refs/heads/, etc. The branches/
directory says that some branches do not correspond to local development
(and should never be used for that) but instead they correspond to a
particular branch in some remote repository. Such branches are called
"REMOTE BRANCHES".

So it's "if branch X has corresponding .git/branch/X file, it's not a
local branch but instead a REMOTE BRANCH corresponding to the URL stored
in that file". That simple. The URL is address of the repository plus
optionally a '#branchname' if the branch name in the remote repository
should not default to remote HEAD or master.

In addition, Git (not Cogito at this point) supports a completely
different and unrelated abstraction called REMOTES. They don't have
anything to do with branches. Instead, a REMOTE represents a repository
URL and a set of local/remote branch pairs to handle on pulls and
pushes; it has no other obvious mapping to branches and branches can be
even shared between various REMOTES etc. (this is changing lately with
the refs/remotes/ hierarchy, but I think that's still not in wide use).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

  reply	other threads:[~2006-11-12 16:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-12 15:50 when is a remote a branch? Anand Kumria
2006-11-12 16:11 ` Jakub Narebski
2006-11-12 16:36   ` Petr Baudis [this message]
2006-11-12 17:31     ` Jakub Narebski
2006-11-14 20:28       ` Petr Baudis
2006-11-14 20:36         ` Jakub Narebski
2006-11-14 20:44           ` Petr Baudis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061112163624.GE7201@pasky.or.cz \
    --to=pasky@suse.cz \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox