Find main branch

Hey,

If I clone a repo, the repo will be on a specific branch, the 'main' (typically 'master') branch.

Is there any direct command to find that main branch, since that information is present?

If so, is there any way to find it without actually cloning the repo (similar to git ls-remote)?

Looking at the capabilities the server sends you. (I forgot if there is a git command for it, but:)

# check for http://github.com/gitster/git ssh git@github.com git-upload-pack gitster/git 0104fc10eb5b87a75af2cb93a3932897572f2c544915 HEADmulti_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2:2.4.8~peff-symbolic-refs-iii-revenge-of-the-sith-1258-gc4b0e8b

Notice the "symref=HEAD:refs/heads/master", which is what you want.

On Thu, Jan 14, 2016 at 10:17 AM, pedro rijo <pedrorijo91@gmail.com> wrote:

On Thu, 14 Jan 2016 18:17:48 +0000 pedro rijo <pedrorijo91@gmail.com> wrote:

`git clone` checks out the branch which is pointed by by the HEAD ref in the source repository.

Run `git ls-remote <url>` and, record the SHA1 name of the HEAD ref, then look that name up in the list of the remaining refs.

Stefan Beller solution is based on the server, which may not be very easy to do when dealing with Github/Bitbucket/Gitlab and other God knows which provider.

Konstantin ls-remote solution is the one I'm already using, but if I have several branches on that commit, I will not be able to decide.

I thought that the 'main' branch information was stored in git, and possibly with some way to access it with a git command

Thanks, Pedro Rijo

2016-01-14 18:31 GMT+00:00 Konstantin Khomoutov <kostix+git@007spb.ru>:

On Thu, 14 Jan 2016 18:40:15 +0000 pedro rijo <pedrorijo91@gmail.com> wrote:

It *is* stored in the Git repository -- in the HEAD ref. The question of how to retreive precisely this bit of information -- I don't really know. Basically you want `git show-remote-ref --head` but Git does not have such a command, only `git show-ref` ;-)

On Thu, Jan 14, 2016 at 11:40 AM, pedro rijo <pedrorijo91@gmail.com> wrote:

It is, but unfortunately it's not stored in a way that a remote client can (easily) retrieve using porcelain commands. The HEAD ref on the remote is the "main" branch, but, as Konstantin's ls-remote command shows, the actual wire protocol data for HEAD is the SHA-1 of the tip commit for the branch, not the name.

As Stefan indicated, the way this is messaged to the client from the server is in the capabilities sent. There's generally not a good way to see this. However, one thing that you might try (assuming the you're using HTTPS to talk to the repository and you're on MacOS or Linux) is to manually run git-remote-https. For example, here's output for the atlassian/atlassian-refapp repository on Bitbucket:

bturner@ubuntu:~$ git remote-https https://bitbucket.org/atlassian/atlassian-refapp.git https://bitbucket.org/atlassian/atlassian-refapp.git | head list @refs/heads/master HEAD d9330a80b50b92b91bb82834f052e9c86ed55452 refs/heads/2.14-beta1 db3dbe4b6549d0ac1437415dbf1ffb750e33e28b refs/heads/JDEV-32966-fix-xsrfrequestvalidatortest e0331e00e5e73cd463f12c2947ef567edbb6b9f8 refs/heads/atlassian-refapp-2.2.7.x e0e562acf9fbdf5255a503a0916a06c52fc456be refs/heads/atlassian-refapp-2.2.x

(Note that the repetition of the remote URL here is necessary.) "git remote-https" is an interactive process, so when you first run it it won't do anything. "list" is a command I sent to the "git remote-https" process that's running. That leading "@refs/heads/master HEAD" means the remote HEAD is a symbolic ref pointing at the master branch. So master is the "main" branch.

The same thing works for GitHub. Here's the hazelcast/hazelcast repository:

bturner@ubuntu:~$ git remote-https https://github.com/hazelcast/hazelcast.git https://github.com/hazelcast/hazelcast.git | head list @refs/heads/master HEAD 988810c4b5c5195412c65357e06cbb0e51173258 refs/heads/3.1.8 bddfb328e4779bccec6f7788c94960f6292b02c9 refs/heads/3.2-fix-eacg 84e7d1006cd342c39afdf0ac520b5b04b8233d75 refs/heads/3.3.6 2e4ffc4f593de0869f0db9f7224f964f72dac15d refs/heads/3.4-gem d0a7d416b1220ef4badd98e42991dabe34c7beeb refs/heads/3.5.1 6a13721d33bdb07de23f5c505b689e2ee50d5abb refs/heads/3.5.3-ercssn 56676b20baae8668e731f17c9f3b9844ddd486d0 refs/heads/3.5.4

I'm not aware of a simple equivalent for SSH. Also, note that this "git remote-https" trick won't work on Windows. When you hit Enter after "list" it writes a CRLF, so the "git-remote-https" process compares "listCR" against its list of known commands and finds no match.

Hope this helps! Bryan Turner

On Thu, Jan 14, 2016 at 12:12:35PM -0700, Bryan Turner wrote:

There's no equivalent for ssh, because you're hooking in at the remote-helper layer, and ssh (and git://) are builtins, and http is not.

I mentioned "git remote" elsewhere in the thread, which is probably the least gross way (it's just ugly because it writes to a file instead of to stdout). But you can also snoop on the protocol:

  $ GIT_TRACE_PACKET=3 git ls-remote origin 3>&1 >/dev/null |
    perl -lne '/symref=(\S+)/ and print $1'
  HEAD:refs/heads/master

It would be nice if "git ls-remote" just had some way of printing the capabilities.

-Peff

Thanks guys, the last answer seems to work !

Wouldn't mind to have a git command that returned the main branch though :p

Thanks, Pedro Rijo

2016-01-14 21:13 GMT+00:00 Jeff King <peff@peff.net>:

Jeff King <peff@peff.net> writes:

I would agree that it would be nice to give an option to ls-remote to show which ones are symrefs pointing at what. You are being more ambitious than that, but I am not sure I would agree it is a good idea.

Most normal capabilities have no value to ordinary end users, and the symref= thing is interesting for them only because there isn't such an option in ls-remote (hence "capabilities" thing could be used as a poor-man's substitute).

On Fri, Jan 15, 2016 at 09:30:24AM -0800, Junio C Hamano wrote:

I thought it might be nice for any porcelain which tries to wrap `ls-remote`, make some decision based on the capabilities, and then invoke another plumbing command. But I guess that is probably slightly crazy, and nobody is doing it.

Something like `ls-remote --symrefs` probably would be a better place to start.

-Peff

On Thu, Jan 14, 2016 at 06:40:15PM +0000, pedro rijo wrote:

Right. Git used to guess, but that was not great exactly because of the ambiguity you have seen. Servers started publishing the value of the HEAD symref in git v1.8.4.3. I'd expect that to be available on any modern server.

There's unfortunately not a plumbing command to directly access the value, but "git remote set-head $remote -a" will query the remote and update refs/remotes/$remote/HEAD appropriately. As a bonus, if it's an older server that doesn't provide the HEAD value, it will fallback to the "old" heuristics (see guess_remote_head for details).

-Peff