* Re: Cannot clone redirecting stdout
From: Jeff King @ 2009-09-11 16:05 UTC (permalink / raw)
To: Johan Sørensen; +Cc: Aloisio, git, support
In-Reply-To: <9e0f31700909110846h54959ae6u466ceda40799ba37@mail.gmail.com>
On Fri, Sep 11, 2009 at 05:46:23PM +0200, Johan Sørensen wrote:
> Some quick tests seem to indicate it's related to the fact that our
> wonderful little fork+exec git-daemon[1] (which is different from the
> one distributed with git) exec's to "git-upload-pack --strict
> --timeout=30 /path/to/repo". Now, why exactly that'll trigger when the
> no-progress flag is given I'm not sure of. The daemon itself execs as
> soon as it figures out what repo the client requested, so apart from
> the timeout the only thing it reacts to is the header (the
> "${headersize}git-upload-pack project/repo.git\0host=gitorious.org\0"
> part).
>
> We also do redirect stderr to /dev/null for reasons I cannot remember
> (so probably not good ones), that may be related as well. Well run
> some more tests...
Ah. I have a theory. If I do a clone of git://gitorious.org/qt/qt.git,
the counting/compressing stages take a long time (I timed it at 1m40
before it actually sends any data). And looking at upload-pack.c, we
leave the 30-second alarm set while creating the pack. Meaning we die 30
seconds into creating the pack.
When progress is being displayed, however, the progress timer actually
uses SIGALRM, as well. So we are constantly resetting the timer and it
never goes off.
And we should be able to test this theory. How long does it take for the
failure case to fail:
$ time git clone -n git://gitorious.org/qt/qt.git repo >log
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
real 0m31.106s
user 0m0.000s
sys 0m0.012s
Hmm. Suspicious. :)
So that implies to me a few things:
1. You guys should really pack your repos, as you are wasting over a
minute of CPU time every time somebody clones this repo.
2. Upload-pack has what I consider a bug. The --timeout should be
suspended while we are actually crunching numbers to create the
pack. We probably don't want it when sending the pack, either, as
people with slow connections (or big repos) will get timed out
during the send. Probably we just want to apply it to times when we
are waiting to get the list of refs from the client.
3. Upload-pack and the progress code are both using the global alarm
timer and signal, and that is papering over the bug in (2) when
progress is enabled. I'm not sure of the simplest way of having
those interact. But maybe we can just ignore it, because we
probably don't want to using the --timeout alarm during the packing
phase, anyway.
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] reset: add option "--merge-dirty" to "git reset"
From: Linus Torvalds @ 2009-09-11 16:02 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski
In-Reply-To: <200909110729.32581.chriscool@tuxfamily.org>
On Fri, 11 Sep 2009, Christian Couder wrote:
>
> No, I realize it was my writing skills that were lacking again. I will
> rework the commit message using some tables like in Daniel's message.
Ok, thanks.
> > The patch also seems to imply that it's always about HEAD. True?
>
> Yes.
It might be worth noting/explaining very explicitly. "git reset" uin
general does not ever try to make HEAD special - except as a _default_
location, of course, and as the thing that is actually modified.
I realize _why_ (HEAD is kind of the "base" for the index state), but I
think it's worth a comment or something. I did a double-take when I saw
that part of the diff exactly because it's unusual.
Linus
^ permalink raw reply
* Re: Cannot clone redirecting stdout
From: Johan Sørensen @ 2009-09-11 15:46 UTC (permalink / raw)
To: Jeff King; +Cc: Aloisio, git, support
In-Reply-To: <20090911135110.GA30860@coredump.intra.peff.net>
On Fri, Sep 11, 2009 at 3:51 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Sep 11, 2009 at 06:23:29AM -0400, Jeff King wrote:
>
>> > I faced a problem when trying to clone git://gitorious.org/qt/qt.git
>> >
>> > this works:
>> > git clone -n git://gitorious.org/qt/qt.git repo
>> >
>> > this doesn't:
>> > git clone -n git://gitorious.org/qt/qt.git repo >log
>> > fatal: The remote end hung up unexpectedly
>> > fatal: early EOF
>> > fatal: index-pack failed
>>
>> I can reproduce the problem here. But after staring at the strace for a
>> long time, I don't think the problem is on the client side. The remote
>> end _does_ hang up unexpectedly.
>>
>> Looking at what we send, the only difference between the redirected and
>> unredirected case I could find is that we send the "no-progress" flag to
>> the server, which then hangs up on us instead of sending us the pack.
>> Which makes no sense.
>
> I did a little more testing, and I can't reproduce the problem against a
> local git-daemon. I tried using several versions for the server, going
> all the way back to v1.5.0, which pre-dates no-progress, and all of them
> worked just fine.
>
> So I am inclined to think there is something non-standard or broken at
> gitorious.org. I'm cc'ing support@gitorious to see if they have any
> comment.
Some quick tests seem to indicate it's related to the fact that our
wonderful little fork+exec git-daemon[1] (which is different from the
one distributed with git) exec's to "git-upload-pack --strict
--timeout=30 /path/to/repo". Now, why exactly that'll trigger when the
no-progress flag is given I'm not sure of. The daemon itself execs as
soon as it figures out what repo the client requested, so apart from
the timeout the only thing it reacts to is the header (the
"${headersize}git-upload-pack project/repo.git\0host=gitorious.org\0"
part).
We also do redirect stderr to /dev/null for reasons I cannot remember
(so probably not good ones), that may be related as well. Well run
some more tests...
[1]: http://gitorious.org/gitorious/mainline/blobs/master/script/git-daemon
>
> -Peff
> --
> 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/PATCH 2/2] gitweb: check given hash before trying to create snapshot
From: Mark Rada @ 2009-09-11 15:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Mark Rada, git, Junio C Hamano
In-Reply-To: <200909110952.50536.jnareb@gmail.com>
On 2009-09-11, at 3:52 AM, Jakub Narebski wrote:
> Second, I'd rather have better names for snapshots than using full
> SHA-1.
> For snapshot of 'v1.5.0' of repository 'repo.git' I'd prefer for
> snapshot
> to be named 'repo-v1.5.0', and for snapshot of 'next' branch of the
> same
> project to be named for example 'repo-next-20090909', or perhaps
> 'repo-next-2009-09-10T09:16:18' or 'repo-next-20090909-g5f6b0ff',
> or 'repo-v1.6.5-rc0-164-g5f6b0ff'.
Ah, yeah, well, I let $hash still hold the originally passed value,
which
would be used to create the outputted file name (unless overwritten by
the
client by using curl -o or something). Then $snapshot holds the full
hash.
This way, if you were to type something like
http://git.kernel.org/?p=git/git.git;a=snapshot;h=next;sf=tgz
into your browser window, you would get git.git-next.tar.gz back, but
the
backend could look up something like
git-5f6b0ffff13f5cd762d0a5a4e1c4dede58e8a537.tar.gz
using the $snapshot variable in some hypothetical cache (or even
without the
cache it won't mangle the nicer name $hash might have).
Also, right now gitweb will not accept tags for hashes. This seems to be
because it passes the --verify option to rev-parse, but the output
from using
and not using the verify option seems to be the same (other than also
accepting
all tree-ishes). Could you let me know if there is a good reason not
to take
off the --verify option? Otherwise, I would like to take it off in the
next
version of this patch.
Your point about adding the short hash to snapshots of branch heads is
cool,
I'll try that for the next version of the patch.
>> }
>>
>> my $name = $project;
>> diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-
>> gitweb-standalone-http-status.sh
>> index d0ff21d..4f8f147 100644
>> --- a/t/t9501-gitweb-standalone-http-status.sh
>> +++ b/t/t9501-gitweb-standalone-http-status.sh
>> @@ -75,4 +75,30 @@ test_expect_success \
>> test_debug 'cat gitweb.output'
>>
>>
>> +test_expect_success \
>> + 'snapshots: bad treeish id' \
>> + 'gitweb_run "p=.git;a=snapshot;h=frizzumFrazzum;sf=tgz" &&
>> + grep "400 - Not a valid hash id:" gitweb.output'
>> +test_debug 'cat gitweb.output'
>> +
>> +test_expect_success \
>> + 'snapshots: good treeish id' \
>> + 'gitweb_run "p=.git;a=snapshot;h=master;sf=tgz" &&
>> + grep "Status: 200 OK" gitweb.output'
>> +test_debug 'cat gitweb.output'
>
> Why you don't check for "Status: 400" too?
I'm not sure which test you are referring to (I think the second). The
second test is valid and should return a nice .git-master.tar.gz
tarball.
>> Second, any given treeish will always be translated to the full
>> length,
>> unambiguous, hash id; this will be useful for things like creating
>> unique names for snapshot caches.
>
> But this is not a good idea, IMHO.
>
> First, it introduces feature that nobody uses (at least yet); we can
> introduce this feature when it is needed instead.
Sorry for promoting vapourware, I did originally rip this patch out from
something else. I removed the comment from the v2 commit message.
--
Mark Rada (ferrous26)
marada@uwaterloo.ca
^ permalink raw reply
* Re: bash_completion outside repo
From: Jeff King @ 2009-09-11 15:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: james bardin, Todd Zullinger, git
In-Reply-To: <20090911143651.GE1033@spearce.org>
On Fri, Sep 11, 2009 at 07:36:51AM -0700, Shawn O. Pearce wrote:
> > instead of just using "git config --get-regexp 'remote\..*\.url'", which
> > would be slightly more efficient, and also doesn't have this bug. ;)
>
> F'king oversight. You are right, this should be --get-regexp.
> There isn't a reason here, probably other than "I forgot about
> --get-regexp when I wrote the original code".
OK. I will leave a bash-completion patch for you (or somebody else
interested) as I don't use it myself.
Assuming you make such a patch, that will clear up the original issue. I
wonder if we should fix "git config --list". The current semantics seem
a little crazy to me, but it is a scriptable interface. I'm inclined to
call this a bug, though.
-Peff
^ permalink raw reply
* Re: [ JGIT ] incompatiblity found in DirCache
From: Shawn O. Pearce @ 2009-09-11 15:05 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Adam W. Hawks, git
In-Reply-To: <200909092311.07145.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> onsdag 09 september 2009 20:55:39 skrev "Adam W. Hawks" <awhawks@writeme.com>:
> > When using the DirCache interface to the index you can create a
> > invalid/corrupt tree for git 1.6.5.
> >
> > The problem seems to be you can add a path to the index that starts
> > with a "/" and DirCache creates a entry with a mode but no path.
> > This causes git 1.6.5 to fail with a corrupt tree.
>
> I think there are more ways of entering bad stuff. Preventing a
> deliberate programmatic creation of invalid trees is probably not
> the most important thing, but then again, validating the data to
> prevent e.g. the EGit plugin from doing it by mistake due to bugs
> could probably be worthwhile.
We already check for and fail fast on a 0 mode in DirCache, as this
mode is also not valid in the index, or in a git tree.
We should be doing the same thing for an empty path name. "a//b" is
not a valid path in the index, as "" is not a valid tree entry path.
For the same reason, "/a" is not a valid path in the index.
Unfortunately our API also allows you to try and create a name of
"a\u0000b", which is a valid Java string, but will create a corrupt
tree. \u0000 in a name with more than 4095 bytes will also create
a corrupt index (shorter strings are semi-valid because shorter
strings use a Pascal like string format, and longer ones use a C
like string format). Though C git is unable to access a path whose
name contains "\u0000", no matter how long the string is.
I think we should try a bit harder in DirCache to prevent these sorts
of really bad entries from being constructed by application code.
Yes, applications should not do this, but I think the library also
should not write known bogus trash to the disk and claim it is OK.
I'll try to work up a patch for this today.
--
Shawn.
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Linus Torvalds @ 2009-09-11 14:47 UTC (permalink / raw)
To: René Scharfe; +Cc: Jakub Narebski, Brendan Miller, git
In-Reply-To: <4AA97B61.6030301@lsrfire.ath.cx>
On Fri, 11 Sep 2009, René Scharfe wrote:
>
> Using zlib directly avoids the overhead of a pipe and of buffering the
> output for blocked writes; surprisingly (to me), it isn't any faster.
In fact, it should be slower.
On SMP, you're quite likely better off using the pipe, and compressing on
another CPU. Of course, it's usually the case that the compression is _so_
much slower than generating the tar-file (especially for the hot-cache
case) that it doesn't matter or the pipe overhead is even a slowdown.
But especially if generating the tar-file has some delays in it
(cold-cache object lookup, whatever), the "compress in separate process"
is likely simply better, because you can compress while the other process
is looking up data for the tar.
Linus
^ permalink raw reply
* Re: bash_completion outside repo
From: Shawn O. Pearce @ 2009-09-11 14:36 UTC (permalink / raw)
To: Jeff King; +Cc: james bardin, Todd Zullinger, git
In-Reply-To: <20090911141730.GA384@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> I also question why it is using "git config --list" at all in snippets
> like this:
>
> for i in $(git --git-dir="$d" config --list); do
> case "$i" in
> remote.*.url=*)
> i="${i#remote.}"
> echo "${i/.url=*/}"
> ;;
> esac
> done
>
> instead of just using "git config --get-regexp 'remote\..*\.url'", which
> would be slightly more efficient, and also doesn't have this bug. ;)
F'king oversight. You are right, this should be --get-regexp.
There isn't a reason here, probably other than "I forgot about
--get-regexp when I wrote the original code".
--
Shawn.
^ permalink raw reply
* Re: bash_completion outside repo
From: Jeff King @ 2009-09-11 14:17 UTC (permalink / raw)
To: james bardin; +Cc: Todd Zullinger, git
In-Reply-To: <a3b675320909110700k7eb7286qc8cb5691aae214c7@mail.gmail.com>
On Fri, Sep 11, 2009 at 10:00:33AM -0400, james bardin wrote:
> I did a make install, and dropped the completion file in
> /etc/bash_completion.d/. No other settings changed. I did a quick
> check, and it happens with the current 1.6.5 snapshot too, and on a
> fedora 10 box I found.
>
> It seems I only get this error if I don't have a global config.
> Touching ~/.gitconfig stops the error.
Ah, I see. It looks like we use "git config --list" to view several bits
of configuration. However, it is not happy if there is no config file to
list.
However, I'm not sure that "config --list" isn't broken. Inside a repo,
doing "git config --list" shows the repo config and my global config,
and exits with no error. Outside a repo, it shows my global config, and
exits with no error. But if I _don't_ have global config, it produces an
error. Shouldn't it treat that as simply "no config is available"?
I also question why it is using "git config --list" at all in snippets
like this:
for i in $(git --git-dir="$d" config --list); do
case "$i" in
remote.*.url=*)
i="${i#remote.}"
echo "${i/.url=*/}"
;;
esac
done
instead of just using "git config --get-regexp 'remote\..*\.url'", which
would be slightly more efficient, and also doesn't have this bug. ;)
-Peff
^ permalink raw reply
* Re: bash_completion outside repo
From: james bardin @ 2009-09-11 14:00 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git
In-Reply-To: <20090911133313.GF2582@inocybe.localdomain>
On Fri, Sep 11, 2009 at 9:33 AM, Todd Zullinger <tmz@pobox.com> wrote:
> james bardin wrote:
>> I'm making a git rpm for our site, and I'm getting an error with
>> bash_completion on RHEL/CentOS 5.
>
> Out of curiosity, have you tried rebuilding the Fedora packages from
> rawhide? They should work on RHEL/CentOS 5 just fine (I use them
> myself).
>
I was trying to prune out some of the dependencies to make internal
deployment easier.
I bundled the doc tarballs instead of requiring asciidoc, and git
includes its own perl(Error) if it's not available.
On Fri, Sep 11, 2009 at 9:11 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> I can't reproduce this with git version 1.6.5.rc0.164.g5f6b0 on Fedora 11.
>
> Which exact steps reproduce it for you, and which relevant settings (PS1
> and GIT_PS1_...) do you use? Do you have a system or global .gitconfig?
>
I did a make install, and dropped the completion file in
/etc/bash_completion.d/. No other settings changed. I did a quick
check, and it happens with the current 1.6.5 snapshot too, and on a
fedora 10 box I found.
It seems I only get this error if I don't have a global config.
Touching ~/.gitconfig stops the error.
^ permalink raw reply
* Re: Cannot clone redirecting stdout
From: Jeff King @ 2009-09-11 13:51 UTC (permalink / raw)
To: Aloisio; +Cc: git, support
In-Reply-To: <20090911102329.GA13044@sigill.intra.peff.net>
On Fri, Sep 11, 2009 at 06:23:29AM -0400, Jeff King wrote:
> > I faced a problem when trying to clone git://gitorious.org/qt/qt.git
> >
> > this works:
> > git clone -n git://gitorious.org/qt/qt.git repo
> >
> > this doesn't:
> > git clone -n git://gitorious.org/qt/qt.git repo >log
> > fatal: The remote end hung up unexpectedly
> > fatal: early EOF
> > fatal: index-pack failed
>
> I can reproduce the problem here. But after staring at the strace for a
> long time, I don't think the problem is on the client side. The remote
> end _does_ hang up unexpectedly.
>
> Looking at what we send, the only difference between the redirected and
> unredirected case I could find is that we send the "no-progress" flag to
> the server, which then hangs up on us instead of sending us the pack.
> Which makes no sense.
I did a little more testing, and I can't reproduce the problem against a
local git-daemon. I tried using several versions for the server, going
all the way back to v1.5.0, which pre-dates no-progress, and all of them
worked just fine.
So I am inclined to think there is something non-standard or broken at
gitorious.org. I'm cc'ing support@gitorious to see if they have any
comment.
-Peff
^ permalink raw reply
* [PATCH v2] Re: add documentation for mailinfo.scissors and '--no-scissors'
From: Nicolas Sebrecht @ 2009-09-11 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Sebrecht, Nanako Shiraishi, git
In-Reply-To: <7veiqe0x05.fsf@alter.siamese.dyndns.org>
[ Thank you for this review. ]
The 11/09/09, Junio C Hamano wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>
> > diff --git a/git-am.sh b/git-am.sh
> > index 26ffe70..f242d1a 100755
> > --- a/git-am.sh
> > +++ b/git-am.sh
> > @@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
> > u,utf8 recode into utf8 (default)
> > k,keep pass -k flag to git-mailinfo
> > c,scissors strip everything before a scissors line
> > +no-scissors don't obey to a scissors line (default)
> > whitespace= pass it through git-apply
> > ignore-space-change pass it through git-apply
> > ignore-whitespace pass it through git-apply
>
> Do we want it to allow --no-no-scissors? I do not think this hunk is
> necessary at all.
I don't understand your point here. This hunk doesn't allow
--no-no-scissors but add --no-scissors to usage of 'git am', no?
Do I miss something around $OPTIONS_SPEC?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: bash_completion outside repo
From: Todd Zullinger @ 2009-09-11 13:33 UTC (permalink / raw)
To: james bardin; +Cc: git
In-Reply-To: <a3b675320909100813i3e70ab3at66408aebb9952c7d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
james bardin wrote:
> I'm making a git rpm for our site, and I'm getting an error with
> bash_completion on RHEL/CentOS 5.
Out of curiosity, have you tried rebuilding the Fedora packages from
rawhide? They should work on RHEL/CentOS 5 just fine (I use them
myself).
> When outside a repo, any completion causes git to spit out
> fatal: error processing config file(s)
>
> This is 1.6.4.2 using the contrib bash completion file
I can't reproduce this on either Fedora or CentOS.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A great many people think they are thinking when they are merely
rearranging their prejudices.
-- William James
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: bash_completion outside repo
From: Michael J Gruber @ 2009-09-11 13:11 UTC (permalink / raw)
To: james bardin; +Cc: git
In-Reply-To: <a3b675320909100813i3e70ab3at66408aebb9952c7d@mail.gmail.com>
james bardin venit, vidit, dixit 10.09.2009 17:13:
> Hi,
>
> I'm making a git rpm for our site, and I'm getting an error with
> bash_completion on RHEL/CentOS 5.
>
> When outside a repo, any completion causes git to spit out
> fatal: error processing config file(s)
>
> This is 1.6.4.2 using the contrib bash completion file
>
> Thanks
> -jim
I can't reproduce this with git version 1.6.5.rc0.164.g5f6b0 on Fedora 11.
Which exact steps reproduce it for you, and which relevant settings (PS1
and GIT_PS1_...) do you use? Do you have a system or global .gitconfig?
Michael
^ permalink raw reply
* previously committed file untracked prevent checking out an old tag/branch
From: Daniele Segato @ 2009-09-11 11:26 UTC (permalink / raw)
To: git
Hi,
I had this situation:
we used to have a properties file in our project that was used by ant
to build it.
That file was tracked since the beginning of the project (several months ago).
let's call it:
build.properties
(the project is on SVN and I'm the only one to use git)
Since everyone in the project has different directories paths I
decided to untrack the file
create a new template file and track it instead:
so I did something like this:
cp build.properties build.properties.template
vim build.properties.template
echo build.properties >> .git/info/exclude
git rm --cached build.properties
git add build.properties.template
git commit -m "finally we don't overwrite it each other anymore"
Now I had to switch back to a tag that still have that file
(build.properties) tracked to fix some
issue there but when I try I get:
error: Untracked working tree file 'build.properties' would be
overwritten by merge.
How would you handle a situation like this?
I only can think of doing a backup of my build.properties, delete it
and check out the tag or I just delete it and rebuild
it from the template later.
I did it but that made me think on it.
Actually what I really wanted here was the possibility to "locally
track" that file...
something like
git local <file>
that will have that file indexed by git so I can switch to branch that
have that file without loosing it when I go back.
furthermore that would allow me to keep versions of my local file even
if I don't want to commit it.
I could see if I accidentally modified it.
This could be useful, in my opinion.
Is there on git a feature to do something like that?
Do you think it could be useful or do you see any possible problem about that?
Regards,
Daniele
^ permalink raw reply
* Re: git push stages original version on server
From: Mikael Magnusson @ 2009-09-11 11:11 UTC (permalink / raw)
To: Roald de Vries; +Cc: git
In-Reply-To: <D7E5118C-AE88-4C4B-8D8A-5AF16ECF731D@roalddevries.nl>
2009/9/11 Roald de Vries <rdv@roalddevries.nl>:
> Hi all,
>
> There's a thing I don't understand: I have a repository on a server from/to
> which I pull/push. But when I push to it, and do a checkout on the server,
> the pushed changes are not visible. It appears that the changed file is
> added to the index on the server automatically. Why is this? It seems
> dangerous. If I do a commit on the server, the changes from the client will
> be lost.
>
> There's also a thing I'm not sure exists: I use a git server/client setup
> for developing a website. I would like git-pushes to appear immediately
> online (without having to ssh to the server and checking out manually). Is
> this possible?
>
> My questions are:
> - Why does git work like this?
> - Can I change its behaviour (if I still want that after the answer to the
> previous question)?
> - How can I have git automatically checkout pushed changes on the server?
>
> Thanks in advance.
>
> Kind regards,
>
> Roald
http://git.or.cz/gitwiki/GitFaq#Whywon.27tIseechangesintheremoterepoafter.22gitpush.22.3F
--
Mikael Magnusson
^ permalink raw reply
* Re: git push stages original version on server
From: Paolo Bonzini @ 2009-09-11 11:09 UTC (permalink / raw)
To: Roald de Vries; +Cc: git
In-Reply-To: <D7E5118C-AE88-4C4B-8D8A-5AF16ECF731D@roalddevries.nl>
Pushing to a non-bare repository is discouraged.
> - How can I have git automatically checkout pushed changes on the server?
I think you could in principle add a hook that does the "git checkout"
or "git reset --hard $(git symbolic-ref HEAD)", but I suggest pushing to
a bare repository and have the hook trigger a "git pull" elsewhere.
Paolo
^ permalink raw reply
* git push stages original version on server
From: Roald de Vries @ 2009-09-11 10:40 UTC (permalink / raw)
To: git
Hi all,
There's a thing I don't understand: I have a repository on a server
from/to which I pull/push. But when I push to it, and do a checkout on
the server, the pushed changes are not visible. It appears that the
changed file is added to the index on the server automatically. Why is
this? It seems dangerous. If I do a commit on the server, the changes
from the client will be lost.
There's also a thing I'm not sure exists: I use a git server/client
setup for developing a website. I would like git-pushes to appear
immediately online (without having to ssh to the server and checking
out manually). Is this possible?
My questions are:
- Why does git work like this?
- Can I change its behaviour (if I still want that after the answer to
the previous question)?
- How can I have git automatically checkout pushed changes on the
server?
Thanks in advance.
Kind regards,
Roald
^ permalink raw reply
* Re: Cannot clone redirecting stdout
From: Jeff King @ 2009-09-11 10:23 UTC (permalink / raw)
To: Aloisio; +Cc: git
In-Reply-To: <fc8ab2ad0909101533l135c8003m80091cb40ec93f16@mail.gmail.com>
On Thu, Sep 10, 2009 at 07:33:21PM -0300, Aloisio wrote:
> I faced a problem when trying to clone git://gitorious.org/qt/qt.git
>
> this works:
> git clone -n git://gitorious.org/qt/qt.git repo
>
> this doesn't:
> git clone -n git://gitorious.org/qt/qt.git repo >log
> fatal: The remote end hung up unexpectedly
> fatal: early EOF
> fatal: index-pack failed
I can reproduce the problem here. But after staring at the strace for a
long time, I don't think the problem is on the client side. The remote
end _does_ hang up unexpectedly.
Looking at what we send, the only difference between the redirected and
unredirected case I could find is that we send the "no-progress" flag to
the server, which then hangs up on us instead of sending us the pack.
Which makes no sense.
Confused,
-Peff
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Junio C Hamano @ 2009-09-11 8:54 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, msysgit, Tom Preston-Werner, Jakub Narebski
In-Reply-To: <20090909203350.e3d7e5dc.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
>> I am in favour or removing this check, not just due to its
>> unreliability, but for the sake of consistency (we very rarely send a
>> HEAD request to poll data before doing a GET).
I think this is sensible. The only case I think it could be a problem is
this scenario:
- You clone from remote.
- Remote works more and has two more packs, A and B.
- You fetch, but this does not need both of them (perhaps you fetched
only one branch). You get *.idx files for both, but *.pack file only
for A.
- Remote works a bit more and then repacks everything into a single pack
C.
- You fetch, and the walker walks the loose objects, and then finds one
object that cannot be obtained as a loose object. It tries to look up
in the *.idx file and finds it in B.
But the packfile B is long gone.
I didn't follow the codepath that uses http_get_info_packs() and then uses
repo->packs list to see what it does, but as long as the above does not
happen we should be Ok.
Thanks.
^ permalink raw reply
* Re: Cannot clone redirecting stdout
From: Jean-Luc Herren @ 2009-09-11 8:15 UTC (permalink / raw)
To: Aloisio, git
In-Reply-To: <fc8ab2ad0909101533l135c8003m80091cb40ec93f16@mail.gmail.com>
Hi list!
Aloisio wrote:
> this doesn't:
> git clone -n git://gitorious.org/qt/qt.git repo >log
> fatal: The remote end hung up unexpectedly
> fatal: early EOF
> fatal: index-pack failed
What are you trying to store in that file? The only line I
observe being printed to stdout while cloning is this one:
Initialized empty Git repository in [...]/repo/.git/
Everything else (progress status) is printed to stderr and I
presume that any error messages would also go to stderr too, if
any. So possibly you would be happy with this:
git clone -n git://gitorious.org/qt/qt.git repo 2> log
which works fine here with git-1.6.4.2. Though I agree that I
would expect redirecting stdout to work.
Cheers,
jlh
^ permalink raw reply
* Re: [RFC/PATCH 2/2] gitweb: check given hash before trying to create snapshot
From: Jakub Narebski @ 2009-09-11 7:52 UTC (permalink / raw)
To: Mark Rada; +Cc: git, Junio C Hamano
In-Reply-To: <4AA96DAF.4070200@mailservices.uwaterloo.ca>
On Thu, 10 Sep 2009, Mark Rada wrote:
> This patch is dual purposed.
>
> First, it makes things nicer in cases when you hand craft the snapshot
> URL but make a typo (e.g. netx instead of next); you will now get an
> error message instead of a broken tarball.
This is a very good idea.
>
> Second, any given treeish will always be translated to the full length,
> unambiguous, hash id; this will be useful for things like creating
> unique names for snapshot caches.
But this is not a good idea, IMHO.
First, it introduces feature that nobody uses (at least yet); we can
introduce this feature when it is needed instead.
Second, I'd rather have better names for snapshots than using full SHA-1.
For snapshot of 'v1.5.0' of repository 'repo.git' I'd prefer for snapshot
to be named 'repo-v1.5.0', and for snapshot of 'next' branch of the same
project to be named for example 'repo-next-20090909', or perhaps
'repo-next-2009-09-10T09:16:18' or 'repo-next-20090909-g5f6b0ff',
or 'repo-v1.6.5-rc0-164-g5f6b0ff'.
I'm not sure what would be the best name of snapshot of given
subdirectory...
In short: I'd rather not improve on bad design of using full SHA-1
in snapshot name.
>
> This patch includes test for t9501 to demonstrate the changed
> functionality.
>
> Signed-off-by: Mark Rada <marada@uwaterloo.ca>
> ---
> gitweb/gitweb.perl | 5 +++--
> t/t9501-gitweb-standalone-http-status.sh | 26 ++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index d650188..4ae960c 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -5197,8 +5197,9 @@ sub git_snapshot {
> die_error(403, "Unsupported snapshot format");
> }
>
> - if (!defined $hash) {
> - $hash = &git_get_hash($project);
> + my $snapshot = &git_get_hash($project, $hash);
Same comment as for PATCH 1/2: don't use '&' subroutine call if it
is not required.
> + if (!$snapshot) {
> + die_error(400, "Not a valid hash id: $hash");
Note that we don't use user input in _any_ of other error messages;
you would probably need to sanitize $hash.
By the way, wouldn't 404 (Not Found) be a better error code?
> }
>
> my $name = $project;
> diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-gitweb-standalone-http-status.sh
> index d0ff21d..4f8f147 100644
> --- a/t/t9501-gitweb-standalone-http-status.sh
> +++ b/t/t9501-gitweb-standalone-http-status.sh
> @@ -75,4 +75,30 @@ test_expect_success \
> test_debug 'cat gitweb.output'
>
>
> +test_expect_success \
> + 'snapshots: bad treeish id' \
> + 'gitweb_run "p=.git;a=snapshot;h=frizzumFrazzum;sf=tgz" &&
> + grep "400 - Not a valid hash id:" gitweb.output'
> +test_debug 'cat gitweb.output'
> +
> +test_expect_success \
> + 'snapshots: good treeish id' \
> + 'gitweb_run "p=.git;a=snapshot;h=master;sf=tgz" &&
> + grep "Status: 200 OK" gitweb.output'
> +test_debug 'cat gitweb.output'
Why you don't check for "Status: 400" too?
> +
> +test_expect_success \
> + 'snapshots: good object id' \
> + 'ID=`git rev-parse --verify HEAD` &&
> + gitweb_run "p=.git;a=snapshot;h=$ID;sf=tgz" &&
> + grep "Status: 200 OK" gitweb.output'
> +test_debug 'cat gitweb.output'
> +
> +test_expect_success \
> + 'snapshots: bad object id' \
> + 'gitweb_run "p=.git;a=snapshot;h=abcdef01234;sf=tgz" &&
> + grep "400 - Not a valid hash id:" gitweb.output'
> +test_debug 'cat gitweb.output'
> +
> +
> test_done
> --
> 1.6.4.2
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Cannot clone redirecting stdout
From: Stefan Naewe @ 2009-09-11 7:27 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4AA9F0A2.6050105@atlas-elektronik.com>
On 9/11/2009 8:39 AM, Stefan Naewe wrote:
> On 9/11/2009 12:33 AM, Aloisio wrote:
>> Hi all,
>>
>> I faced a problem when trying to clone git://gitorious.org/qt/qt.git
>>
>> this works:
>> git clone -n git://gitorious.org/qt/qt.git repo
>>
>> this doesn't:
>> git clone -n git://gitorious.org/qt/qt.git repo >log
>> fatal: The remote end hung up unexpectedly
>> fatal: early EOF
>> fatal: index-pack failed
>>
>> I reproduced the error in the following versions:
>> git version 1.6.0.4
>> git version 1.6.4.2
>> git version 1.5.4.7
>>
>> Any clues?
>> Thanks
>
> I'd say:
>
> Take a look at /proc/<pid-of-git>/fd
>
> fd 0 (stdout) is linked through a pipe to 'git index-pack'.
> Redirecting this link breaks everything.
stdout is of course fd 1 ;-)
Regards,
Stefan
--
/dev/random says: Never trust a computer you can't lift. - Stan Masor
^ permalink raw reply
* Re: [PATCH v2] add documentation for mailinfo.scissors and '--no-scissors'
From: Junio C Hamano @ 2009-09-11 7:19 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <f63e8402656c02fc2ecdcce8a37cc1d60a61aa1d.1252628643.git.nicolas.s.dev@gmx.fr>
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> +---no-scissors::
> + Do not obey to a scissors line (see linkgit:git-mailinfo[1]).
> +
obey is v.t. so "do not obey a scissors line" would be grammatical; I
think "ignore scissors lines" would be better.
> +--no-scissors::
> + Do not obey to a scissors line. This is only useful if mailinfo.scissors is
> + enabled (see --scissors).
Ditto; also it is useful in general if you do not know which way it is
configured. Saying "_only_" is misleading.
Ignore scissors lines; useful for overriding mailinfo.scissors
settings.
> diff --git a/git-am.sh b/git-am.sh
> index 26ffe70..f242d1a 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
> u,utf8 recode into utf8 (default)
> k,keep pass -k flag to git-mailinfo
> c,scissors strip everything before a scissors line
> +no-scissors don't obey to a scissors line (default)
> whitespace= pass it through git-apply
> ignore-space-change pass it through git-apply
> ignore-whitespace pass it through git-apply
Do we want it to allow --no-no-scissors? I do not think this hunk is
necessary at all.
^ permalink raw reply
* Re: Cannot clone redirecting stdout
From: Stefan Naewe @ 2009-09-11 6:39 UTC (permalink / raw)
To: Aloisio; +Cc: git@vger.kernel.org
In-Reply-To: <fc8ab2ad0909101533l135c8003m80091cb40ec93f16@mail.gmail.com>
On 9/11/2009 12:33 AM, Aloisio wrote:
> Hi all,
>
> I faced a problem when trying to clone git://gitorious.org/qt/qt.git
>
> this works:
> git clone -n git://gitorious.org/qt/qt.git repo
>
> this doesn't:
> git clone -n git://gitorious.org/qt/qt.git repo >log
> fatal: The remote end hung up unexpectedly
> fatal: early EOF
> fatal: index-pack failed
>
> I reproduced the error in the following versions:
> git version 1.6.0.4
> git version 1.6.4.2
> git version 1.5.4.7
>
> Any clues?
> Thanks
I'd say:
Take a look at /proc/<pid-of-git>/fd
fd 0 (stdout) is linked through a pipe to 'git index-pack'.
Redirecting this link breaks everything.
Regards,
Stefan
^ 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