* 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] 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
* [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
* [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
* 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
* 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: [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: 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: [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
* [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
* [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 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
* 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
* 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: 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: 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] 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: [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: fix encode handling for site_{header,footer}
From: Jakub Narebski @ 2008-11-17 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tatsuki Sugiura, git, Gerrit Pape, Recai Oktaş
In-Reply-To: <7v8wrizlxo.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Nov 2008, Junio C Hamano wrote:
> Tatsuki Sugiura <sugi@nemui.org> writes:
>
> > All non-ASCII chars of site_{header,footer} will be broken
> > by perl IO layer without decoding to utf8.
> >
> > Here is a fix to just call to_utf8 for inputs from these files.
> >
> > Signed-off-by: Tatsuki Sugiura <sugi@nemui.org>
>
> Looks good, thanks.
Hmmm... it is good _partial_ solution. I wonder if gitweb doesn't
have the same problem with per-project README.html file...
> > ---
> > gitweb/gitweb.perl | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 933e137..79ca5c2 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -2929,7 +2929,7 @@ EOF
> >
> > if (-f $site_header) {
> > open (my $fd, $site_header);
> > - print <$fd>;
> > + print map {to_utf8($_)} <$fd>;
> > close $fd;
> > }
> >
> > @@ -3018,7 +3018,7 @@ sub git_footer_html {
> >
> > if (-f $site_footer) {
> > open (my $fd, $site_footer);
> > - print <$fd>;
> > + print map {to_utf8($_)} <$fd>;
> > close $fd;
> > }
> >
> > --
> > 1.5.6.5
There was some patch by Recai Oktaş, or Gerrit Pape (or me)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4c104d2..8b5fcc1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -16,7 +16,7 @@ use Encode;
use Fcntl ':mode';
use File::Find qw();
use File::Basename qw(basename);
-binmode STDOUT, ':utf8';
+use open qw(:std :utf8);
BEGIN {
CGI->compile() if $ENV{'MOD_PERL'};
Then to_utf8() wouldn't be necessary. But I'd like for Perl experts to
check it first; for example this doesn't allow $fallback_encoding.
--
Jakub Narębski
Poland
^ permalink raw reply related
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-17 10:37 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1226776980-9674-1-git-send-email-tuncer.ayaz@gmail.com>
Junio,
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?
--- 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] Makefile: introduce NO_PTHREADS
From: Johannes Sixt @ 2008-11-17 10:34 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Junio C Hamano, Git Mailing List, Linus Torvalds
In-Reply-To: <e2b179460811170203v41e54ecclc3d6526bcc0fe928@mail.gmail.com>
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.)
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
-- Hannes
^ permalink raw reply related
* Re: [PATCH] request-pull: make usage string match manpage
From: Junio C Hamano @ 2008-11-17 10:28 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git
In-Reply-To: <1226912239-7248-1-git-send-email-stefan.naewe@atlas-elektronik.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: fix encode handling for site_{header,footer}
From: Junio C Hamano @ 2008-11-17 10:28 UTC (permalink / raw)
To: Tatsuki Sugiura; +Cc: git, Jakub Narebski
In-Reply-To: <87vdumbxgc.wl@vaj-k-334-sugi.local.valinux.co.jp>
Tatsuki Sugiura <sugi@nemui.org> writes:
> All non-ASCII chars of site_{header,footer} will be broken
> by perl IO layer without decoding to utf8.
>
> Here is a fix to just call to_utf8 for inputs from these files.
>
> Signed-off-by: Tatsuki Sugiura <sugi@nemui.org>
Looks good, thanks.
> ---
> gitweb/gitweb.perl | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 933e137..79ca5c2 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2929,7 +2929,7 @@ EOF
>
> if (-f $site_header) {
> open (my $fd, $site_header);
> - print <$fd>;
> + print map {to_utf8($_)} <$fd>;
> close $fd;
> }
>
> @@ -3018,7 +3018,7 @@ sub git_footer_html {
>
> if (-f $site_footer) {
> open (my $fd, $site_footer);
> - print <$fd>;
> + print map {to_utf8($_)} <$fd>;
> close $fd;
> }
>
> --
> 1.5.6.5
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Junio C Hamano @ 2008-11-17 10:18 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Johannes Sixt, Git Mailing List, Linus Torvalds
In-Reply-To: <e2b179460811170203v41e54ecclc3d6526bcc0fe928@mail.gmail.com>
"Mike Ralphson" <mike.ralphson@gmail.com> writes:
> 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.
>
> I'll wait a little while to see if anyone else reports the same for
> other platforms and then submit a patch.
Thanks.
I expect to be slow this week til just before Thanksgiving, so the more
people we have to keep an eye on the areas they excel at, the better for
all of us and certainly it would help me a lot.
^ permalink raw reply
* Re: [PATCH 2/2] git-remote: add verbose mode
From: Junio C Hamano @ 2008-11-17 10:15 UTC (permalink / raw)
To: crquan; +Cc: git
In-Reply-To: <1226913150-26088-2-git-send-email-crquan@gmail.com>
crquan@gmail.com writes:
> From: Denis ChengRq <crquan@gmail.com>
>
> Signed-off-by: Cheng Renquan <crquan@gmail.com>
Your other one (I am assuming the other one is also from you) has "From:
Cheng Renquan <crquan@gmail.com>" and this is "From: Denis ChengRq
<crquan@gmail.com>". We'd prefer to keep the same person under a single
name in "git shortlog" list. Under which name do you want to be known?
Please describe in what sense this is "verbose", iow, what additional
information is added by this patch, in your proposed commit log message.
> @@ -40,10 +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 };
> - printf("Updating %s\n", name);
> + if (verbose)
> + printf("Updating %s (%s)\n", name, url);
Are you guaranteeing that url is not NULL at this point in the code?
If so how?
How does this "--verbose" command the users give "git remote" relate to
the "--verbose" option the underlying "git fetch" has? IOW, do you tell
"git fetch" to be verbose as well? If so, how? If not, why not?
^ 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