* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Mike Ralphson @ 2008-11-17 10:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List, Linus Torvalds
In-Reply-To: <492148AD.1090604@viscovery.net>
2008/11/17 Johannes Sixt <j.sixt@viscovery.net>:
> Mike Ralphson schrieb:
>> 2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
>>> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>>> This introduces make variable NO_PTHREADS for platforms that lack the
>>>> support for pthreads library or people who do not want to use it for
>>>> whatever reason. When defined, it makes the multi-threaded index
>>>> preloading into a no-op, and also disables threaded delta searching by
>>>> pack-objects.
>>> Ack. Makes sense.
>>
>> I'd be minded to make this the default on AIX to keep the prerequisite
>> list as small as possible, then people can opt-in for the performance
>> benefits if required.
>
> Is pthreads not a standard shipment on AIX? I would set NO_PTHREADS only
> if we know in advance that there are many installations without pthreads.
> (And I don't know what the situation is.)
I should have dug a bit further, it seems to be present on my 5.3
machines but I still need to determine whether it got installed by
default. Either way it must need some other link flags...
> BTW, this needs to be squashed in, because we don't have pthreads on Windows:
>
> diff --git a/Makefile b/Makefile
> index ffc9531..3a30b8c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -769,6 +769,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
> NO_STRCASESTR = YesPlease
> NO_STRLCPY = YesPlease
> NO_MEMMEM = YesPlease
> + NO_PTHREADS = YesPlease
> NEEDS_LIBICONV = YesPlease
> OLD_ICONV = YesPlease
> NO_C99_FORMAT = YesPlease
>
Ta. Ok to add your S-o-B on a squashed patch?
Mike
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Jakub Narebski @ 2008-11-17 10:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Petr Baudis
In-Reply-To: <7vskpqzms5.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Nov 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Dnia poniedziałek 17. listopada 2008 07:10, Giuseppe Bilotta napisał:
>>> On Mon, Nov 17, 2008 at 2:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> [...]
>>>> First, you forgot the signoff, but you have addressed that already.
>>>>
>>>>
>>>> Second, I thought at first that it would be good for the patch to also
>>>> simplify %feature hash, using "'default' => 1" instead of current bit
>>>> convoluted "'default' => [1]", at the cost of bit more code for
>>>> defensive programming. But now I think that if it is to be done,
>>>> it should be put as separate patch.
>>>
>>> Is this an ACK? 8-D
>>
>> I'm sorry. Yes, it is.
>
> Are you sure, even with those unnecessary changes from list context
> assignments to scalar ones?
Well, on one hand this change is not _necessary_, as it would work
without it. On the other hand it feels like cleanup (like e.g. using
tabs to indent but spaces to align, or word-wrapping too long lines).
So I think I'll pass the ball to you... your call ;-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: publish since current state?
From: Gennady Kushnir @ 2008-11-17 10:52 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <49211B78.50204@op5.se>
Thank your for your reply.
But I could not find documentation for grafts... it is only mentioned
in glossary.
The only thing I found with google is 1-year-old a mail list post
http://marc.info/?l=git&m=119636089519572&w=2
could you point out some direct link to grafts documentation?
And also - what you mean by "copy the object database
from the old repository into the new one" ?
I'm not aware of such operation. What command does it?
And will not that copied database go online as dangling objects?
Gennady Kushnir
2008/11/17 Andreas Ericsson <ae@op5.se>:
> Gennady Kushnir wrote:
>>
>> Hello list.
>> I'm going to publish my work into online public repository.
>> I have several months of previous history in my local git repo. And I
>> don't want to make it all public.
>> Is it possible to publish just a shallow copy of my repository storing
>> my current tree?
>
> Yes. Look for 'grafts' in the documentation. You'll have to create a
> new repository containing only the most recent code first, and then
> create the grafts-file in that repository and copy the object database
> from the old repository into the new one.
>
>> I'd also like to keep my local history private but push new commits
>> from it into that online repo.
>>
>
> The grafts solution will work like that, assuming you don't publish
> your grafts-file.
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Junio C Hamano @ 2008-11-17 10:51 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git, gitster
In-Reply-To: <4ac8254d0811170237o78060cb3k4a64dceaa3a475d0@mail.gmail.com>
"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
> I think you need to have something like the following applied on top of
> what's in pu to be able to use "pull -v -v -v" and be able to count the
> occurrences via parse-options.c. What do you think?
Makes sense, except that as a futureproofing we may be better off doing
the same for -q as well.
> --- git-pull.sh 2008-11-17 11:32:19.000000000 +0100
> +++ git-pull.sh.b 2008-11-17 11:33:03.000000000 +0100
> @@ -26,7 +26,7 @@
> -q|--quiet)
> verbosity=-q ;;
> -v|--verbose)
> - verbosity=-v ;;
> + verbosity="$verbosity -v" ;;
> -n|--no-stat|--no-summary)
> no_stat=-n ;;
> --stat|--summary)
>
> Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-17 10:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6ziy69h.fsf@gitster.siamese.dyndns.org>
On Mon, Nov 17, 2008 at 11:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> I think you need to have something like the following applied on top of
>> what's in pu to be able to use "pull -v -v -v" and be able to count the
>> occurrences via parse-options.c. What do you think?
>
> Makes sense, except that as a futureproofing we may be better off doing
> the same for -q as well.
What's funny is that my original patch to git-pull.sh had both :).
>> --- git-pull.sh 2008-11-17 11:32:19.000000000 +0100
>> +++ git-pull.sh.b 2008-11-17 11:33:03.000000000 +0100
>> @@ -26,7 +26,7 @@
>> -q|--quiet)
>> verbosity=-q ;;
>> -v|--verbose)
>> - verbosity=-v ;;
>> + verbosity="$verbosity -v" ;;
>> -n|--no-stat|--no-summary)
>> no_stat=-n ;;
>> --stat|--summary)
>>
>> Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
>
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Constantine Plotnikov @ 2008-11-17 11:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vy6ziy69h.fsf@gitster.siamese.dyndns.org>
On Mon, Nov 17, 2008 at 1:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> I think you need to have something like the following applied on top of
>> what's in pu to be able to use "pull -v -v -v" and be able to count the
>> occurrences via parse-options.c. What do you think?
>
I'm just interested why not just optional level argument to verbosity
like --verbose=2 or -v2?
Regards,
Constantine
^ permalink raw reply
* [PATCH 1/3] git-remote: match usage string with the manual pages
From: crquan @ 2008-11-17 11:15 UTC (permalink / raw)
To: git
From: Cheng Renquan <crquan@gmail.com>
Signed-off-by: Cheng Renquan <crquan@gmail.com>
---
builtin-remote.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 71696b5..d032f25 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -8,12 +8,12 @@
#include "refs.h"
static const char * const builtin_remote_usage[] = {
- "git remote",
- "git remote add <name> <url>",
+ "git remote [-v | --verbose]",
+ "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
- "git remote show <name>",
- "git remote prune <name>",
+ "git remote show [-n] <name>",
+ "git remote prune [-n | --dry-run] <name>",
"git remote update [group]",
NULL
};
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/3] git-remote: add verbose mode to git remote update
From: crquan @ 2008-11-17 11:15 UTC (permalink / raw)
To: git
In-Reply-To: <1226920551-28303-1-git-send-email-crquan@gmail.com>
From: Cheng Renquan <crquan@gmail.com>
Pass the verbose mode parameter to the underlying fetch command.
$ ./git remote -v update
Updating origin
From git://git.kernel.org/pub/scm/git/git
= [up to date] html -> origin/html
= [up to date] maint -> origin/maint
= [up to date] man -> origin/man
= [up to date] master -> origin/master
= [up to date] next -> origin/next
= [up to date] pu -> origin/pu
= [up to date] todo -> origin/todo
Signed-off-by: Cheng Renquan <crquan@gmail.com>
---
builtin-remote.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index d032f25..fff9920 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
"git remote rm <name>",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote update [group]",
+ "git remote update [-v | --verbose] [group]",
NULL
};
@@ -40,9 +40,13 @@ static int opt_parse_track(const struct option *opt, const char *arg, int not)
return 0;
}
-static int fetch_remote(const char *name)
+static int fetch_remote(const char *name, const char *url)
{
- const char *argv[] = { "fetch", name, NULL };
+ const char *argv[] = { "fetch", name, NULL, NULL };
+ if (verbose) {
+ argv[1] = "-v";
+ argv[2] = name;
+ }
printf("Updating %s\n", name);
if (run_command_v_opt(argv, RUN_GIT_CMD))
return error("Could not fetch %s", name);
@@ -117,7 +121,7 @@ static int add(int argc, const char **argv)
return 1;
}
- if (fetch && fetch_remote(name))
+ if (fetch && fetch_remote(name, url))
return 1;
if (master) {
@@ -769,8 +773,12 @@ static int prune(int argc, const char **argv)
static int get_one_remote_for_update(struct remote *remote, void *priv)
{
struct string_list *list = priv;
+
if (!remote->skip_default_update)
- string_list_append(xstrdup(remote->name), list);
+ string_list_append(remote->name, list)->util =
+ remote->url_nr > 0
+ ? (void *)remote->url[remote->url_nr-1] : NULL;
+
return 0;
}
@@ -818,7 +826,7 @@ static int update(int argc, const char **argv)
result = for_each_remote(get_one_remote_for_update, &list);
for (i = 0; i < list.nr; i++)
- result |= fetch_remote(list.items[i].string);
+ result |= fetch_remote(list.items[i].string, list.items[i].util);
/* all names were strdup()ed or strndup()ed */
list.strdup_strings = 1;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 3/3] git-remote: simplifying get_one_entry
From: crquan @ 2008-11-17 11:15 UTC (permalink / raw)
To: git
In-Reply-To: <1226920551-28303-2-git-send-email-crquan@gmail.com>
From: Cheng Renquan <crquan@gmail.com>
The loop for remote->url_nr is really useless,
set to the last one directly is better.
Signed-off-by: Cheng Renquan <crquan@gmail.com>
---
builtin-remote.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index fff9920..59d69a5 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -839,13 +839,9 @@ static int get_one_entry(struct remote *remote, void *priv)
{
struct string_list *list = priv;
- if (remote->url_nr > 0) {
- int i;
-
- for (i = 0; i < remote->url_nr; i++)
- string_list_append(remote->name, list)->util = (void *)remote->url[i];
- } else
- string_list_append(remote->name, list)->util = NULL;
+ string_list_append(remote->name, list)->util =
+ remote->url_nr > 0
+ ? (void *)remote->url[remote->url_nr-1] : NULL;
return 0;
}
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Johannes Sixt @ 2008-11-17 11:25 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Junio C Hamano, Git Mailing List, Linus Torvalds
In-Reply-To: <e2b179460811170245t1845cc66h7cb2a18c43a79359@mail.gmail.com>
Mike Ralphson schrieb:
> 2008/11/17 Johannes Sixt <j.sixt@viscovery.net>:
>> Mike Ralphson schrieb:
>>> 2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
>>>> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>>>> This introduces make variable NO_PTHREADS for platforms that lack the
>>>>> support for pthreads library or people who do not want to use it for
>>>>> whatever reason. When defined, it makes the multi-threaded index
>>>>> preloading into a no-op, and also disables threaded delta searching by
>>>>> pack-objects.
>>>> Ack. Makes sense.
>>> I'd be minded to make this the default on AIX to keep the prerequisite
>>> list as small as possible, then people can opt-in for the performance
>>> benefits if required.
>> Is pthreads not a standard shipment on AIX? I would set NO_PTHREADS only
>> if we know in advance that there are many installations without pthreads.
>> (And I don't know what the situation is.)
>
> I should have dug a bit further, it seems to be present on my 5.3
> machines but I still need to determine whether it got installed by
> default. Either way it must need some other link flags...
I tried compiling with THREADED_DELTA_SEARCH=Yes, and it fails with
CC builtin-pack-objects.o
In file included from /usr/include/sys/pri.h:29,
from /usr/include/sys/sched.h:38,
from /usr/include/sched.h:52,
from /usr/include/pthread.h:43,
from builtin-pack-objects.c:22:
/usr/include/sys/proc.h:203: parse error before "crid_t"
/usr/include/sys/proc.h:212: parse error before "p_class"
/usr/include/sys/proc.h:355: parse error before '}' token
:-( Maybe NO_PTHREADS is indeed the safer choice? I'm not going to dig
into this today, though. (I'm on AIX 4.3.something.)
>> BTW, this needs to be squashed in, because we don't have pthreads on Windows:
>>
>> diff --git a/Makefile b/Makefile
>> index ffc9531..3a30b8c 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -769,6 +769,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
>> NO_STRCASESTR = YesPlease
>> NO_STRLCPY = YesPlease
>> NO_MEMMEM = YesPlease
>> + NO_PTHREADS = YesPlease
>> NEEDS_LIBICONV = YesPlease
>> OLD_ICONV = YesPlease
>> NO_C99_FORMAT = YesPlease
>>
>
> Ta. Ok to add your S-o-B on a squashed patch?
Sure. Use this address please:
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* Re: publish since current state?
From: Andreas Ericsson @ 2008-11-17 11:44 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: git
In-Reply-To: <23ae57c00811170252uba2cd22kb99a23134f026fc6@mail.gmail.com>
Gennady Kushnir wrote:
> Thank your for your reply.
> But I could not find documentation for grafts... it is only mentioned
> in glossary.
> The only thing I found with google is 1-year-old a mail list post
> http://marc.info/?l=git&m=119636089519572&w=2
> could you point out some direct link to grafts documentation?
>
>From that link can be gleaned the important stuff, actually.
--8<--8<--
Graft points are configured via the .git/info/grafts file. It has one
record per line describing a commit and its fake parents by listing
object names separated by a space and terminated by a newline.
<commit sha1> <parent sha1> [<parent sha1>]*
--8<--8<--
> And also - what you mean by "copy the object database
> from the old repository into the new one" ?
I mean something like this:
cd old_repo && git repack -a -d && \
cp .git/objects/pack/* ../new_repo/.git/objects/pack
cd ../new_repo && \
echo "$first_sha1_of_new_repo $last_sha1_of_old_repo" \
> .git/info/grafts
and you're done.
> I'm not aware of such operation. What command does it?
> And will not that copied database go online as dangling objects?
>
No. The grafts file will connect the two histories so they
look like one. The public repo where people clone from should
not have the grafts-file, and you should run "git repack -a -d"
in that repository to prevent dumb commit walkers from getting
access to all your ancient history through a mega-pack.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCHv3 3/4] gitweb: separate heads and remotes lists
From: Giuseppe Bilotta @ 2008-11-17 13:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <7viqqn377m.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 16, 2008 at 6:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>> - my @headlist = git_get_heads_list(16);
>> + my @headlist = git_get_heads_list(16, 'heads');
>> + my @remotelist = $remote_heads ? git_get_heads_list(16, 'remotes') : ();
>
> Wasteful to run one for-each-ref for each list.
>
> You earlier introduced $ref_item{'class'} so that you can differenciate
> what you got from git_get_heads_list(); make use of it, perhaps like:
>
> my @heads_list = git_get_heads_list(16, \%head_class);
> my @headlist = grep { $_->{'class'} eq 'head' } @heads_list;
> my @remotelist = grep { $_->{'class'} eq 'remote' } @heads_list;
>
> By the way, your [2/4] used "heads" and "remotes" as class, while your
> [1/4] stored 'head' and 'remote' in $ref_item{'class'}. Notice the above
> suggestion corrects this discrepancy as well.
Although I agree with the head_class idea, I would like to point out
that doing a single git call to retrieve all refs and then selecting
the ones we want and doing multiple git calls are not equivalent.
First of all, with multiple calls we can limit the calls to retrieve
at most 16 refs of each kind, whereas this cannot be done with a
single call for all the refs. I'm not sure however, performance-wise,
if it's faster to filter the first 16 refs of each after retrieving
all of them, or doing multiple calls, especially with lots of refs.
Moreover, gitweb is already doing multiple for-each-ref calls to get
tags and heads. I guess that at this point we could go the extra mile
and include tags in the refs management. Of course, the problem of how
to handle the rate limiting remains.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv3 3/4] gitweb: separate heads and remotes lists
From: Giuseppe Bilotta @ 2008-11-17 13:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <cb7bb73a0811170511s4df6efbbl220fa89469388aca@mail.gmail.com>
On Mon, Nov 17, 2008 at 2:11 PM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> On Sun, Nov 16, 2008 at 6:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>> - my @headlist = git_get_heads_list(16);
>>> + my @headlist = git_get_heads_list(16, 'heads');
>>> + my @remotelist = $remote_heads ? git_get_heads_list(16, 'remotes') : ();
>>
>> Wasteful to run one for-each-ref for each list.
>>
>> You earlier introduced $ref_item{'class'} so that you can differenciate
>> what you got from git_get_heads_list(); make use of it, perhaps like:
>>
>> my @heads_list = git_get_heads_list(16, \%head_class);
>> my @headlist = grep { $_->{'class'} eq 'head' } @heads_list;
>> my @remotelist = grep { $_->{'class'} eq 'remote' } @heads_list;
>>
>> By the way, your [2/4] used "heads" and "remotes" as class, while your
>> [1/4] stored 'head' and 'remote' in $ref_item{'class'}. Notice the above
>> suggestion corrects this discrepancy as well.
>
> Although I agree with the head_class idea, I would like to point out
> that doing a single git call to retrieve all refs and then selecting
> the ones we want and doing multiple git calls are not equivalent.
>
> First of all, with multiple calls we can limit the calls to retrieve
> at most 16 refs of each kind, whereas this cannot be done with a
> single call for all the refs. I'm not sure however, performance-wise,
> if it's faster to filter the first 16 refs of each after retrieving
> all of them, or doing multiple calls, especially with lots of refs.
>
> Moreover, gitweb is already doing multiple for-each-ref calls to get
> tags and heads. I guess that at this point we could go the extra mile
> and include tags in the refs management. Of course, the problem of how
> to handle the rate limiting remains.
Sorry, replying to myself here. After more careful reading and some
more accurate testing, I gather that tags and heads management is
different enough to justify totally separate methods, and the cost of
an additional git call. It *could* still be merged (possibly with a
slightly different format string to accomodate both cases), but we
would have to do sorting ourselves, and such stuff. Not sure it's
worth it (yet).
My perplexity about rate limiting and separate calls for separate head
classes still remains, though.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Shawn O. Pearce @ 2008-11-17 15:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Christian Couder, Git Mailing List
In-Reply-To: <49211C19.5010409@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
>
> "Copy-rewrite", naturally. Being able to lift much of the data-munging code
> is a great benefit. It's basically just the revision traversal (which is
> heavy on state-dependant code) that I haven't quite figured out how to do
> yet, but I believe Shawn's idea of using revision pools is most likely the
> way to go. Each application has to make sure a pool isn't modified by more
> than one thread, but each application can have as many pools as it likes.
I also like Pierre's idea of using annotation data in different
annotation pools, and storing the rewritten parents in such a pool.
Then an application can more easily reuse a revision pool, by just
tossing the rewritten parent pool, or any other annotations it
wants to recompute.
It may still be important to have revision pools and make them
not thread-safe, so we can void fine-grained locking costs in
the library during the tight revision traversal loops.
--
Shawn.
^ permalink raw reply
* [PATCH 1/2 v2] Documentation: user-manual: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-17 15:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/user-manual.txt | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
Here is a new version of this patch series with the changes
from Junio.
Thanks,
Christian.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 645d752..c0d8caf 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -18,12 +18,22 @@ People needing to do actual development will also want to read
Further chapters cover more specialized topics.
Comprehensive reference documentation is available through the man
-pages. For a command such as "git clone <repo>", just use
+pages, or linkgit:git-help[1] command. For example, for the command
+"git clone <repo>", you can either use:
------------------------------------------------
$ man git-clone
------------------------------------------------
+or:
+
+------------------------------------------------
+$ git help clone
+------------------------------------------------
+
+With the latter, you can use the manual viewer of your choice; see
+linkgit:git-help[1] for more information.
+
See also <<git-quick-start>> for a brief overview of git commands,
without any explanation.
--
1.6.0.4.617.g621cb
^ permalink raw reply related
* [PATCH 2/2 v2] Documentation: tutorial: add information about "git help" at the beginning
From: Christian Couder @ 2008-11-17 15:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Also add a few links to git-help(1) in "See also" sections.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/gitcore-tutorial.txt | 1 +
Documentation/gittutorial-2.txt | 1 +
Documentation/gittutorial.txt | 10 ++++++++++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 61fc5d7..96bf353 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1693,6 +1693,7 @@ SEE ALSO
linkgit:gittutorial[7],
linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index bab0f34..a057b50 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -425,6 +425,7 @@ linkgit:gittutorial[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 384972c..7892244 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -26,6 +26,15 @@ First, note that you can get documentation for a command such as
$ man git-log
------------------------------------------------
+or:
+
+------------------------------------------------
+$ git help log
+------------------------------------------------
+
+With the latter, you can use the manual viewer of your choice; see
+linkgit:git-help[1] for more information.
+
It is a good idea to introduce yourself to git with your name and
public email address before doing any operation. The easiest
way to do so is:
@@ -653,6 +662,7 @@ linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
+linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
--
1.6.0.4.617.g621cb
^ permalink raw reply related
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Junio C Hamano @ 2008-11-17 16:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811150915240.3468@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>
>> This introduces make variable NO_PTHREADS for platforms that lack the
>> support for pthreads library or people who do not want to use it for
>> whatever reason. When defined, it makes the multi-threaded index
>> preloading into a no-op, and also disables threaded delta searching by
>> pack-objects.
>
> Ack. Makes sense.
Hmm, I started getting random segfaults that sometimes reproduces. For
example, this is what I just got from "git diff --stat $some_commit".
#0 0x00002b952568b090 in strlen () from /lib/libc.so.6
#1 0x000000000044ed42 in git_checkattr (path=0x2b95284b3970 "parse-options.c",
num=3, check=0x41000e90) at attr.c:512
#2 0x0000000000458921 in convert_to_git (
path=0x2b95284b3970 "parse-options.c",
src=0x2aaaaaabb000 <Address 0x2aaaaaabb000 out of bounds>, len=12594,
dst=0x41000f30, checksafe=SAFE_CRLF_FALSE) at convert.c:578
#3 0x0000000000489ac3 in index_mem (
sha1=0x41000ff0 "\210f�⽡x�\207�� 7R}\217\032��", buf=0x2aaaaaabb000,
size=12594, write_object=0, type=<value optimized out>,
path=0x2f2f2f2f2f2f2f2f <Address 0x2f2f2f2f2f2f2f2f out of bounds>)
at sha1_file.c:2451
#4 0x0000000000489c3d in index_fd (
sha1=0x41000ff0 "\210f�⽡x�\207�� 7R}\217\032��", fd=5,
st=<value optimized out>, write_object=0, type=OBJ_BLOB,
path=0x2b95284b3970 "parse-options.c") at sha1_file.c:2483
#5 0x000000000047857a in ce_modified_check_fs (ce=0x2b95284b3930,
st=0x41001080) at read-cache.c:92
#6 0x00000000004786a2 in ie_match_stat (istate=0x71c860, ce=0x2b95284b3930,
st=0x41001080, options=<value optimized out>) at read-cache.c:282
#7 0x0000000000497e65 in preload_thread (_data=<value optimized out>)
at preload-index.c:46
#8 0x00002b9525964017 in start_thread () from /lib/libpthread.so.0
#9 0x00002b95256da5bd in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
I suspect that the callpath around ce_modified_check_fs() uses a buffer
obtained from path.c:get_pathname() and parallel threads stomp on each
other, but I do not have time to debug this right now (I will be on a
14-hour flight in a few hours).
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Junio C Hamano @ 2008-11-17 16:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811150915240.3468@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>
>> This introduces make variable NO_PTHREADS for platforms that lack the
>> support for pthreads library or people who do not want to use it for
>> whatever reason. When defined, it makes the multi-threaded index
>> preloading into a no-op, and also disables threaded delta searching by
>> pack-objects.
>
> Ack. Makes sense.
Hmm, I started getting random segfaults that sometimes reproduce. For
example, this is what I just got from "git diff --stat $some_commit".
#0 0x00002b952568b090 in strlen () from /lib/libc.so.6
#1 0x000000000044ed42 in git_checkattr (path=0x2b95284b3970 "parse-options.c",
num=3, check=0x41000e90) at attr.c:512
#2 0x0000000000458921 in convert_to_git (
path=0x2b95284b3970 "parse-options.c",
src=0x2aaaaaabb000 <Address 0x2aaaaaabb000 out of bounds>, len=12594,
dst=0x41000f30, checksafe=SAFE_CRLF_FALSE) at convert.c:578
#3 0x0000000000489ac3 in index_mem (
sha1=0x41000ff0 "\210f�⽡x�\207�� 7R}\217\032��", buf=0x2aaaaaabb000,
size=12594, write_object=0, type=<value optimized out>,
path=0x2f2f2f2f2f2f2f2f <Address 0x2f2f2f2f2f2f2f2f out of bounds>)
at sha1_file.c:2451
#4 0x0000000000489c3d in index_fd (
sha1=0x41000ff0 "\210f�⽡x�\207�� 7R}\217\032��", fd=5,
st=<value optimized out>, write_object=0, type=OBJ_BLOB,
path=0x2b95284b3970 "parse-options.c") at sha1_file.c:2483
#5 0x000000000047857a in ce_modified_check_fs (ce=0x2b95284b3930,
st=0x41001080) at read-cache.c:92
#6 0x00000000004786a2 in ie_match_stat (istate=0x71c860, ce=0x2b95284b3930,
st=0x41001080, options=<value optimized out>) at read-cache.c:282
#7 0x0000000000497e65 in preload_thread (_data=<value optimized out>)
at preload-index.c:46
#8 0x00002b9525964017 in start_thread () from /lib/libpthread.so.0
#9 0x00002b95256da5bd in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
Unfortunately, I do not have time to debug this right now (I will be on a
14-hour flight in a few hours).
^ permalink raw reply
* Re: [PATCH 2/3] git-remote: add verbose mode to git remote update
From: Junio C Hamano @ 2008-11-17 16:46 UTC (permalink / raw)
To: crquan; +Cc: git
In-Reply-To: <1226920551-28303-2-git-send-email-crquan@gmail.com>
crquan@gmail.com writes:
> From: Cheng Renquan <crquan@gmail.com>
>
> Pass the verbose mode parameter to the underlying fetch command.
>
> $ ./git remote -v update
> Updating origin
> From git://git.kernel.org/pub/scm/git/git
> = [up to date] html -> origin/html
> ...
> - "git remote update [group]",
> + "git remote update [-v | --verbose] [group]",
> NULL
> };
Hmm, ok. I do not think "git remote update -v" would work, though.
> @@ -40,9 +40,13 @@ static int opt_parse_track(const struct option *opt, const char *arg, int not)
> return 0;
> }
>
> -static int fetch_remote(const char *name)
> +static int fetch_remote(const char *name, const char *url)
> {
> - const char *argv[] = { "fetch", name, NULL };
> + const char *argv[] = { "fetch", name, NULL, NULL };
> + if (verbose) {
> + argv[1] = "-v";
> + argv[2] = name;
> + }
> printf("Updating %s\n", name);
> if (run_command_v_opt(argv, RUN_GIT_CMD))
> return error("Could not fetch %s", name);
I do not think this new parameter "url" is used anywhere in this function;
please drop the change in the function signature. That would make your
change to "add()", "get_one_remote_for_update()", and "update()" all
unnecessary.
> @@ -769,8 +773,12 @@ static int prune(int argc, const char **argv)
> static int get_one_remote_for_update(struct remote *remote, void *priv)
> {
> struct string_list *list = priv;
> +
> if (!remote->skip_default_update)
> - string_list_append(xstrdup(remote->name), list);
> + string_list_append(remote->name, list)->util =
> + remote->url_nr > 0
> + ? (void *)remote->url[remote->url_nr-1] : NULL;
> +
> return 0;
> }
>
I notice that you dropped xstrdup() without explanation. While I think it
is a valid leak fix, that should be done as a separate commit (shown
below).
By the way, you fixed mismatch between the documentation and usage string
in an earlier patch, but you broke it yourself ;-). Please fix it up.
Thanks.
-- >8 --
Subject: builtin-remote.c: plug a small memory leak in get_one_remote_for_updates()
We know that the string pointed at by remote->name won't change. It can
be borrowed as the key in the string_list without copying. Other parts of
existing code such as get_one_entry() already rely on this fact.
Noticed by Cheng Renquan.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index d032f25..14774e3 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -770,7 +770,7 @@ static int get_one_remote_for_update(struct remote *remote, void *priv)
{
struct string_list *list = priv;
if (!remote->skip_default_update)
- string_list_append(xstrdup(remote->name), list);
+ string_list_append(remote->name, list);
return 0;
}
--
1.6.0.4.772.g2ebfe
^ permalink raw reply related
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Linus Torvalds @ 2008-11-17 16:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vvdumwbnn.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Nov 2008, Junio C Hamano wrote:
>
> I suspect that the callpath around ce_modified_check_fs() uses a buffer
> obtained from path.c:get_pathname() and parallel threads stomp on each
> other, but I do not have time to debug this right now (I will be on a
> 14-hour flight in a few hours).
Oh, damn. I had forgotten that check_fs() doesn't just do a "lstat()" any
more. You're right.
Let me look at it.
Linus
^ permalink raw reply
* Re: [PATCH 3/3] git-remote: simplifying get_one_entry
From: Junio C Hamano @ 2008-11-17 16:48 UTC (permalink / raw)
To: crquan; +Cc: git
In-Reply-To: <1226920551-28303-3-git-send-email-crquan@gmail.com>
crquan@gmail.com writes:
> From: Cheng Renquan <crquan@gmail.com>
>
> The loop for remote->url_nr is really useless, set to the last one
> directly is better.
Is it really useless? Be more descriptive.
> - if (remote->url_nr > 0) {
> - int i;
> -
> - for (i = 0; i < remote->url_nr; i++)
> - string_list_append(remote->name, list)->util = (void *)remote->url[i];
> - } else
> - string_list_append(remote->name, list)->util = NULL;
> + string_list_append(remote->name, list)->util =
> + remote->url_nr > 0
> + ? (void *)remote->url[remote->url_nr-1] : NULL;
When you have more than one URL associated with the remote (this makes
sense only for pushing), the current code adds that many string_list_item
to the list, each holding the URL. "git remote -v" shows all of them.
Your change instead creates only one string_list_item and hold the last
URL. Doesn't it make show_all() to show only one URL for the remote?
^ permalink raw reply
* Fix index preloading for racy dirty case
From: Linus Torvalds @ 2008-11-17 17:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811170846390.3468@nehalem.linux-foundation.org>
In the threaded index preloading case, we must be sure to always use the
CE_MATCH_RACY_IS_DIRTY flag when calling ie_match_stat(), in order to make
sure that we only ever look at the stat() data, and don't try to do
anything fancy.
Because most of git internals are not thread-safe, and must not be called
in parallel.
Otherwise, what happens is that if the timestamps indicate that an entry
_might_ be dirty, we might start actually comparing filesystem data with
the object database. And we mustn't do that, because that would involve
looking up and creating the object structure, and that whole code sequence
with read_sha1_file() where we look up and add objects to the hashes is
definitely not thread-safe.
Nor do we want to add locking, because the whole point of the preload was
to be simple and not affect anything else. With CE_MATCH_RACY_IS_DIRTY, we
get what we wanted, and we'll just leave the hard cases well alone, to be
done later in the much simpler serial case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
On Mon, 17 Nov 2008, Linus Torvalds wrote:
>
> Oh, damn. I had forgotten that check_fs() doesn't just do a "lstat()" any
> more. You're right.
Never mind the "any more". I don't think it ever did.
But I do think that this is trivially fixed, and I should have thought
about it. And while I didn't reproduce your SIGSEGV, I think this trivial
patch should fix it.
Sorry about the mindfart.
preload-index.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/preload-index.c b/preload-index.c
index 3ce42e0..a6a6bdb 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -43,7 +43,7 @@ static void *preload_thread(void *_data)
continue;
if (lstat(ce->name, &st))
continue;
- if (ie_match_stat(index, ce, &st, 0))
+ if (ie_match_stat(index, ce, &st, CE_MATCH_RACY_IS_DIRTY))
continue;
ce_mark_uptodate(ce);
} while (--nr > 0);
^ permalink raw reply related
* git-bisect not working correctly in the kvm.git repository?
From: walt @ 2008-11-17 17:27 UTC (permalink / raw)
To: git
I'm trying to find a bug introduced somewhere between kvm-69
and kvm-70, so of course I want to git-bisect down to it.
The weirdness is that when I give git-bisect the good and
bad tags, almost everything in my working directory just
disappears, leaving only the qemu subdirectory behind.
Can anyone else reproduce this with the kvm.git repo?
(I don't see this problem with the linux.git repo or the
git.git repo, so it seems to be something with the kvm.git
repo itself.)
Thanks!
^ permalink raw reply
* Re: git-bisect not working correctly in the kvm.git repository?
From: Linus Torvalds @ 2008-11-17 19:34 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <gfs9hn$hq9$1@ger.gmane.org>
On Mon, 17 Nov 2008, walt wrote:
>
> I'm trying to find a bug introduced somewhere between kvm-69
> and kvm-70, so of course I want to git-bisect down to it.
>
> The weirdness is that when I give git-bisect the good and
> bad tags, almost everything in my working directory just
> disappears, leaving only the qemu subdirectory behind.
Have you done subdirectory merges or other odd merges?
If you merge stuff from another project that isn't a full repository, then
you are merging commits that simply don't _have_ the full tree of your
repo. If you then bisect into those commits, the checkout will then (of
course) end up having only the files that are in that partial tree.
This will happen in the git repository too, if "git bisect" ends up
jumping into one of the commits that were done in the 'gitk' repository.
For an example of this, do something like
git clean -dqfx
git checkout -b oddbranch eb33a67f218b612f6fb1456e19b40a1f97ff02c0
in the git repository, and see all files disappear, and gitk is no longer
in the 'gitk-git' subdirectory, but got moved to the top level.
Because in the history that is that commit, that is literally how things
were. The data from that commit just got merged into a subdirectory of its
own, and together with all the rest of git, by using a subtree merge.
Linus
^ permalink raw reply
* Re: git-bisect not working correctly in the kvm.git repository?
From: Christian Couder @ 2008-11-17 19:47 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <gfs9hn$hq9$1@ger.gmane.org>
Le lundi 17 novembre 2008, walt a écrit :
> I'm trying to find a bug introduced somewhere between kvm-69
> and kvm-70, so of course I want to git-bisect down to it.
>
> The weirdness is that when I give git-bisect the good and
> bad tags, almost everything in my working directory just
> disappears, leaving only the qemu subdirectory behind.
>
> Can anyone else reproduce this with the kvm.git repo?
> (I don't see this problem with the linux.git repo or the
> git.git repo, so it seems to be something with the kvm.git
> repo itself.)
I cannot reproduce this:
$ git bisect start kvm-70 kvm-69
Bisecting: 846 revisions left to test after this
[80bfc25f42db6d4715c7688ae2352c5a8038fe7e] ntfs: le*_add_cpu conversion
$ find . -type f |wc -l
24286
$ git bisect reset
Previous HEAD position was 80bfc25... ntfs: le*_add_cpu conversion
Switched to branch "master"
$ find . -type f |wc -l
24384
Could you give more information, like your git version and the result of the
above commands?
Thanks,
Christian.
^ 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