* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 13:11 UTC (permalink / raw)
To: Lars Hjemli, Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <8c5c35580705240541j7f632fc4lbd308c9386c2bde6@mail.gmail.com>
On Thu, May 24, 2007 at 02:41:57PM +0200, Lars Hjemli wrote:
> I think the whole point of the 'remote config' stuff is to get an
> unversioned/out-of-tree .gitmodules file, right?
Yes.
> 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.
That's a possibility, but then...
On Thu, May 24, 2007 at 01:43:54PM +0200, Sven Verdoolaege wrote:
> 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?
I don't think you can expect the user to this herself.
skimo
^ permalink raw reply
* Re: HTTP trees trailing GIT trees
From: Panagiotis Issaris @ 2007-05-24 12:44 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20070523T161537-175@post.gmane.org>
Hi,
Panagiotis Issaris <takis.issaris <at> uhasselt.be> writes:
> Petr Baudis <pasky <at> suse.cz> writes:
> > On Wed, May 23, 2007 at 04:01:33PM CEST, Panagiotis Issaris wrote:
> > > I reported this to the person who had setup the repository:
> > > http://article.gmane.org/gmane.comp.video.ffmpeg.devel/51151
> > >
> > > But unfortunately, the problem seems to remain.
> > >
> > > Is this a known problem, or might this be a bug or misconfiguration?
> >
> > did any push happenned since the post-update hook was enabled? It
> > takes effect only after the next push. So far,
> >
> > http://git.mplayerhq.hu/ffmpeg/info/refs
> >
> > and
> >
> > http://git.mplayerhq.hu/ffmpeg/refs/heads/master
> >
> > is still out-of-sync (keeping this in sync is what is the job of the
> > post-update hook, or git-update-server-info respectively).
> >
>
> Yes, I'd think so, as Måns stated that he had enabled the hook on
> 2007-05-22 20:43:27. The last commit shown on http://git.mplayerhq.hu/
> through gitweb occurred 25 minutes ago ("Wed, 23 May 2007 13:46:11 +0000").
>
> Thanks for your fast reply.
I've checked both protocols from the same network now, unfortunately
without any improvements.
Furthermore, I've also started tracing, hoping to figure out what
the problem might be (or getting a hint from someone regarding
the possible cause).
The host which is involved:
nslookup 213.144.138.186
186.138.144.213.in-addr.arpa name = natsuki.mplayerhq.hu
Parts of the trace -f:
...
connect(4, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("213.144.138.186")}, 16) = -1 EINPROGRESS
(Operation now in progress)
...
send(4, "GET /ffmpeg/info/refs HTTP/1.1\r\n
User-Agent: curl/7.15.5
(i486-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3
libidn/0.6.5\r\n
Host: git.mplayerhq .hu\r\nAccept: */*\r\nPragma:
no-cache\r\n\r\n", 188, MSG_NOSIGNAL) = 188
...
recv(4, "HTTP/1.1 200 OK\r\nDate: Thu, 24 May 2007 12:27:05 GMT\r\n
Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4\r\n
Last-Modified: Thu, 24 May 2007 04:25:50 GMT\r\n
ETag: \"2c01f-79-ad720f80\"\r\nAccept-Ranges:
bytes\r\nContent-Length: 121\r\nContent-Type:
text/plain\r\n\r\nc30fa83981290671ed972835297fbe93ef9d1e58\t
refs/heads/master\nc30fa83981290671ed972835297fbe93ef9d1e58\t
refs/remotes/git-svn\n",
16384, MSG_NOSIGNAL) = 381
So, we're asking for /ffmpeg/info/refs, and the server is
returning c30fa8391812..., but, using GitWeb one can see
that c30fa839812... is not the last commit, this one is:
http://git.mplayerhq.hu/?p=ffmpeg;a=commit;
h=47d7dcb5a7d89f413064e7ef1b54d77e59fb8375
When using the git protocol, the trace shows this:
...
connect(3, {sa_family=AF_INET, sin_port=htons(9418),
sin_addr=inet_addr("213.144.138.186")}, 16) = 0
dup(3) = 4
write(4, "0032git-upload-pack /ffmpeg\0host=git.mplayerhq.hu\0",
50) = 50
read(3, "007c", 4) = 4
read(3, "47d7dcb5a7d89f413064e7ef1b54d77e59fb8375 HEAD\0multi_ack
thin-pack side-band side-band-64k ofs-delta shallow no-progress\n",
120) = 120
read(3, "003f", 4) = 4
read(3, "47d7dcb5a7d89f413064e7ef1b54d77e59fb8375
refs/heads/master\n", 59)
= 59
read(3, "0042", 4) = 4
read(3, "47d7dcb5a7d89f413064e7ef1b54d77e59fb8375
refs/remotes/git-svn\n", 62)
= 62
read(3, "0000", 4) = 4
...
So, here, I'd guess it's also asking for the latest revision and
apparantly receiving 47d7dcb5a... as the hash, which is correct (and
the same as GitWeb shows).
And hints? Any other info I can provide?
I've upgrade GIT hoping it solve the problem, but it doesn't. Some
versions, I've tried are git version 1.5.2.35.ga334 and git
version 1.5.2.
With friendly regards,
Takis
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Lars Hjemli @ 2007-05-24 12:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: skimo, Shawn O. Pearce, Junio C Hamano, git, Martin Waitz,
Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241315290.4648@racer.site>
On 5/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
>
> > On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
> > > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > > > 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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 12:39 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241315290.4648@racer.site>
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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Petr Baudis @ 2007-05-24 12:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: skimo, git, Junio C Hamano, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241033570.4648@racer.site>
On Thu, May 24, 2007 at 11:35:33AM CEST, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
>
> > On Thu, May 24, 2007 at 12:40:20AM +0100, Johannes Schindelin wrote:
> > > On Thu, 24 May 2007, skimo@liacs.nl wrote:
> > > > 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.
> >
> > Hmmm... git-remote does only local configuration and never gets
> > any information from the other side.
> > What would be the interface and how would you get the information?
>
> I was complaining that git-config, which is purely a local beast, gets
> infected with even more obscure stuff. Junio mentions regularly that he
> does not trust git-config that much, and given the number of fixes we
> still get, I have to agree. So let's not put any more stuff into that
> kitchen sink, especially if it has nothing to do with the configuration of
> your repo.
Then again, git-remote is purely a local beast too, isn't it?
We could use git-remote-config for accessing remote configuration (if
it's a good idea at all, which I'm not totally convinced about)... (And
hope people don't confuse it with stuff related to git-remote too much.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Santi Béjar @ 2007-05-24 12:23 UTC (permalink / raw)
To: skimo
Cc: Johannes Schindelin, Shawn O. Pearce, Junio C Hamano, git,
Martin Waitz, Alex Riesen
In-Reply-To: <20070524114354.GN942MdfPADPa@greensroom.kotnet.org>
On 5/24/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
> > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > > 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
>
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Sixt @ 2007-05-24 12:23 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705241315290.4648@racer.site>
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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 12:16 UTC (permalink / raw)
To: skimo; +Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <20070524114354.GN942MdfPADPa@greensroom.kotnet.org>
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
> > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > > 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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 11:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241230410.4648@racer.site>
On Thu, May 24, 2007 at 12:31:33PM +0100, Johannes Schindelin wrote:
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > 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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 11:31 UTC (permalink / raw)
To: skimo; +Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <20070524111645.GK942MdfPADPa@greensroom.kotnet.org>
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> On Thu, May 24, 2007 at 12:02:41PM +0100, Johannes Schindelin wrote:
> > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > > On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
> > > > 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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 11:16 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241201270.4648@racer.site>
On Thu, May 24, 2007 at 12:02:41PM +0100, Johannes Schindelin wrote:
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
> > > 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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 11:02 UTC (permalink / raw)
To: skimo; +Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <20070524105112.GI942MdfPADPa@greensroom.kotnet.org>
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
> > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > > 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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 10:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241033570.4648@racer.site>
On Thu, May 24, 2007 at 10:35:33AM +0100, Johannes Schindelin wrote:
> I was complaining that git-config, which is purely a local beast, gets
> infected with even more obscure stuff. Junio mentions regularly that he
> does not trust git-config that much, and given the number of fixes we
> still get, I have to agree. So let's not put any more stuff into that
> kitchen sink, especially if it has nothing to do with the configuration of
> your repo.
Well, the name has been changed from git-repo-config some time ago...
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 10:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241039200.4648@racer.site>
On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > 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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 9:41 UTC (permalink / raw)
To: skimo; +Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <20070524073652.GH942MdfPADPa@greensroom.kotnet.org>
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> 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.
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.
> > 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
^ permalink raw reply
* gitk: clicking a branch line doesn't stop patch generator
From: Johannes Sixt @ 2007-05-24 9:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
Hi!
When a commit is highlighted, git-show or equivalent is spawned to fill
the patch window. When a different commit is highlighted, appearently if
git-show is still running, it is killed and a new one is started.
However, if a branch line is clicked, a running git-show is not killed,
hence its output is appended below the "Parent" and "Child" sections.
To reproduce, fire up gitk without arguments on git.git. Go all the way
down to the initial commit and select "Diff this->selected" from the
context menu, then quickly click on a line between two commits.
Unless your machine is blazingly fast, you will see that patch text is
appended below the "Child" section. Try with linux-2.6.git if git.git is
too small a project.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: Johannes Schindelin @ 2007-05-24 9:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Dana How, Git Mailing List
In-Reply-To: <20070524071235.GL28023@spearce.org>
Hi,
On Thu, 24 May 2007, Shawn O. Pearce wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > "Dana How" <danahow@gmail.com> writes:
> >
> > > The packed X too big combination is the problem. As the
> > > commit message says, this could happen if the packs
> > > came from fast-import,...
> > > We have three options in this case:
> > > (1) Drop the object (do not put it in the new pack(s)).
> > > (2) Pass the object into the new pack(s).
> > > (3) Write out the object as a new loose object.
> > >
> > > Option (1) is unacceptable. When you call git-repack -a,
> > > it blindly deletes all the non-kept packs at the end. So
> > > the megablobs would be lost.
> >
> > Ok, I can buy that -- (1) nor (2) are unacceptable and (3) is
> > the only sane thing to do for a previously packed objects that
> > exceed the size limit.
>
> I still don't buy the idea that these megablobs shouldn't be packed.
> I understand Dana's pain here (at least a little bit, my problems
> aren't as bad as his are), but I also hate to see us run away from
> packfiles for these really sick cases just because we have some
> issues in our current packfile handling.
Isn't this issue helpable by the "-delta" attribute?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 9:35 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano, Martin Waitz, Alex Riesen
In-Reply-To: <20070524072404.GF942MdfPADPa@greensroom.kotnet.org>
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> On Thu, May 24, 2007 at 12:40:20AM +0100, Johannes Schindelin wrote:
> > On Thu, 24 May 2007, skimo@liacs.nl wrote:
> > > 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.
>
> Hmmm... git-remote does only local configuration and never gets
> any information from the other side.
> What would be the interface and how would you get the information?
I was complaining that git-config, which is purely a local beast, gets
infected with even more obscure stuff. Junio mentions regularly that he
does not trust git-config that much, and given the number of fixes we
still get, I have to agree. So let's not put any more stuff into that
kitchen sink, especially if it has nothing to do with the configuration of
your repo.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix git-svn to handle svn not reporting the md5sum of a file, and test.
From: Eric Wong @ 2007-05-24 9:16 UTC (permalink / raw)
To: James Y Knight; +Cc: git
In-Reply-To: <1179981426176-git-send-email-foom@fuhm.net>
James Y Knight <foom@fuhm.net> wrote:
Thanks.
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
> git-svn.perl | 2 +-
> t/t9112-git-svn-md5less-file.sh | 45 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 46 insertions(+), 1 deletions(-)
> create mode 100755 t/t9112-git-svn-md5less-file.sh
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 3c4f490..b2773dc 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -2471,7 +2471,7 @@ sub close_file {
> $md5->addfile($fh);
> my $got = $md5->hexdigest;
> die "Checksum mismatch: $path\n",
> - "expected: $exp\n got: $got\n" if ($got ne $exp);
> + "expected: $exp\n got: $got\n" if (defined $exp && $got ne $exp);
> sysseek($fh, 0, 0) or croak $!;
> if ($fb->{mode_b} == 120000) {
> sysread($fh, my $buf, 5) == 5 or croak $!;
> diff --git a/t/t9112-git-svn-md5less-file.sh b/t/t9112-git-svn-md5less-file.sh
> new file mode 100755
> index 0000000..08313bb
> --- /dev/null
> +++ b/t/t9112-git-svn-md5less-file.sh
> @@ -0,0 +1,45 @@
> +test_description='test that git handles an svn repository with missing md5sums'
> +
> +. ./lib-git-svn.sh
> +
> +# Loading a node from a svn dumpfile without a Text-Content-Length
> +# field causes svn to neglect to store or report an md5sum. (it will
> +# calculate one if you had put Text-Content-Length: 0). This showed
> +# up in a repository creted with cvs2svn.
> +
> +cat > dumpfile.svn <<EOF
> +SVN-fs-dump-format-version: 1
> +
> +Revision-number: 1
> +Prop-content-length: 98
> +Content-length: 98
> +
> +K 7
> +svn:log
> +V 0
> +
> +K 10
> +svn:author
> +V 4
> +test
> +K 8
> +svn:date
> +V 27
> +2007-05-06T12:37:01.153339Z
> +PROPS-END
> +
> +Node-path: md5less-file
> +Node-kind: file
> +Node-action: add
> +Prop-content-length: 10
> +Content-length: 10
> +
> +PROPS-END
> +
> +EOF
> +
> +test_expect_success 'load svn dumpfile' "svnadmin load $rawsvnrepo < dumpfile.svn"
> +
> +test_expect_success 'initialize git-svn' "git-svn init $svnrepo"
> +test_expect_success 'fetch revisions from svn' 'git-svn fetch'
> +test_done
> --
> 1.5.2.rc2.1.g7f0b
>
--
Eric Wong
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 7:36 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Johannes Schindelin, git, Martin Waitz,
Alex Riesen
In-Reply-To: <20070524072945.GO28023@spearce.org>
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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Shawn O. Pearce @ 2007-05-24 7:29 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, Johannes Schindelin, git, Martin Waitz,
Alex Riesen
In-Reply-To: <20070524072216.GE942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Wed, May 23, 2007 at 05:50:42PM -0700, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > > 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.
^ permalink raw reply
* Re: [PATCH 11/22] entry.c: optionally checkout submodules
From: Alex Riesen @ 2007-05-24 7:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: skimo@liacs.nl, git, Junio C Hamano, Martin Waitz
In-Reply-To: <20070524071819.GN28023@spearce.org>
On 5/24/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Alex Riesen <raa.lkml@gmail.com> wrote:
> > On 5/24/07, skimo@liacs.nl <skimo@liacs.nl> wrote:
> >
> > >+ args[argc++] = "checkout";
> > >+ if (state->force)
> > >+ args[argc++] = "-f";
> > >+ args[argc++] = sha1_to_hex(ce->sha1);
> > >+ args[argc] = NULL;
> >
> > You should consider passing "-v" if the superprojects read-tree
> > had it. Some submodules will be annoyingly big
>
> In 1.5.2 that -v shouldn't be necessary. The read-tree should
It is necessary. Progress meters may not stay forever the only
thing to show when verbose. The code just stripped a part of
users command, how _can_ this be ok?!
> start a timer, and if it has not reached 50% of its processing
> within 2 seconds it starts showing progress. Unless !istty(2),
> in which case it just sits there, chugging away at your drive.
>
> I'm actually really unhappy with our !istty(2) means disable
> progress thing. git-gui knows how to read and show the progress
> meters, but nobody prints them anymore as 2 is a pipe. I have the
Somebody does: just because some stupid script in the middle
did a 2>&1.
> same problem with a Java build tool that sometimes starts up an
> expensive Git operation (like a clone over SSH of a 60+ MiB project).
That said, many tools have explicit --progress switch. Maybe _this_ is
what you need, and not an override whether STDERR is on a tty.
BTW, you could have used ptys, at least on UNIX-like platforms.
^ permalink raw reply
* Re: [PATCH 11/22] entry.c: optionally checkout submodules
From: Sven Verdoolaege @ 2007-05-24 7:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Alex Riesen, git, Junio C Hamano, Martin Waitz
In-Reply-To: <20070524071819.GN28023@spearce.org>
On Thu, May 24, 2007 at 03:18:19AM -0400, Shawn O. Pearce wrote:
> Alex Riesen <raa.lkml@gmail.com> wrote:
> > On 5/24/07, skimo@liacs.nl <skimo@liacs.nl> wrote:
> >
> > >+ args[argc++] = "checkout";
> > >+ if (state->force)
> > >+ args[argc++] = "-f";
> > >+ args[argc++] = sha1_to_hex(ce->sha1);
> > >+ args[argc] = NULL;
> >
> > You should consider passing "-v" if the superprojects read-tree
> > had it. Some submodules will be annoyingly big
>
> In 1.5.2 that -v shouldn't be necessary. The read-tree should
> start a timer, and if it has not reached 50% of its processing
> within 2 seconds it starts showing progress. Unless !istty(2),
> in which case it just sits there, chugging away at your drive.
Well, git-checkout.sh has this line:
merge_error=$(git-read-tree $submodules -m -u --exclude-per-directory=.gitignore $old $new 2>&1) || (
so actually you don't see anything right now when a submodule
checkout is going on during a checkout of the supermodule.
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 7:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705240039370.4113@racer.site>
On Thu, May 24, 2007 at 12:40:20AM +0100, Johannes Schindelin wrote:
> On Thu, 24 May 2007, skimo@liacs.nl wrote:
> > 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.
Hmmm... git-remote does only local configuration and never gets
any information from the other side.
What would be the interface and how would you get the information?
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 7:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Martin Waitz, Alex Riesen
In-Reply-To: <7vtzu3yrh9.fsf@assigned-by-dhcp.cox.net>
On Wed, May 23, 2007 at 05:50:42PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > On Thu, 24 May 2007, skimo@liacs.nl wrote:
> >> 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.
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox