Follow-up Comment #7, sr #110378 (project administration):
> Thanks. Everything is fine, now, w/ these instructions.
Great! Good to hear that things are better. And I see that code has been
pushed. However I also see that there is a problem that needs to be fixed.
There are only two branches and those are "archive" and "p" branches. Neither
of those seem to be an intended main trunk master branch type of branch.
However the default branch at initial upload was set to the "master" branch,
which does not exist. And therefore when doing a pristine clone checkout
there is no default branch to set as the default. So something is amiss.
Were one of those branches intended to be the master copy branch? Or is that
still in process of happening?
> Strangely enough, i used instructions on that page to try to push
previously,
> w/ the remote in the form of:
>
> t...@git.sv.gnu.org:/srv/git/superopt.git
>
> Perhaps that is no longer a valid syntax? In any case, i will close this
> issue shortly. Thanks again.
The git tools recognize a URL for the repository. Being a URL as you know
there are many forms available for it. The man page for git-clone includes
the following explanation that instead of doing a poor summary I would just
include verbatim. But in summary I will say that
ssh://t...@git.savannah.gnu.org/srv/git/superopt.git is the canonical URL
syntax and t...@git.sv.gnu.org:/srv/git/superopt.git is the scp-like
alternative syntax and both are effectively equivalent. Also
git.savannah.gnu.org is the canonical of git.sv.gnu.org which is an official
alternative.
GIT URLS
In general, URLs contain information about the transport protocol, the
address of the remote server, and the path to the repository.
Depending
on the transport protocol, some of this information may be absent.
Git supports ssh, git, http, and https protocols (in addition, ftp,
and
ftps can be used for fetching, but this is inefficient and deprecated;
do not use it).
The native transport (i.e. git:// URL) does no authentication and
should be used with caution on unsecured networks.
The following syntaxes may be used with them:
o ssh://[user@]host.xz[:port]/path/to/repo.git/
o git://host.xz[:port]/path/to/repo.git/
o http[s]://host.xz[:port]/path/to/repo.git/
o ftp[s]://host.xz[:port]/path/to/repo.git/
An alternative scp-like syntax may also be used with the ssh protocol:
o [user@]host.xz:path/to/repo.git/
This syntax is only recognized if there are no slashes before the
first
colon. This helps differentiate a local path that contains a colon.
For
example the local path foo:bar could be specified as an absolute path
or ./foo:bar to avoid being misinterpreted as an ssh url.
And so we see the description of the URL syntaxes including the scp-like
syntax. It's personal preference as it is a client interpreted string. I
prefer the syntax with the protocol on the front because I think it is both
more self-documenting and also easier to edit on the fly to one of the other
different protocols.
However note that the path used by each of the protocols happens to be
incrementally different for all three. That's unfortunate but an
implementation detail of how each has been implemented. ssh is a real shell
login command and sees the actual /srv/git path. https/http share the web
server namespace with svn, hg, bzr, cvs and needs at least the /git path to
select that namespace. The anonymous but dedicated git:// protocol is the
only one that does not have a namespacing leading directory because git is all
that the git-daemon does. And so all three paths are slightly different of
necessity.
I'll mention that the ftp protocol is not supported at Savannah.
The git upstream documentation goes on to mention this following too.
The ssh and git protocols additionally support ~username expansion:
o ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
o git://host.xz[:port]/~[user]/path/to/repo.git/
o [user@]host.xz:/~[user]/path/to/repo.git/
I'll mention that Savannah does not support ~[user] syntax, please don't use
it. The actuality is that it does exist but the path to the user home
directory is an accident of implementation and one that might change and
likely will change in the future.
And the documention continues with more detail that is well worth exploring
too.
And just finishing this that I await your information on the default branch
for git so as to understand how things should be set up for a clean checkout.
_______________________________________________________
Reply to this item at:
<https://savannah.nongnu.org/support/?110378>
_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/
