From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:12
Johannes Schindelin [off-list ref] writes:
On Thu, 24 May 2007, skimo@liacs.nl wrote:
quoted
This patch series implements a mechanism for cloning submodules.
Each submodule is specified by a 'submodule.<submodule>.url'
configuration option, e.g.,
bash-3.00$ ./git-config --remote=http://www.liacs.nl/~sverdool/isa.git --get-regexp 'submodule\..*\.url'
submodule.cloog.url /home/sverdool/public_html/cloog.git
submodule.cloog.url http://www.liacs.nl/~sverdool/cloog.git
I am sorry to complain so late in the game, but I am not really interested
in submodules. However, what you say here is not a task for git-config
IMHO, but rather for git-remote.
Honestly speaking, I do not think people have no business
peeking into configuratoin remote repository has, and it would
be preferrable that supermodule Porcelain stuff does not rely on
that.
I am sorry to complain so late in the game, but I am not really interested
in submodules. However, what you say here is not a task for git-config
IMHO, but rather for git-remote.
Honestly speaking, I do not think people have no business
peeking into configuratoin remote repository has, and it would
be preferrable that supermodule Porcelain stuff does not rely on
that.
Maybe there are too many negations in that sentence, but are you
saying it is ok to look into the remote configuration or not?
skimo
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:12
Sven Verdoolaege [off-list ref] wrote:
On Wed, May 23, 2007 at 05:50:42PM -0700, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
I am sorry to complain so late in the game, but I am not really interested
in submodules. However, what you say here is not a task for git-config
IMHO, but rather for git-remote.
Honestly speaking, I do not think people have no business
peeking into configuratoin remote repository has, and it would
be preferrable that supermodule Porcelain stuff does not rely on
that.
Maybe there are too many negations in that sentence, but are you
saying it is ok to look into the remote configuration or not?
I think its OK to look at *your* .git/config to see what is
configured for the remotes, (e.g. git config remote.origin.url)
but it is NOT OK to look at the *remote*'s .git/config to see what
they have configured.
Why? Their configuration is their configuration. Who knows what
they have stored there. Look at the recent cvsserver config options,
there's now a lot of information about the SQL database that backs
cvsserver. That stuff shouldn't be public.
If you want to publish something for a client to fetch, it should
be done by publishing a Git object referenced by a proper ref:
blob, tree, commit, tag, take your pick.
--
Shawn.
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:12
On Thu, May 24, 2007 at 03:29:45AM -0400, Shawn O. Pearce wrote:
Why? Their configuration is their configuration. Who knows what
they have stored there. Look at the recent cvsserver config options,
there's now a lot of information about the SQL database that backs
cvsserver. That stuff shouldn't be public.
For http:// or rsync:// it's public already; for ssh://, if you are allowed
to access the git repo, you can read the config as well; for git://,
we can dump a predefined selection of configuration variables.
If you want to publish something for a client to fetch, it should
be done by publishing a Git object referenced by a proper ref:
blob, tree, commit, tag, take your pick.
You mean like a tag "submodules" that points to a text file
describing the submodules?
That's a bit of a pain to set up since you would want that
to be independent of your project.
skimo
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
On Thu, May 24, 2007 at 03:29:45AM -0400, Shawn O. Pearce wrote:
quoted
Why? Their configuration is their configuration. Who knows what
they have stored there. Look at the recent cvsserver config options,
there's now a lot of information about the SQL database that backs
cvsserver. That stuff shouldn't be public.
For http:// or rsync:// it's public already; for ssh://, if you are
allowed to access the git repo, you can read the config as well; for
git://, we can dump a predefined selection of configuration variables.
I sanitized a once-public repo, which was _not_ updated via http-push (in
which case you'd not see a meaningful config anyway), where the
permissions prevented the config from being read.
quoted
If you want to publish something for a client to fetch, it should be
done by publishing a Git object referenced by a proper ref: blob,
tree, commit, tag, take your pick.
You mean like a tag "submodules" that points to a text file
describing the submodules?
That's a bit of a pain to set up since you would want that
to be independent of your project.
I could imagine this to be another extension of ls-remote.
Ciao,
Dscho
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:12
On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
You mean like a tag "submodules" that points to a text file
describing the submodules?
That's a bit of a pain to set up since you would want that
to be independent of your project.
I could imagine this to be another extension of ls-remote.
You mean extending upload-pack ? Junio mentioned this possibility as well.
This only solves the git:// and ssh:// case though.
What to do with the other protocols?
Also, I don't really understand why it would be less of a hack
to add it to ls-remote than to add it to git-config.
The latter seems more natural to me.
skimo
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
You mean like a tag "submodules" that points to a text file
describing the submodules?
That's a bit of a pain to set up since you would want that
to be independent of your project.
I could imagine this to be another extension of ls-remote.
You mean extending upload-pack ? Junio mentioned this possibility as well.
This only solves the git:// and ssh:// case though.
What to do with the other protocols?
As we do for the refs: put it into .git/info/refs. This file is already
meant to "cache" the output of ls-remote for dumb protocols.
Also, I don't really understand why it would be less of a hack
to add it to ls-remote than to add it to git-config.
The latter seems more natural to me.
No, not at all. git-config is about the local data. It is _meant_ to be
private. Things you can receive by ls-remote are _meant_ to be public.
Ciao,
Dscho
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:12
On Thu, May 24, 2007 at 12:02:41PM +0100, Johannes Schindelin wrote:
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
quoted
I could imagine this to be another extension of ls-remote.
You mean extending upload-pack ? Junio mentioned this possibility as well.
This only solves the git:// and ssh:// case though.
What to do with the other protocols?
As we do for the refs: put it into .git/info/refs. This file is already
meant to "cache" the output of ls-remote for dumb protocols.
OK... so what should git-update-server-info put in this file for submodules?
Or, equivalently, what should be the output of ls-remote?
Right now its a list of pairs of revs(sha1) and refs.
For submodules we want a connection between a submodule name
and one or more URLs where the submodule can be found.
How are you going to squeeze that into info/refs without confusing
older versions of git?
skimo
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
On Thu, May 24, 2007 at 12:02:41PM +0100, Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
quoted
I could imagine this to be another extension of ls-remote.
You mean extending upload-pack ? Junio mentioned this possibility as well.
This only solves the git:// and ssh:// case though.
What to do with the other protocols?
As we do for the refs: put it into .git/info/refs. This file is already
meant to "cache" the output of ls-remote for dumb protocols.
OK... so what should git-update-server-info put in this file for submodules?
Or, equivalently, what should be the output of ls-remote?
Right now its a list of pairs of revs(sha1) and refs.
For submodules we want a connection between a submodule name
and one or more URLs where the submodule can be found.
How are you going to squeeze that into info/refs without confusing
older versions of git?
I wonder if the "ref^{blub}" syntax could be used for that: change "blub"
to the URL, or "sub:URL" or something.
Ciao,
Dscho
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:12
On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
OK... so what should git-update-server-info put in this file for submodules?
Or, equivalently, what should be the output of ls-remote?
Right now its a list of pairs of revs(sha1) and refs.
For submodules we want a connection between a submodule name
and one or more URLs where the submodule can be found.
How are you going to squeeze that into info/refs without confusing
older versions of git?
I wonder if the "ref^{blub}" syntax could be used for that: change "blub"
to the URL, or "sub:URL" or something.
Just to be clear, would it look like the following?
e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule
/home/sverdool/public_html/cloog.git cloog^{URL}
http://www.liacs.nl/~sverdool/cloog.git cloog^{URL}
Is there no code out there that expects the "rev" part to be
exactly 40 characters?
Or do you propose we put the URL in a blob and put the object sha1
in there. If so, who's going to create these blobs for the git://
and ssh:// protocols? upload-pack?
Thanks for the discussion, btw.
I hope we can come up with something that's acceptable to everyone.
skimo
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
OK... so what should git-update-server-info put in this file for submodules?
Or, equivalently, what should be the output of ls-remote?
Right now its a list of pairs of revs(sha1) and refs.
For submodules we want a connection between a submodule name
and one or more URLs where the submodule can be found.
How are you going to squeeze that into info/refs without confusing
older versions of git?
I wonder if the "ref^{blub}" syntax could be used for that: change "blub"
to the URL, or "sub:URL" or something.
Just to be clear, would it look like the following?
e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule
/home/sverdool/public_html/cloog.git cloog^{URL}
http://www.liacs.nl/~sverdool/cloog.git cloog^{URL}
I was more thinking about something like this:
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
But then, I haven't really thought about it deeply.
Ciao,
Dscho
From: Johannes Sixt <hidden> Date: 2016-06-15 22:43:12
Johannes Schindelin wrote:
I was more thinking about something like this:
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
where 3fa7ded... is the commit (gitlink) that appears in the tree?
-- Hannes
On 5/24/07, Sven Verdoolaege [off-list ref] wrote:
On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
OK... so what should git-update-server-info put in this file for submodules?
Or, equivalently, what should be the output of ls-remote?
Right now its a list of pairs of revs(sha1) and refs.
For submodules we want a connection between a submodule name
and one or more URLs where the submodule can be found.
How are you going to squeeze that into info/refs without confusing
older versions of git?
I wonder if the "ref^{blub}" syntax could be used for that: change "blub"
to the URL, or "sub:URL" or something.
Just to be clear, would it look like the following?
e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule
/home/sverdool/public_html/cloog.git cloog^{URL}
http://www.liacs.nl/~sverdool/cloog.git cloog^{URL}
Is there no code out there that expects the "rev" part to be
exactly 40 characters?
Or do you propose we put the URL in a blob and put the object sha1
in there. If so, who's going to create these blobs for the git://
and ssh:// protocols? upload-pack?
There was a thread about adding symrefs to this as:
ref: refs/heads/master HEAD
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
we could extend this for subproject support as:
subproject: kernel:URL refs/heads/master
subproject: gcc:URL refs/heads/master
And it allows to define different URL for different branches
(linux-2.6.git for master and linux-2.4.git for old, for example).
Just my 0.02 cents.
Santi
Thanks for the discussion, btw.
I hope we can come up with something that's acceptable to everyone.
skimo
-
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: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:12
On Thu, May 24, 2007 at 01:16:38PM +0100, Johannes Schindelin wrote:
I was more thinking about something like this:
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
As Johannes already indicated I don't think this rev makes sense.
I suppose we could just set it to 0.
I also don't think the URL should be associated to a ref.
skimo
From: Lars Hjemli <hidden> Date: 2016-06-15 22:43:12
On 5/24/07, Johannes Schindelin [off-list ref] wrote:
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
OK... so what should git-update-server-info put in this file for submodules?
Or, equivalently, what should be the output of ls-remote?
Right now its a list of pairs of revs(sha1) and refs.
For submodules we want a connection between a submodule name
and one or more URLs where the submodule can be found.
How are you going to squeeze that into info/refs without confusing
older versions of git?
I wonder if the "ref^{blub}" syntax could be used for that: change "blub"
to the URL, or "sub:URL" or something.
Just to be clear, would it look like the following?
e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule
/home/sverdool/public_html/cloog.git cloog^{URL}
http://www.liacs.nl/~sverdool/cloog.git cloog^{URL}
I was more thinking about something like this:
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
But then, I haven't really thought about it deeply.
I think the whole point of the 'remote config' stuff is to get an
unversioned/out-of-tree .gitmodules file, right?
If so, one could put this file into the object db and refer to it with
something like 'refs/tags/subproject-config' or even
'refs/misc/subproject-config'. Both of these refs will be found by
ls-remote and point to the object containing the suggested subproject
configuration.
I actually do something similar with the release tarballs for cgit: try
git ls-remote git://hjemli.net/pub/git/cgit
to see the references to the tarballs which are displayed on the cgit
summary page.
But then again, I might have completely misunderstood the problem...
--
larsh
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
Hi,
On Thu, 24 May 2007, Johannes Sixt wrote:
Johannes Schindelin wrote:
quoted
I was more thinking about something like this:
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
where 3fa7ded... is the commit (gitlink) that appears in the tree?
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
On Thu, May 24, 2007 at 01:16:38PM +0100, Johannes Schindelin wrote:
quoted
I was more thinking about something like this:
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
As Johannes already indicated I don't think this rev makes sense.
You like to confuse me, don't you?
I suppose we could just set it to 0.
I also don't think the URL should be associated to a ref.
It does not need to be.
But then, it is sort of a "subref": You could just clone the submodule in
its own right, correct?
Ciao,
Dscho
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:12
On Thu, May 24, 2007 at 02:17:27PM +0100, Johannes Schindelin wrote:
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
I suppose we could just set it to 0.
I also don't think the URL should be associated to a ref.
It does not need to be.
But then, it is sort of a "subref": You could just clone the submodule in
its own right, correct?
Exactly, but the information we want is not associated to any
particular revision of the submodule. It just points to the repo.
It's also not associated with any revision of the supermodule.
That information should go in a tracked .gitmodules file.
skimo
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:12
hoi :)
On Wed, May 23, 2007 at 05:50:42PM -0700, Junio C Hamano wrote:
Honestly speaking, I do not think people have no business
peeking into configuratoin remote repository has, and it would
be preferrable that supermodule Porcelain stuff does not rely on
that.
yes.
I would greatly appreciate having one standard repository format,
also for subprojects so that it is not possible to look into the
remote configuration.
However I do see that the site administrator might want to physically
separate the different subprojects which is difficult to support
in one big monolithic repository. But if additional information
about the physical location of subprojects is neccessary, then
that should be stored in something like .git/info/subprojects or
similiar, instead of the .git/config.
--
Martin Waitz
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
On Thu, May 24, 2007 at 02:17:27PM +0100, Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
I suppose we could just set it to 0.
I also don't think the URL should be associated to a ref.
It does not need to be.
But then, it is sort of a "subref": You could just clone the submodule in
its own right, correct?
Exactly, but the information we want is not associated to any
particular revision of the submodule. It just points to the repo.
It's also not associated with any revision of the supermodule.
That information should go in a tracked .gitmodules file.
It is not that expensive to just give the SHA-1 with the URL, and to
introduce a new namespace, say
3f... submodule/path^{URL:blablub}
to say that the submodule which is connected in "HEAD:path" is available
with the URL "blablub" and just so happens to be at commit "3f..." at the
moment. Heck, you can even use this instead of expensive fetches to verify
up-to-date, and even more, you can make sure that you are as up-to-date as
the remote supermodule.
But then, I do not care about that deeply. Like I said, I haven't followed
the discussions, but I really do not understand why an information as
essential to a superproject is not contained in something like
HEAD:.gitmodules. Git does not have to take it from there, it can still
continue to take it from a local config in .git/, but .gitmodules can live
in the tree happily, for the pleasure of the tools (if only to initialise
the first version of the local config after clone).
Without some very intrusive surgery into the transport code of Git, in 22
patches, which I am not at all comfortable with.
Ciao,
Dscho
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:12
On Thu, May 24, 2007 at 02:52:25PM +0100, Johannes Schindelin wrote:
It is not that expensive to just give the SHA-1 with the URL, and to
introduce a new namespace, say
3f... submodule/path^{URL:blablub}
to say that the submodule which is connected in "HEAD:path" is available
with the URL "blablub" and just so happens to be at commit "3f..." at the
moment. Heck, you can even use this instead of expensive fetches to verify
up-to-date, and even more, you can make sure that you are as up-to-date as
the remote supermodule.
What about all the other branches?
Also, the submodule may not even be in any of the tips of the branches.
Without some very intrusive surgery into the transport code of Git, in 22
patches, which I am not at all comfortable with.
You're not comfortable with the number or with the patches?
There's only about four or five that deal with this git-config stuff
and any other mechanism would have to implemented as well.
skimo
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
On Thu, May 24, 2007 at 02:52:25PM +0100, Johannes Schindelin wrote:
quoted
It is not that expensive to just give the SHA-1 with the URL, and to
introduce a new namespace, say
3f... submodule/path^{URL:blablub}
to say that the submodule which is connected in "HEAD:path" is available
with the URL "blablub" and just so happens to be at commit "3f..." at the
moment. Heck, you can even use this instead of expensive fetches to verify
up-to-date, and even more, you can make sure that you are as up-to-date as
the remote supermodule.
What about all the other branches?
Also, the submodule may not even be in any of the tips of the branches.
Okay, bad idea.
quoted
Without some very intrusive surgery into the transport code of Git, in 22
patches, which I am not at all comfortable with.
You're not comfortable with the number or with the patches?
There's only about four or five that deal with this git-config stuff
and any other mechanism would have to implemented as well.
If it was even only one, which is as intrusive, I would still be
uncomfortable. And yes, the large number does not make me want to review
the series either.
Ciao,
Dscho
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:12
Johannes Schindelin wrote:
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
quoted
quoted
OK... so what should git-update-server-info put in this file for submodules?
Or, equivalently, what should be the output of ls-remote?
Right now its a list of pairs of revs(sha1) and refs.
For submodules we want a connection between a submodule name
and one or more URLs where the submodule can be found.
How are you going to squeeze that into info/refs without confusing
older versions of git?
I wonder if the "ref^{blub}" syntax could be used for that: change "blub"
to the URL, or "sub:URL" or something.
Just to be clear, would it look like the following?
e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule
/home/sverdool/public_html/cloog.git cloog^{URL}
http://www.liacs.nl/~sverdool/cloog.git cloog^{URL}
I was more thinking about something like this:
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
But then, I haven't really thought about it deeply.
I was thinking about the following:
ref: refs/heads/master HEAD
e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/master:submodule/path
URL: /home/sverdool/public_html/cloog.git refs/heads/master:submodule/path^{URL}
URL: http://www.liacs.nl/~sverdool/cloog.git refs/heads/master:submodule/path^{URL}
By the way, it would be nice if git-show-refs --deferefence used TAB
between sha1 and ref name, like in git-ls-remote / git-peek-remote,
otherwise I think git-show-refs output parsers would fail on [proposed]
"current branch" extension.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
Hi,
On Fri, 25 May 2007, Jakub Narebski wrote:
Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
quoted
quoted
quoted
OK... so what should git-update-server-info put in this file for submodules?
Or, equivalently, what should be the output of ls-remote?
Right now its a list of pairs of revs(sha1) and refs.
For submodules we want a connection between a submodule name
and one or more URLs where the submodule can be found.
How are you going to squeeze that into info/refs without confusing
older versions of git?
I wonder if the "ref^{blub}" syntax could be used for that: change "blub"
to the URL, or "sub:URL" or something.
Just to be clear, would it look like the following?
e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule
/home/sverdool/public_html/cloog.git cloog^{URL}
http://www.liacs.nl/~sverdool/cloog.git cloog^{URL}
I was more thinking about something like this:
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
But then, I haven't really thought about it deeply.
I was thinking about the following:
ref: refs/heads/master HEAD
e8a6e39ecfbd391a54b9c3329fd3c6e33d745abd refs/heads/bernstein
c5c64e3fe48302f0c4581985f9c68d615f7bcb4e refs/heads/master
3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/master:submodule/path
URL: /home/sverdool/public_html/cloog.git refs/heads/master:submodule/path^{URL}
URL: http://www.liacs.nl/~sverdool/cloog.git refs/heads/master:submodule/path^{URL}
By the way, it would be nice if git-show-refs --deferefence used TAB
between sha1 and ref name, like in git-ls-remote / git-peek-remote,
otherwise I think git-show-refs output parsers would fail on [proposed]
"current branch" extension.
Well, I always hinted at it, and now officially retract my proposal. IMHO
.gitmodules is a much better place for that. It _belongs_ in the
repository, not just the config.
Ciao,
Dscho
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:13
hoi :)
On Thu, May 24, 2007 at 12:02:41PM +0100, Johannes Schindelin wrote:
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
quoted
On Thu, 24 May 2007, Sven Verdoolaege wrote:
quoted
You mean like a tag "submodules" that points to a text file
describing the submodules?
That's a bit of a pain to set up since you would want that
to be independent of your project.
I could imagine this to be another extension of ls-remote.
You mean extending upload-pack ? Junio mentioned this possibility as well.
This only solves the git:// and ssh:// case though.
What to do with the other protocols?
As we do for the refs: put it into .git/info/refs. This file is already
meant to "cache" the output of ls-remote for dumb protocols.
why on earth do you want to store a subproject SHA1 in the
superproject.git?
The subproject only exists as a part of the superproject tree and thus
there is no "the subproject SHA1 which is used by the superproject".
It just doesn't work as you can have several superproject branches with
different subproject. And even the superproject can itself be a
subproject.
--
Martin Waitz
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:13
On Sun, May 27, 2007 at 10:34:42PM +0200, Martin Waitz wrote:
On Thu, May 24, 2007 at 12:02:41PM +0100, Johannes Schindelin wrote:
quoted
As we do for the refs: put it into .git/info/refs. This file is already
meant to "cache" the output of ls-remote for dumb protocols.
why on earth do you want to store a subproject SHA1 in the
superproject.git?
Did you read that sentence after writing it?
Anyway, we already concluded further down the thread that
it wouldn't make sense to put any particular subproject SHA-1
in the superproject's info/refs.
skimo