From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:45:28
Wang Chen wrote:
quoted
So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
1.5.3.x)
My git version is 1.5.5.1, although it doesn't matter ;)
http transport requires that "git update-server-info" is done after each
push. Otherwise, it ends up in a trainwreck.
Shawn Pierce at Google is working on a long-term solution, but in the
meantime, if you have to use http transport, murder your IT people.
-hpa
From: Wang Chen <hidden> Date: 2016-06-15 22:45:28
H. Peter Anvin said the following on 2008-10-10 23:58:
Wang Chen wrote:
quoted
quoted
So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
1.5.3.x)
My git version is 1.5.5.1, although it doesn't matter ;)
http transport requires that "git update-server-info" is done after each
push. Otherwise, it ends up in a trainwreck.
Shawn Pierce at Google is working on a long-term solution, but in the
meantime, if you have to use http transport, murder your IT people.
So, the current solutions are:
1. Waiting for Shawn fixing it.
2. Asking Ingo to "git update-server-info" after each push.
3. Murdering our IT people.
I'd rather to do the second solution than the third one :)
Ingo, will you do "git update-server-info" after each push before
Shawn fix this problem?
From: Lars Hjemli <hidden> Date: 2016-06-15 22:45:28
On Sun, Oct 12, 2008 at 13:28, Wang Chen [off-list ref] wrote:
H. Peter Anvin said the following on 2008-10-10 23:58:
quoted
Wang Chen wrote:
quoted
quoted
So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
1.5.3.x)
My git version is 1.5.5.1, although it doesn't matter ;)
http transport requires that "git update-server-info" is done after each
push. Otherwise, it ends up in a trainwreck.
Shawn Pierce at Google is working on a long-term solution, but in the
meantime, if you have to use http transport, murder your IT people.
So, the current solutions are:
1. Waiting for Shawn fixing it.
2. Asking Ingo to "git update-server-info" after each push.
3. Murdering our IT people.
4. Install cgit, which removes the need for `git update-server-info`
--
larsh
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:45:28
Wang Chen wrote:
So, the current solutions are:
1. Waiting for Shawn fixing it.
2. Asking Ingo to "git update-server-info" after each push.
3. Murdering our IT people.
I'd rather to do the second solution than the third one :)
Actually, the third solution is the proper one given the circumstances
you find yourself in. None of this would be a problem if there wasn't a
bunch of companies with incompetent network management.
-hpa
So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
1.5.3.x)
My git version is 1.5.5.1, although it doesn't matter ;)
http transport requires that "git update-server-info" is done after
each push. Otherwise, it ends up in a trainwreck.
can i simply put "git update-server-info" into .git/hooks/post-receive
to solve this problem?
post-update, rather than post-receive.
The standard post-update.sample contains it, it just needs a rename.
hm, -tip's .git/hooks/post-update already contained this, for the last 2
months:
exec git update-server-info
so ... _despite_ us having this in the git repo, the HTTP protocol still
does not work. Why?
Ingo
From: Petr Baudis <hidden> Date: 2016-06-15 22:45:28
On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
hm, -tip's .git/hooks/post-update already contained this, for the last 2
months:
exec git update-server-info
so ... _despite_ us having this in the git repo, the HTTP protocol still
does not work. Why?
I think your problem is that HTTP does not know where to look for
objects coming from alternates; IIRC this would work if you used
relative paths in objects/info/alternates, or you can create
objects/info/http-alternates like
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
quoted
hm, -tip's .git/hooks/post-update already contained this, for the last 2
months:
exec git update-server-info
so ... _despite_ us having this in the git repo, the HTTP protocol still
does not work. Why?
I think your problem is that HTTP does not know where to look for
objects coming from alternates; IIRC this would work if you used
relative paths in objects/info/alternates, or you can create
objects/info/http-alternates like
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
ok, i've now set it up like this:
$ pwd
/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
$ cat objects/info/alternates
/home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
$ cat objects/info/http-alternates
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
and i've added "git update-server-info" to hooks/post-receive and made
it chmod +x.
that should be golden, right? I'm wondering why this isnt in the default
setup - i've been behind a limited corporate firewall in a former life
and having HTTP access is indeed very handy and pragmatic. Often hotel
WLANs are HTTP only as well.
Soapbox: in fact it would be outright stupid to limit the kernel
source's availability artificially by not making HTTP a tier-one access
method.
Fighting against HTTP-only firewalls is like constantly pointing it out
to the popular press that they should say 'cracker' instead of 'hacker'.
It is pointless and only hurts the availability our own project.
Ingo
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:28
Ingo Molnar [off-list ref] writes:
Soapbox: in fact it would be outright stupid to limit the kernel
source's availability artificially by not making HTTP a tier-one access
method.
Fighting against HTTP-only firewalls is like constantly pointing it out
to the popular press that they should say 'cracker' instead of 'hacker'.
It is pointless and only hurts the availability our own project.
Hopefully there should soon be here "smart" HTTP server (as for
example CGI script), which encapsulates git protocol, modified for the
fact that HTTP is stateless protocol, in HTTP. It would unfortunately
require git installed on server.
It is WIP, but I'm not sure how far it is from completion.
--
Jakub Narebski
Poland
ShadeHawk on #git
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:28
Jakub Narebski [off-list ref] wrote:
Ingo Molnar [off-list ref] writes:
quoted
Soapbox: in fact it would be outright stupid to limit the kernel
source's availability artificially by not making HTTP a tier-one access
method.
Hopefully there should soon be here "smart" HTTP server [...]
It is WIP, but I'm not sure how far it is from completion.
Its still not even prototyped. I'm supposed to be spending my 20%
time at Google on the Git-in-HTTP documentation and implementation,
so I can feed patches to the list for review.
Sadly, my current 80% project has been demanding >120% of my time
these past 5 weeks, so I have not been able to touch the Git-in-HTTP
concept in that time period.
Most of my 80% project has to be wrapped up by this time next
week. Afterwards I'm going to try and dedicate at least a week
to Git-in-HTTP and get caught up. I sort of have to; its part of
my goals for my performance evaluation. Even if the list winds
up rejecting my implementation, I still have to put it out there
for discussion.
--
Shawn.
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:45:28
Petr Baudis wrote:
On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
quoted
hm, -tip's .git/hooks/post-update already contained this, for the last 2
months:
exec git update-server-info
so ... _despite_ us having this in the git repo, the HTTP protocol still
does not work. Why?
I think your problem is that HTTP does not know where to look for
objects coming from alternates; IIRC this would work if you used
relative paths in objects/info/alternates, or you can create
objects/info/http-alternates like
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
Yes, alternates must not contain paths referencing /home/ftp.
-hpa
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:45:28
Ingo Molnar wrote:
Soapbox: in fact it would be outright stupid to limit the kernel
source's availability artificially by not making HTTP a tier-one access
method.
Fighting against HTTP-only firewalls is like constantly pointing it out
to the popular press that they should say 'cracker' instead of 'hacker'.
It is pointless and only hurts the availability our own project.
Yes, and Shawn Pierce is working on making HTTP a proper "smart" access
method, based on a proposal I submitted. That is the proper solution,
since it avoids all the braindamage of "dumb" access methods. We
[kernel.org] intend to deploy it as soon as it is available.
-hpa
From: Wang Chen <hidden> Date: 2016-06-15 22:45:28
Ingo Molnar said the following on 2008-10-13 0:59:
* Petr Baudis [off-list ref] wrote:
quoted
On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
quoted
hm, -tip's .git/hooks/post-update already contained this, for the last 2
months:
exec git update-server-info
so ... _despite_ us having this in the git repo, the HTTP protocol still
does not work. Why?
I think your problem is that HTTP does not know where to look for
objects coming from alternates; IIRC this would work if you used
relative paths in objects/info/alternates, or you can create
objects/info/http-alternates like
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
ok, i've now set it up like this:
$ pwd
/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
$ cat objects/info/alternates
/home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
$ cat objects/info/http-alternates
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
and i've added "git update-server-info" to hooks/post-receive and made
it chmod +x.
that should be golden, right? I'm wondering why this isnt in the default
setup - i've been behind a limited corporate firewall in a former life
and having HTTP access is indeed very handy and pragmatic. Often hotel
WLANs are HTTP only as well.
Soapbox: in fact it would be outright stupid to limit the kernel
source's availability artificially by not making HTTP a tier-one access
method.
Fighting against HTTP-only firewalls is like constantly pointing it out
to the popular press that they should say 'cracker' instead of 'hacker'.
It is pointless and only hurts the availability our own project.
Yes. My clone is successful. Thanks, Peter.
But, after cloning, git-pull failed because of conflict.
I think maybe because Ingo rebased his tree?
---
Auto-merged init/main.c
CONFLICT (content): Merge conflict in init/main.c
Auto-merged scripts/bootgraph.pl
CONFLICT (add/add): Merge conflict in scripts/bootgraph.pl
Removed sound/soc/at91/eti_b1_wm8731.c
Automatic merge failed; fix conflicts and then commit the result.
---
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:45:29
Wang Chen wrote:
Yes. My clone is successful. Thanks, Peter.
But, after cloning, git-pull failed because of conflict.
I think maybe because Ingo rebased his tree?
---
Auto-merged init/main.c
CONFLICT (content): Merge conflict in init/main.c
Auto-merged scripts/bootgraph.pl
CONFLICT (add/add): Merge conflict in scripts/bootgraph.pl
Removed sound/soc/at91/eti_b1_wm8731.c
Automatic merge failed; fix conflicts and then commit the result.
---
Yes, the master branch on tip is not rebase-free.
-hpa