* Re: problem cloning via http since v1.6.6-rc0
From: Tay Ray Chuan @ 2010-01-21 1:34 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git
In-Reply-To: <20100121004756.GA18213@onerussian.com>
Hi,
On Thu, Jan 21, 2010 at 8:47 AM, Yaroslav Halchenko
<debian@onerussian.com> wrote:
> Cloning of the repository works fine with v1.6.5.7 but fails with v1.6.6-rc0.
this sounds like around the time the smart http protocol was introduced.
> fatal: http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?
>
> on the server, 1.6.3.3 version of git was used to run git
> update-server-info.
hmm, are you using the WebDAV-flavour or the smart http protocol to
host the repository?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Tay Ray Chuan @ 2010-01-21 1:36 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git
In-Reply-To: <20100121004756.GA18213@onerussian.com>
On Thu, Jan 21, 2010 at 8:47 AM, Yaroslav Halchenko
<debian@onerussian.com> wrote:
> $> GIT_TRACE=2 ./git clone http://git.debian.org/git/pkg-exppsy/pymvpa.git
> trace: built-in: git 'clone' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> warning: templates not found /home/yoh/share/git-core/templates
> Initialized empty Git repository in /home/yoh/proj/misc/git/pymvpa/.git/
> trace: run_command: 'remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> trace: exec: 'git' 'remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> trace: exec: 'git-remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> trace: run_command: 'git-remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> fatal: http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?
oh, and by the way, could you also run this again with GIT_CURL_VERBOSE=1?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Fix memory corruption when .gitignore does not end by \n
From: Nguyen Thai Ngoc Duy @ 2010-01-21 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Jonathan del Strother
In-Reply-To: <7v3a20367d.fsf@alter.siamese.dyndns.org>
On 1/21/10, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > This patch causes a crash for me. Not sure if it does for anybody else.
>
>
> I am puzzled. What do you mean by this? If this patch makes the code
> crash, then it is not a fix. Is this meant as "Jonathan, can you try this
> patch and tell me what happens, so that I can diagnose the issue better?"
> patch?
I mean the t3001 patch in comment part, which removes \n at the end of
.gitignore and crashes the unmodified git.
IOW I found a problem and this patch (not the t3001 one) should fix
it. Not sure if this causes Jonathan problem though.
> Is it better/safer to revert the entire nd/sparse topic from the master in
> the meantime before we know what is going on?
I would wait for Jonathan response. If this is not the cause, probably
safer to revert it.
--
Duy
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #06; Wed, 20)
From: Johan Herland @ 2010-01-21 1:40 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Junio C Hamano
In-Reply-To: <fabb9a1e1001201706i4c7ffaecs55153c9220bc5992@mail.gmail.com>
On Thursday 21 January 2010, Sverre Rabbelier wrote:
> On Thu, Jan 21, 2010 at 01:52, Junio C Hamano <gitster@pobox.com> wrote:
> > * jh/notes (2010-01-17) 23 commits
> > [...]
> > Updated with a re-roll.
>
> Just checking, you reverted all from next (with exception of the first
> three), and now re-queued it to pu, with the first three still in
> next? Or did I mis-remember and did only the first three make it to
> next in the first place?
You misremembered. Only the three first were merged to 'next'. Junio was
about to merge the rest, but I asked him to hold until I had produced the
current iteration.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git equivalent to clearcase wink-in
From: Johan Herland @ 2010-01-21 1:51 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Mike Hommey, Jamie Wellnitz, Richard Assal
In-Reply-To: <fabb9a1e1001201434n1036253ds1120c2abc0d3728e@mail.gmail.com>
On Wednesday 20 January 2010, Sverre Rabbelier wrote:
> On Wed, Jan 20, 2010 at 22:12, Mike Hommey <mh@glandium.org> wrote:
> > Surely the ccache directory could be shared on nfs or some other
> > network filesystem. Or object file could be checked in, which is imho
> > ugly, but should work (better to do that on a separate branch)
>
> Ha! It could even be stored as a note on the tree object? The whole
> notes business seems to be nearing a usable stage. Or maybe notes are
> text-only, mhhh. Johan?
In principle you could (ab)use the notes structure for this purpose. There
is nothing inherently text-only about notes. I would certainly suggest to
create a custom notes ref for this purpose, so that these object caches are
not mixed up with other notes (and are also not displayed by git log).
I'm also not sure the putting the note on the tree object is the right
granularity. You could imagine putting a .o-file as a note on the
corresponding .c-file _blob_, but that would only work if the .o-file
depended solely on the .c file (i.e. it would only work for preprocessed
source, or .c-files without any #includes), so that is probably not viable.
The problem with putting the object cache on the tree object, is that it
would only be useful for those building the exact same tree as the one where
the cache was made. Even though ccache can handle changed files just fine,
you would not be able to leverage it, since the cache would be hidden under
a different tree object.
Here's is an even more extreme idea: AFAIK, ccache works by hashing a
preprocessed source file, and mapping the hash value to the resulting object
file. A later lookup of the same preprocessed source file will yield the
object file without having to go through that pesky compilation.
Now, what if that hash function happened to be SHA1, and the mapping
happened to be the Git object database? In other words you could create a
notes tree where the keys are SHA1s from preprocessed source files, and the
note objects are the corresponding object files. As long as you don't call
gc_notes() on this notes tree, it doesn't really matter that your SHA1 keys
do not really exist as objects in the Git repo. The notes code can happily
map any arbitrary SHA1 sum to a note object; it's only in gc_notes() that we
actually care whether that SHA1 identifies an existing Git object.
Oh, and BTW, I consider the notes feature to be ready for prime time once
the patch series currently in 'pu' is fully merged.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #06; Wed, 20)
From: Sverre Rabbelier @ 2010-01-21 2:04 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Junio C Hamano
In-Reply-To: <201001210240.10522.johan@herland.net>
Heya,
On Thu, Jan 21, 2010 at 02:40, Johan Herland <johan@herland.net> wrote:
> You misremembered. Only the three first were merged to 'next'. Junio was
> about to merge the rest, but I asked him to hold until I had produced the
> current iteration.
Ah, I should have checked the last what's cooking; or looked at that
inter-diff thingy Junio's contemplating on doing :)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git notes: notes
From: Johan Herland @ 2010-01-21 2:05 UTC (permalink / raw)
To: Joey Hess; +Cc: git, Johannes.Schindelin
In-Reply-To: <20100120182438.GB31507@gnu.kitenet.net>
On Wednesday 20 January 2010, Joey Hess wrote:
> Johan Herland wrote:
> > > PS, Has anyone thought about using notes to warn bisect away from
> > > commits that are known to be unbuildable or otherwise cause bisection
> > > trouble?
> >
> > No, I haven't thought of that specific use case. Great idea! :)
>
> Only problem I see with doing it is it might be too easy to overwrite
> such a note with git notes edit -m
Well, you would have to run "git notes edit -m" with core.notesRef or
$GIT_NOTES_REF set to the notes ref where bisect information is stored (e.g.
"refs/notes/bisect").
In any case, I would not use "git notes" to maintain the bisect hints.
Rather, I'd add subcommands to "git bisect" that would take care of
maintaining the notes tree @ "refs/notes/bisect". Much more user-friendly
than telling the user to write their own bisect-notes by hand.
> Did you consider having -m append a line to an existing note?
Hmm. Not really. The "git notes" porcelain was originally written by Dscho,
and my builtin-ification of it (currently in 'pu') preserves the original
semantics of "git notes edit -m". It might make sense to change the
defaults; what do you think, Dscho?
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Andrey Погребной добавил Вас в друзья на сайте ВКонтакте.ру
From: ВКонтакте.ру @ 2010-01-21 2:10 UTC (permalink / raw)
To: git
git,
Andrey Погребной добавил Вас в друзья на сайте ВКонтакте.ру
Вы можете зайти на сайт и просмотреть страницы Ваших друзей, используя
Ваш e-mail и автоматически созданный пароль: Q6ES31pV
ВКонтакте.ру - сайт, который ежедневно позволяет десяткам миллионов людей находить старых друзей и оставаться с ними на связи, делиться фотографиями
и событиями из жизни.
Чтобы войти на сайт, пройдите по ссылке:
http://vkontakte.ru/login.php?regemail=git@vger.kernel.org#Q6ES31pV
Внимание: Ваша регистрация не будет активирована, если Вы проигнорируете
это приглашение.
Желаем удачи!
С уважением,
Администрация ВКонтакте.ру
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Yaroslav Halchenko @ 2010-01-21 2:33 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d1001201736g9160306g51949a5f36d83e14@mail.gmail.com>
$> GIT_CURL_VERBOSE=1 GIT_TRACE=2 ./git clone http://git.debian.org/git/pkg-exppsy/pymvpa.git
trace: built-in: git 'clone' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
warning: templates not found /home/yoh/share/git-core/templates
Initialized empty Git repository in /home/yoh/proj/misc/git/pymvpa/.git/
trace: run_command: 'remote-http' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
trace: exec: 'git' 'remote-http' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
trace: exec: 'git-remote-http' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
trace: run_command: 'git-remote-http' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
* Couldn't find host git.debian.org in the .netrc file; using defaults
* About to connect() to git.debian.org port 80 (#0)
* Trying 217.196.43.134... * Connected to git.debian.org (217.196.43.134) port 80 (#0)
> GET /git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.6.6.267.g5b159
Host: git.debian.org
Accept: */*
Pragma: no-cache
* The requested URL returned error: 404
* Closing connection #0
fatal: http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?
as for smart vs DAV -- don't see any smart alias handling in apache
configuration (I have/had no clue about some smart http in git, just looked at
apache template and saw smart aliases -- is there smth else to check within
webserver config?)
On Thu, 21 Jan 2010, Tay Ray Chuan wrote:
> On Thu, Jan 21, 2010 at 8:47 AM, Yaroslav Halchenko
> <debian@onerussian.com> wrote:
> > $> GIT_TRACE=2 ./git clone http://git.debian.org/git/pkg-exppsy/pymvpa.git
> > trace: built-in: git 'clone' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> > warning: templates not found /home/yoh/share/git-core/templates
> > Initialized empty Git repository in /home/yoh/proj/misc/git/pymvpa/.git/
> > trace: run_command: 'remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> > trace: exec: 'git' 'remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> > trace: exec: 'git-remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> > trace: run_command: 'git-remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> > fatal: http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?
> oh, and by the way, could you also run this again with GIT_CURL_VERBOSE=1?
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply
* Andrey Погребной добавил Вас в друзья на сайте ВКонтакте.ру
From: ВКонтакте.ру @ 2010-01-21 2:35 UTC (permalink / raw)
To: git
git,
Andrey Погребной добавил Вас в друзья на сайте ВКонтакте.ру
Вы можете зайти на сайт и просмотреть страницы Ваших друзей, используя
Ваш e-mail и автоматически созданный пароль: 77JAUVRc
ВКонтакте.ру - сайт, который ежедневно позволяет десяткам миллионов людей находить старых друзей и оставаться с ними на связи, делиться фотографиями
и событиями из жизни.
Чтобы войти на сайт, пройдите по ссылке:
http://vkontakte.ru/login.php?regemail=git@vger.kernel.org#77JAUVRc
Внимание: Ваша регистрация не будет активирована, если Вы проигнорируете
это приглашение.
Желаем удачи!
С уважением,
Администрация ВКонтакте.ру
^ permalink raw reply
* Re: git notes: notes
From: Johan Herland @ 2010-01-21 2:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Michael J Gruber, Joey Hess,
johan
In-Reply-To: <7vljfsz7vx.fsf@alter.siamese.dyndns.org>
On Thursday 21 January 2010, Junio C Hamano wrote:
> [...]
I just want to note that I've read the whole thread (up to here), and I
agree with pretty much everything that's been said so far:
- We should be more conservative about showing notes, especially in contexts
that may be used by scripts. Disabling notes by default when --pretty/--
format is in use, sounds like a good idea. So does adding a --show-notes
option for overriding the default.
- The format-patch bug is grave and unexcusable and must be fixed. Michael:
Thanks for discovering.
- I'd still like to keep notes as part of the default output from git log
and friends (when NOT using --pretty/--format). Only notes from a single
notes ref (typically the default "refs/notes/commits") should be shown.
- Re. Peff's worry that "git log" will fill up with random bisection cruft:
Any notes that are related to bisection (or any other special use case for
notes) should live on its own notes ref (typically "refs/notes/bisect" for
bisection cruft) that is not used by "git log" (unless you explicitly say so
through $GIT_NOTES_REF or core.notesRef).
- Re. Junio's worry that he will become the janitor for these patches.
Please don't. As long as the patch series is in 'pu', it is MY
responsibility to address issues and organize any additional patches on top
of the series. Feel free to ignore all additional patches, and wait for an
updated series from my end.
- Yes, there should be more tests verifying that there is no negative impact
on git log and friends. Docs must be updated as well, where needed.
Unfortunately I don't have the time to work on this right now, but I'll do
my best to get around to it as soon as possible (at least by the end of the
coming weekend).
Again, thanks for your involvement. It is really appreciated.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git notes: notes
From: Junio C Hamano @ 2010-01-21 3:03 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Johannes Schindelin, Michael J Gruber, Joey Hess
In-Reply-To: <201001210354.22756.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> - Re. Junio's worry that he will become the janitor for these patches.
>
> Please don't. As long as the patch series is in 'pu', it is MY
> responsibility ...
I am not worried so much about what is not in 'next' yet. My worry right
now is primarily about what to do with upcoming 1.7.0 and also the 1.6.6.X
series, which already shipped with "format-patch" that injects notes in
its output.
^ permalink raw reply
* Re: git notes: notes
From: Junio C Hamano @ 2010-01-21 3:37 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Michael J Gruber, Joey Hess, Johan Herland,
git
In-Reply-To: <7vljfsz7vx.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Actually I am of two minds regarding --pretty={short,medium} and the
> like. The "how about this" patch may be the safest for people who are
> used to read "log --pretty=xxx" output with scripts, but it does look
> inconsistent and hard to explain to new people who do not even know that
> there were versions of git that does not know about notes.
Heh, it is not surprising that we have this bug, given that all of us just
missed how bogus my "how about this" patch was ;-)
The check for "if (fmt_pretty)" only kicks in when that thing was read
from the configuration; handling of command line --pretty and --pretty=
options happen long after that, when we call setup_revisions().
So if we really wanted to say "If the user explicitly tells us to run
under a particular --pretty mode, we don't show notes by default.", we
would need a patch like this on top of it.
Another thing to note is that "work differently between no --pretty on the
command line and an explicit --pretty=medium" is more work than "we always
default to show notes if showing in the default verbosity".
This version considers a user supplied "format.pretty" configuration as
"the user told us to use this specific format, and we won't show notes
unless explicitly told". I personally don't care either way exactly
because I don't use that configuration (nor teach others to use it), but
in a sense the configuration is setting a personal "default", so I think
it could be argued that we should instead show the notes by default in
that case (i.e. remove "rev->pretty_given = 1" in the first hunk).
builtin-log.c | 9 ++++++---
revision.c | 4 ++++
revision.h | 2 ++
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 3bc3919..1e05b0f 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -39,10 +39,10 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
rev->abbrev = DEFAULT_ABBREV;
rev->commit_format = CMIT_FMT_DEFAULT;
- if (fmt_pretty)
+ if (fmt_pretty) {
get_commit_format(fmt_pretty, rev);
- else
- rev->show_notes = 1;
+ rev->pretty_given = 1;
+ }
rev->verbose_header = 1;
DIFF_OPT_SET(&rev->diffopt, RECURSIVE);
rev->show_root_diff = default_show_root;
@@ -60,6 +60,9 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
usage(builtin_log_usage);
argc = setup_revisions(argc, argv, rev, "HEAD");
+ if (!rev->show_notes_given && !rev->pretty_given)
+ rev->show_notes = 1;
+
if (rev->diffopt.pickaxe || rev->diffopt.filter)
rev->always_show_header = 0;
if (DIFF_OPT_TST(&rev->diffopt, FOLLOW_RENAMES)) {
diff --git a/revision.c b/revision.c
index 7e00a6c..0de78fb 100644
--- a/revision.c
+++ b/revision.c
@@ -1161,14 +1161,18 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->verbose_header = 1;
} else if (!strcmp(arg, "--pretty")) {
revs->verbose_header = 1;
+ revs->pretty_given = 1;
get_commit_format(arg+8, revs);
} else if (!prefixcmp(arg, "--pretty=") || !prefixcmp(arg, "--format=")) {
revs->verbose_header = 1;
+ revs->pretty_given = 1;
get_commit_format(arg+9, revs);
} else if (!strcmp(arg, "--show-notes")) {
revs->show_notes = 1;
+ revs->show_notes_given = 1;
} else if (!strcmp(arg, "--no-notes")) {
revs->show_notes = 0;
+ revs->show_notes_given = 1;
} else if (!strcmp(arg, "--oneline")) {
revs->verbose_header = 1;
get_commit_format("oneline", revs);
diff --git a/revision.h b/revision.h
index 4167c1e..a14deef 100644
--- a/revision.h
+++ b/revision.h
@@ -81,6 +81,8 @@ struct rev_info {
unsigned int shown_one:1,
show_merge:1,
show_notes:1,
+ show_notes_given:1,
+ pretty_given:1,
abbrev_commit:1,
use_terminator:1,
missing_newline:1,
^ permalink raw reply related
* Re: git notes: notes
From: Johannes Schindelin @ 2010-01-21 3:59 UTC (permalink / raw)
To: Johan Herland; +Cc: Joey Hess, git
In-Reply-To: <201001210305.05309.johan@herland.net>
Hi,
On Thu, 21 Jan 2010, Johan Herland wrote:
> On Wednesday 20 January 2010, Joey Hess wrote:
>
> > Did you consider having -m append a line to an existing note?
>
> Hmm. Not really. The "git notes" porcelain was originally written by
> Dscho, and my builtin-ification of it (currently in 'pu') preserves the
> original semantics of "git notes edit -m". It might make sense to change
> the defaults; what do you think, Dscho?
I do not really care as long as there is a nice way to edit the complete
note interactively.
Of course, I _do_ expect people to get confused just like they do with the
current inconsistencies: "git commit -m" does not really append, but set
the commit message, even if you amend a commit.
So maybe you want to use a different command line option for that.
Ciao,
Dscho
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Tay Ray Chuan @ 2010-01-21 4:01 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git
In-Reply-To: <20100121023310.GB18213@onerussian.com>
Hi,
On Thu, Jan 21, 2010 at 10:33 AM, Yaroslav Halchenko
<debian@onerussian.com> wrote:
> * Trying 217.196.43.134... * Connected to git.debian.org (217.196.43.134) port 80 (#0)
>> GET /git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack HTTP/1.1
> User-Agent: git/1.6.6.267.g5b159
> Host: git.debian.org
> Accept: */*
> Pragma: no-cache
>
> * The requested URL returned error: 404
> * Closing connection #0
> fatal: http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?
I don't think git's at fault here, as we're getting a 404 Not Found.
Could you check that the repository (the one the url points to, after
taking into any url rewriting) is a bare one, ie. has structure
pkg-exppsy/
|-pymvpa.git
|-objects/
|-info/
|-refs/
|-...
rather than the non-bare
pkg-exppsy/
|-pymvpa.git
|-.git
|-objects/
|-info/
|-refs/
|-...
?
> as for smart vs DAV -- don't see any smart alias handling in apache
> configuration (I have/had no clue about some smart http in git, just looked at
> apache template and saw smart aliases -- is there smth else to check within
> webserver config?)
If that's the case, I don't think it's related to your problem. (Btw,
"smart" refers to the http protocol that git can use to sync your
repo, via a CGI program on the server, instead of WebDAV. See
git-http-backend(1) for details.)
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: git notes: notes
From: Joey Hess @ 2010-01-21 4:05 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.1001210457380.4985@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
Johannes Schindelin wrote:
> I do not really care as long as there is a nice way to edit the complete
> note interactively.
>
> Of course, I _do_ expect people to get confused just like they do with the
> current inconsistencies: "git commit -m" does not really append, but set
> the commit message, even if you amend a commit.
>
> So maybe you want to use a different command line option for that.
Maybe: git notes add [-m|-F]
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #06; Wed, 20)
From: Junio C Hamano @ 2010-01-21 4:06 UTC (permalink / raw)
To: Johan Herland; +Cc: Sverre Rabbelier, git
In-Reply-To: <201001210240.10522.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Thursday 21 January 2010, Sverre Rabbelier wrote:
>> On Thu, Jan 21, 2010 at 01:52, Junio C Hamano <gitster@pobox.com> wrote:
>> > * jh/notes (2010-01-17) 23 commits
>> > [...]
>> > Updated with a re-roll.
>>
>> Just checking, you reverted all from next (with exception of the first
>> three), and now re-queued it to pu, with the first three still in
>> next? Or did I mis-remember and did only the first three make it to
>> next in the first place?
>
> You misremembered. Only the three first were merged to 'next'. Junio was
> about to merge the rest, but I asked him to hold until I had produced the
> current iteration.
I've been meaning to merge the first three to 'master', as many people
have been running 'next' and new features tend to be exercised less by
those on 'master' than on 'next', and it would be beneficial to make
'master' at 1.7.0-rc0 as close to what we have had in 'next' for a long
time.
Worries?
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Yaroslav Halchenko @ 2010-01-21 4:38 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d1001202001h4c794166y4bcf01b42f3ea1bb@mail.gmail.com>
On Thu, 21 Jan 2010, Tay Ray Chuan wrote:
> > fatal: http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?
> I don't think git's at fault here, as we're getting a 404 Not Found.
khe khe, pardon me, but if git can't talk to its nephew (ie its own
repository which was created with earlier version), whenever another
nephew (ie git of earlier version) can talk to it, I do consider it to
be git's fault ;)
let me zoom in onto difference in communication between two different versions :
* Trying 217.196.43.134... * Connected to git.debian.org (217.196.43.134) port 80 (#0)
> GET /git/pkg-exppsy/pymvpa.git/info/refs HTTP/1.1
User-Agent: git/1.6.5
Host: git.debian.org
Accept: */*
Pragma: no-cache
< HTTP/1.1 200 OK
whenever, once again, for 1.6.6 it looked much shorter:
* Trying 217.196.43.134... * Connected to git.debian.org (217.196.43.134) port 80 (#0)
> GET /git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.6.6.267.g5b159
Host: git.debian.org
Accept: */*
Pragma: no-cache
* The requested URL returned error: 404
* Closing connection #0
fatal: http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?
> Could you check that the repository (the one the url points to, after
> taking into any url rewriting) is a bare one, ie. has structure
yes - it is bare... I was 101% sure (isn't that a convention to have
.git suffix for directories with bare repositories), but just to make
sure:
$> cd /srv/git.debian.org/git/pkg-exppsy/pymvpa.git/
total 76
8 branches/ 8 config 8 description 8 HEAD 8 hooks/ 8 info/ 8 objects/ 12 packed-refs 8 refs/
> If that's the case, I don't think it's related to your problem. (Btw,
> "smart" refers to the http protocol that git can use to sync your
> repo, via a CGI program on the server, instead of WebDAV. See
> git-http-backend(1) for details.)
thanks for info, I did know about this beastie.
I see no references to git-http-backend in apache config -- so indeed
should not be the case... but from the git-http-backend description:
,---
| By default, only the `upload-pack` service is enabled, which serves
| 'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from
| 'git-fetch', 'git-pull', and 'git-clone'.
`---
so, it looks like 1.6.6 for some reason decided to assume that it is "smart"
http whenever it is not? is that the case here?
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Ilari Liusvaara @ 2010-01-21 5:08 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git, Shawn O. Pearce
In-Reply-To: <20100121004756.GA18213@onerussian.com>
On Wed, Jan 20, 2010 at 07:47:56PM -0500, Yaroslav Halchenko wrote:
Added spearce to cc.
> Dear Git Developers,
>
> Some users of our project started recently to complain that they could not
> clone the repository via http (git:// wasn't a choice due to heavy firewalling)
> and because http:// was used as a protocol to get sources in some distributions
> (e.g. macports).
>
> Cloning of the repository works fine with v1.6.5.7 but fails with v1.6.6-rc0.
> I haven't done full bisection since that repository is relatively bulky and
> poor server is quite loaded anyways, so I thought you just would get a clue
> without going brute-force. But here are the details: in case of failing
> operation, I immediately get failure:
>
> $> GIT_TRACE=2 ./git clone http://git.debian.org/git/pkg-exppsy/pymvpa.git
> trace: built-in: git 'clone' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> warning: templates not found /home/yoh/share/git-core/templates
> Initialized empty Git repository in /home/yoh/proj/misc/git/pymvpa/.git/
> trace: run_command: 'remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> trace: exec: 'git' 'remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> trace: exec: 'git-remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> trace: run_command: 'git-remote-curl' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git' 'http://git.debian.org/git/pkg-exppsy/pymvpa.git'
> fatal: http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?
Looks like remote-curl (which handles http) issues request for:
'.../info/refs?service=git-upload-pack'
And expects that if there is no smart HTTP server there for the request to be
interpretted as:
'.../info/refs'
(i.e. webserver would ignore the query). This isn't true for git.debian.org.
Requesting the latter works (and the data formatting looks sane), but the
former is 404. This causes the fetch to fail.
-Ilari
^ permalink raw reply
* Re: [PATCH] Fix memory corruption when .gitignore does not end by \n
From: Jonathan del Strother @ 2010-01-21 6:08 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <fcaeb9bf1001201738x5cd374c2o280ec42d6d65c0f7@mail.gmail.com>
2010/1/21 Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
> On 1/21/10, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>
>> > This patch causes a crash for me. Not sure if it does for anybody else.
>>
>>
>> I am puzzled. What do you mean by this? If this patch makes the code
>> crash, then it is not a fix. Is this meant as "Jonathan, can you try this
>> patch and tell me what happens, so that I can diagnose the issue better?"
>> patch?
>
> I mean the t3001 patch in comment part, which removes \n at the end of
> .gitignore and crashes the unmodified git.
>
> IOW I found a problem and this patch (not the t3001 one) should fix
> it. Not sure if this causes Jonathan problem though.
>
>> Is it better/safer to revert the entire nd/sparse topic from the master in
>> the meantime before we know what is going on?
>
> I would wait for Jonathan response. If this is not the cause, probably
> safer to revert it.
> --
> Duy
>
Think it's all fixed after applying this patch - at least, I can no
longer reproduce the crash, whereas I was able to make it fail ~90% of
the time before.
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Tay Ray Chuan @ 2010-01-21 6:47 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Yaroslav Halchenko, git, Shawn O. Pearce
In-Reply-To: <20100121050850.GA18896@Knoppix>
Hi,
On Thu, Jan 21, 2010 at 1:08 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> Looks like remote-curl (which handles http) issues request for:
>
> '.../info/refs?service=git-upload-pack'
>
> And expects that if there is no smart HTTP server there for the request to be
> interpretted as:
>
> '.../info/refs'
>
> (i.e. webserver would ignore the query). This isn't true for git.debian.org.
> Requesting the latter works (and the data formatting looks sane), but the
> former is 404. This causes the fetch to fail.
afaik, putting a "?var1=val1&var2=...." still makes it a normal GET
request, even if the url requested is just a plain file and not some
cgi handler that uses those variables/values.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Fix memory corruption when .gitignore does not end by \n
From: Junio C Hamano @ 2010-01-21 6:48 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, git, Jeff King, Jonathan del Strother
In-Reply-To: <fcaeb9bf1001201738x5cd374c2o280ec42d6d65c0f7@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> I mean the t3001 patch in comment part, which removes \n at the end of
> .gitignore and crashes the unmodified git.
>
> IOW I found a problem and this patch (not the t3001 one) should fix
> it. Not sure if this causes Jonathan problem though.
Ah, I see. And a bug that leaves a string unterminated will exhibit
different symptoms depending on what garbage happens to follow it, so it
may not be universally reproducible.
Thanks; applied (and I saw Jonathan's Ack, as well).
Thanks, both.
^ permalink raw reply
* Re: [PATCH 1/2] Allow to override mergetool.prompt with $GIT_MERGETOOL*_PROMPT
From: David Aguilar @ 2010-01-21 7:44 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <4B572192.2020606@gmail.com>
Hi,
On Wed, Jan 20, 2010 at 04:30:26PM +0100, Sebastian Schuberth wrote:
> This is for symmetry with git-difftool, and to make should_prompt_merge ()
> reusable from within git-difftool--helper.
>
> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
> ---
> git-mergetool--lib.sh | 9 +++++++++
> git-mergetool.sh | 3 ++-
> 2 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index 5b62785..16b0343 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -7,6 +7,15 @@ merge_mode() {
> test "$TOOL_MODE" = merge
> }
>
> +should_prompt_merge () {
> + local prompt=$(git config --bool mergetool.prompt || echo true)
> + if test "$prompt" = true; then
> + test -z "$GIT_MERGETOOL_NO_PROMPT"
> + else
> + test -n "$GIT_MERGETOOL_PROMPT"
> + fi
> +}
Someone already mentioned dropping "local" here.
The GIT_DIFFTOOL*_PROMPT variables are implementation details
about how git-difftool passes options to git-difftool--helper.
We don't advertise them in the documentation so we probably
shouldn't support them aside from what is needed for
git-difftool. We can drop this part.
61ed71dc just recently removed git-difftool--helper's use of
GIT_MERGE_TOOL based on this rationale.
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index b52a741..d453cb0 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -202,7 +202,8 @@ merge_file () {
> return 0
> }
>
> -prompt=$(git config --bool mergetool.prompt || echo true)
> +should_prompt_merge
> +prompt=$?
>
> while test $# != 0
> do
git-difftool falling back to mergetool.prompt when
difftool.prompt is not available is good, especially
since we advertise that feature.
Once you drop the local declarations and the env. variable
it should be good to go. Patch v2, soon?
--
David
^ permalink raw reply
* Re: git equivalent to clearcase wink-in
From: Matthieu Moy @ 2010-01-21 7:46 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jamie Wellnitz, Richard Assal, git
In-Reply-To: <20100120211251.GA26274@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> On Wed, Jan 20, 2010 at 04:05:46PM -0500, Jamie Wellnitz wrote:
>> Would something like ccache (compiler cache) help you out? It's not
>> the same as wink-in (which, as I understand it, copies an already
>> built object file from someone else who has built it). Instead each
>> user has their own cache, so everyone has to pay the expensive build
>> price at least once.
>
> Surely the ccache directory could be shared on nfs or some other network
> filesystem.
There's a section "SHARING A CACHE" here:
http://ccache.samba.org/ccache-man.html
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: problem cloning via http since v1.6.6-rc0
From: Tay Ray Chuan @ 2010-01-21 7:51 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: Ilari Liusvaara, Shawn O. Pearce, git
In-Reply-To: <be6fef0d1001202247l7467a14ap8181eb3ed830167a@mail.gmail.com>
Hi,
On Thu, 21 Jan 2010 14:47:37 +0800
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Thu, Jan 21, 2010 at 1:08 PM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> > Looks like remote-curl (which handles http) issues request for:
> >
> > '.../info/refs?service=git-upload-pack'
> >
> > And expects that if there is no smart HTTP server there for the request to be
> > interpretted as:
> >
> > '.../info/refs'
> >
> > (i.e. webserver would ignore the query). This isn't true for git.debian.org.
> > Requesting the latter works (and the data formatting looks sane), but the
> > former is 404. This causes the fetch to fail.
>
> afaik, putting a "?var1=val1&var2=...." still makes it a normal GET
> request, even if the url requested is just a plain file and not some
> cgi handler that uses those variables/values.
Yaroslav, sorry for making you run in circles - it really is git's
fault (sorta).
In recent versions of git, we were sending out the GET request for
info/refs with a query string (?serivce=<service name>). I'm not sure
why, but your server is not playing nice when the query string is
appended.
Could you try this patch and see if it solves the issue? I manage to
clone your repo successfully with it.
--
Cheers,
Ray Chuan
-->8--
Subject: [PATCH] http/remote-curl: coddle picky servers
When "info/refs" is a static file and not behind a CGI handler, some
servers may not handle a GET request for it with a query string
appended (eg. "?foo=bar") properly.
If such a request fails, retry it sans the query string, and also
discount the possibility of using the "smart" protocol (since no
service is specified with "?service=<service name>").
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
remote-curl.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 1361006..a904164 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -102,7 +102,7 @@ static struct discovery* discover_refs(const char *service)
struct strbuf buffer = STRBUF_INIT;
struct discovery *last = last_discovery;
char *refs_url;
- int http_ret, is_http = 0;
+ int http_ret, is_http = 0, proto_git_candidate = 1;
if (last && !strcmp(service, last->service))
return last;
@@ -121,6 +121,19 @@ static struct discovery* discover_refs(const char *service)
init_walker();
http_ret = http_get_strbuf(refs_url, &buffer, HTTP_NO_CACHE);
+
+ /* try again with "plain" url (no ? or & appended) */
+ if (http_ret != HTTP_OK) {
+ free(refs_url);
+ strbuf_reset(&buffer);
+
+ proto_git_candidate = 0;
+ strbuf_addf(&buffer, "%s/info/refs", url);
+ refs_url = strbuf_detach(&buffer, NULL);
+
+ http_ret = http_get_strbuf(refs_url, &buffer, HTTP_NO_CACHE);
+ }
+
switch (http_ret) {
case HTTP_OK:
break;
@@ -137,7 +150,8 @@ static struct discovery* discover_refs(const char *service)
last->buf_alloc = strbuf_detach(&buffer, &last->len);
last->buf = last->buf_alloc;
- if (is_http && 5 <= last->len && last->buf[4] == '#') {
+ if (is_http && proto_git_candidate
+ && 5 <= last->len && last->buf[4] == '#') {
/* smart HTTP response; validate that the service
* pkt-line matches our request.
*/
--
1.6.6.1.337.g96bc8
^ permalink raw reply related
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