From: pedro rijo <hidden> Date: 2016-06-15 23:07:45
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)?
--
Thanks,
Pedro Rijo
From: Stefan Beller <hidden> Date: 2016-06-15 23:07:45
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 [off-list ref] wrote:
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)?
--
Thanks,
Pedro Rijo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Konstantin Khomoutov <hidden> Date: 2016-06-15 23:07:45
On Thu, 14 Jan 2016 18:17:48 +0000
pedro rijo [off-list ref] wrote:
If I clone a repo, the repo will be on a specific branch, the 'main'
(typically 'master') branch.
`git clone` checks out the branch which is pointed by by the HEAD ref in
the source repository.
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)?
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.
From: pedro rijo <hidden> Date: 2016-06-15 23:07:45
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 [off-list ref]:
On Thu, 14 Jan 2016 18:17:48 +0000
pedro rijo [off-list ref] wrote:
quoted
If I clone a repo, the repo will be on a specific branch, the 'main'
(typically 'master') branch.
`git clone` checks out the branch which is pointed by by the HEAD ref in
the source repository.
quoted
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)?
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.
From: Konstantin Khomoutov <hidden> Date: 2016-06-15 23:07:45
On Thu, 14 Jan 2016 18:40:15 +0000
pedro rijo [off-list ref] wrote:
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
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 [off-list ref] wrote:
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
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.githttps://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.githttps://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
From: Jeff King <hidden> Date: 2016-06-15 23:07:45
On Thu, Jan 14, 2016 at 06:40:15PM +0000, pedro rijo wrote:
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.
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
From: Jeff King <hidden> Date: 2016-06-15 23:07:45
On Thu, Jan 14, 2016 at 12:12:35PM -0700, Bryan Turner wrote:
The same thing works for GitHub. Here's the hazelcast/hazelcast repository:
bturner@ubuntu:~$ git remote-https
https://github.com/hazelcast/hazelcast.githttps://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.
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
From: pedro rijo <hidden> Date: 2016-06-15 23:07:46
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 [off-list ref]:
On Thu, Jan 14, 2016 at 12:12:35PM -0700, Bryan Turner wrote:
quoted
The same thing works for GitHub. Here's the hazelcast/hazelcast repository:
bturner@ubuntu:~$ git remote-https
https://github.com/hazelcast/hazelcast.githttps://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.
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