* [PATCH 2/3] diff/apply: cast variable in call to free()
From: Ævar Arnfjörð Bjarmason @ 2011-11-06 12:06 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jim Meyering, Fredrik Gustafsson,
Ævar Arnfjörð Bjarmason
In-Reply-To: <1320581184-4557-1-git-send-email-avarab@gmail.com>
Both of these free() calls are freeing a "const unsigned char (*)[20]"
type while free() expects a "void *". This results in the following
warning under clang 2.9:
builtin/diff.c:185:7: warning: passing 'const unsigned char (*)[20]' to parameter of type 'void *' discards qualifiers
free(parent);
^~~~~~
submodule.c:394:7: warning: passing 'const unsigned char (*)[20]' to parameter of type 'void *' discards qualifiers
free(parents);
^~~~~~~
This free()-ing without a cast was added by Jim Meyering to
builtin/diff.c in v1.7.6-rc3~4 and later by Fredrik Gustafsson in
submodule.c in v1.7.7-rc1~25^2.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
builtin/diff.c | 2 +-
submodule.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/diff.c b/builtin/diff.c
index 1118689..0fe638f 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -182,7 +182,7 @@ static int builtin_diff_combined(struct rev_info *revs,
hashcpy((unsigned char *)(parent + i), ent[i].item->sha1);
diff_tree_combined(parent[0], parent + 1, ents - 1,
revs->dense_combined_merges, revs);
- free(parent);
+ free((void *)parent);
return 0;
}
diff --git a/submodule.c b/submodule.c
index 0fd10a0..52cdcc6 100644
--- a/submodule.c
+++ b/submodule.c
@@ -391,7 +391,7 @@ static void commit_need_pushing(struct commit *commit, struct commit_list *paren
rev.diffopt.format_callback_data = needs_pushing;
diff_tree_combined(commit->object.sha1, parents, n, 1, &rev);
- free(parents);
+ free((void *)parents);
}
int check_submodule_needs_pushing(unsigned char new_sha1[20], const char *remotes_name)
--
1.7.6.3
^ permalink raw reply related
* [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member
From: Ævar Arnfjörð Bjarmason @ 2011-11-06 12:06 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jim Meyering, Fredrik Gustafsson,
Ævar Arnfjörð Bjarmason
In-Reply-To: <1320581184-4557-1-git-send-email-avarab@gmail.com>
Remove an "p->field < 0" comparison in grep.c that'll always be
false. In this case "p" is a "grep_pat" where "field" is defined as:
enum grep_header_field field;
And grep_header_field is in turn defined as:
enum grep_header_field {
GREP_HEADER_AUTHOR = 0,
GREP_HEADER_COMMITTER
};
Meaning that this comparison will always be false. This was spotted by
clang 2.9 which produced the following warning while compiling grep.c:
grep.c:330:16: warning: comparison of unsigned enum expression < 0 is always false [-Wtautological-compare]
if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field)
~~~~~~~~ ^ ~
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
grep.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/grep.c b/grep.c
index b29d09c..025d3f8 100644
--- a/grep.c
+++ b/grep.c
@@ -327,7 +327,7 @@ static struct grep_expr *prep_header_patterns(struct grep_opt *opt)
for (p = opt->header_list; p; p = p->next) {
if (p->token != GREP_PATTERN_HEAD)
die("bug: a non-header pattern in grep header list.");
- if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field)
+ if (GREP_HEADER_FIELD_MAX <= p->field)
die("bug: unknown header field %d", p->field);
compile_regexp(p, opt);
}
--
1.7.6.3
^ permalink raw reply related
* Re: [PATCH 0/3] Fix code issues spotted by clang
From: Ævar Arnfjörð Bjarmason @ 2011-11-06 12:33 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jim Meyering, Fredrik Gustafsson,
Ævar Arnfjörð Bjarmason, Martin Waitz,
Elijah Newren
In-Reply-To: <1320581184-4557-1-git-send-email-avarab@gmail.com>
On Sun, Nov 6, 2011 at 13:06, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> This series fixes some of the code issues raised by clang.
Out of curiosity I also compiled git on "Sun Studio 12 Update 1" on
ee6dfb2d83ba1b057943e705f707fa27e34e47f9 with this patch series
applied and it emits the following warnings, quoted below along with
my comments:
"pack-write.c", line 76: warning: name redefined by pragma
redefine_extname declared static: tmpfile
Presumably this means that we've imported the function tmpfile() and
Sun's CC doesn't like that we're creating a variable with that name.
"read-cache.c", line 761: warning: statement not reached
SunCC's brain is melting on this particularly clever piece of code:
goto inside;
for (;;) {
if (!c)
return 1;
if (is_dir_sep(c)) {
inside:
"sha1_file.c", line 2453: warning: name redefined by pragma
redefine_extname declared static: tmpfile
same tempfile issue.
"compat/../git-compat-util.h", line 4: warning: macro redefined:
_FILE_OFFSET_BITS
"compat/../git-compat-util.h", line 4: warning: macro redefined:
_FILE_OFFSET_BITS
Seems we're clashing with this:
$ grep -r '#define.*_FILE_OFFSET_BITS' /usr/include/
/usr/include/sys/feature_tests.h:#define _FILE_OFFSET_BITS 64
/usr/include/sys/feature_tests.h:#define _FILE_OFFSET_BITS 32
"xdiff/xutils.c", line 194: warning: statement not reached
This was added in b97e911643341cb31e6b97029b9ffd96fc675b1d as a
workaround on systems using glibc, should this even be run on Sun
libc? Martin?
Another clever bit of code blowing SunCC's brain:
if (flags & XDF_IGNORE_WHITESPACE) {
goto skip_ws;
while (i1 < s1 && i2 < s2) {
if (l1[i1++] != l2[i2++])
return 0;
skip_ws:
while (i1 < s1 && XDL_ISSPACE(l1[i1]))
i1++;
while (i2 < s2 && XDL_ISSPACE(l2[i2]))
i2++;
}
}
"fast-import.c", line 858: warning: name redefined by pragma
redefine_extname declared static: tmpfile
ditto tempfile issue.
"builtin/fast-export.c", line 54: warning: enum type mismatch: op "="
This seems to me to be a legitimate issue we introduced in
2d8ad46919213ebbd7bb72eb5b56cca8cc3ae07f, Elijah?
We're defining an enum like this:
static enum { ABORT, VERBATIM, WARN, STRIP } signed_tag_mode = ABORT;
static enum { ERROR, DROP, REWRITE } tag_of_filtered_mode = ABORT;
And then doing:
if (unset || !strcmp(arg, "abort"))
tag_of_filtered_mode = ABORT; <-- Line 54
else if (!strcmp(arg, "drop"))
tag_of_filtered_mode = DROP;
else if (!strcmp(arg, "rewrite"))
tag_of_filtered_mode = REWRITE;
Presumably that assignment should be "= ERROR".
"builtin/index-pack.c", line 175: warning: name redefined by
pragma redefine_extname declared static: tmpfile
ditto tempfile.
"vcs-svn/string_pool.c", line 11: warning: initializer will be
sign-extended: -1
"vcs-svn/string_pool.c", line 81: warning: initializer will be
sign-extended: -1
"vcs-svn/repo_tree.c", line 112: warning: initializer will be
sign-extended: -1
"vcs-svn/repo_tree.c", line 112: warning: initializer will be
sign-extended: -1
"test-treap.c", line 34: warning: initializer will be sign-extended: -1
All of these come down to assigning ~0 to an uint32_t variable, e.g.:
uint32_t token = ~0;
^ permalink raw reply
* Re: [PATCH] Introduce commit.verbose config option
From: SZEDER Gábor @ 2011-11-06 12:52 UTC (permalink / raw)
To: Fernando Vezzosi; +Cc: git
In-Reply-To: <20111105182339.27C069004A@inscatolati.net>
On Sat, Nov 05, 2011 at 07:07:35PM +0100, Fernando Vezzosi wrote:
> Enabling commit.verbose will make git commit behave as if --verbose was
> passed on the command line.
>
> Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com>
> Signed-off-by: Fernando Vezzosi <buccia@repnz.net>
> ---
> Documentation/config.txt | 3 +++
> builtin/commit.c | 4 ++++
> 2 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 5a841da..6826788 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -832,6 +832,9 @@ commit.template::
> "{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
> specified user's home directory.
>
> +commit.verbose::
> + A boolean to enable verbose mode like the --verbose flag does.
> +
I just tried out this patch, and found that setting commit.verbose to
true also affects git commit's behavior when invoked from scripts
where you can't pass --verbose to git commit. I.e. the diff to be
committed is shown for git revert, interactive rebase's reword or
squash commands, or during 'git rebase --continue' after resolving a
conflict. I think this should be mentioned both in the commit message
and in the documentation.
Anyway, I like this change because I have a somewhat convoluted and
flaky combination of hooks and editor scripts to do the same, and now
I can finally get rid of them.
Best,
Gábor
^ permalink raw reply
* Re: [PATCH] grep: detect number of CPUs for thread spawning
From: Pete Wyckoff @ 2011-11-06 14:50 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Eric Herman, Sverre Rabbelier,
Fernando Vezzosi
In-Reply-To: <1320502568-14085-1-git-send-email-avarab@gmail.com>
avarab@gmail.com wrote on Sat, 05 Nov 2011 14:16 +0000:
> From: Eric Herman <eric@freesa.org>
>
> Change the number of threads that we spawn from a hardcoded value of
> "8" to what online_cpus() returns.
>
> Back in v1.7.0-rc1~19^2 when threaded grep was introduced the number
> of threads was hardcoded at compile time to 8, but this value was only
> used if online_cpus() returned greater than 1.
>
> However just using 8 threads regardless of the actual number of CPUs
> is inefficient if we have more than 8 CPUs, and potentially wasteful
> if we have fewer than 8 CPUs.
I agree with the need to exploit >8 CPUs, but I lose a lot of
performance when limiting the threads to the number of physical
CPUs.
Tests without your patch on master, just changing "#define
THREADS" from 8 to 2. On a 2-core Intel Core2 Duo.
Producing lots of output:
8 threads:
$ time ~/u/src/git/bin-wrappers/git grep f > /dev/null
0m14.02s user 0m3.64s sys 0m11.93s elapsed 148.07 %CPU
$ time ~/u/src/git/bin-wrappers/git grep f > /dev/null
0m13.86s user 0m3.70s sys 0m11.82s elapsed 148.57 %CPU
2 threads:
$ time ~/u/src/git/bin-wrappers/git grep f > /dev/null
0m15.14s user 0m3.52s sys 0m24.22s elapsed 77.05 %CPU
$ time ~/u/src/git/bin-wrappers/git grep f > /dev/null
0m14.85s user 0m3.79s sys 0m24.20s elapsed 77.05 %CPU
Producing no output:
8 threads:
$ time ~/u/src/git/bin-wrappers/git grep unfindable-string
0m1.14s user 0m3.68s sys 0m5.17s elapsed 93.22 %CPU
$ time ~/u/src/git/bin-wrappers/git grep unfindable-string
0m1.28s user 0m3.56s sys 0m5.15s elapsed 94.22 %CPU
2 threads:
$ time ~/u/src/git/bin-wrappers/git grep unfindable-string
0m1.36s user 0m3.64s sys 0m16.82s elapsed 29.75 %CPU
$ time ~/u/src/git/bin-wrappers/git grep unfindable-string
0m1.38s user 0m3.66s sys 0m16.81s elapsed 30.04 %CPU
My workdir is on NFS, where even though the repository is fully
cached, the open()s must go to the server. Using more threads
than CPUs makes it more likely that some thread isn't blocked.
You could add a #threads knob, but then we'd have to get
everybody on NFS to set that properly. Or take a look at
preload_index() to see how it guesses at how many threads it
needs.
-- Pete
^ permalink raw reply
* Re: [PATCH 3/3] grep: get rid of useless x < 0 comparison on an enum member
From: Andreas Schwab @ 2011-11-06 15:03 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Jim Meyering, Fredrik Gustafsson
In-Reply-To: <1320581184-4557-4-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Remove an "p->field < 0" comparison in grep.c that'll always be
> false. In this case "p" is a "grep_pat" where "field" is defined as:
>
> enum grep_header_field field;
>
> And grep_header_field is in turn defined as:
>
> enum grep_header_field {
> GREP_HEADER_AUTHOR = 0,
> GREP_HEADER_COMMITTER
> };
>
> Meaning that this comparison will always be false.
The underlying integer type is implementation-defined, and can be any
signed or unsigned integer type that can represent all enumerations.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* A Python script to put CTAN into git (from DVDs)
From: Jonathan Fine @ 2011-11-06 15:17 UTC (permalink / raw)
To: python-list; +Cc: git
Hi
This it to let you know that I'm writing (in Python) a script that
places the content of CTAN into a git repository.
https://bitbucket.org/jfine/python-ctantools
I'm working from the TeX Collection DVDs that are published each year by
the TeX user groups, which contain a snapshot of CTAN (about 100,000
files occupying 4Gb), which means I have to unzip folders and do a few
other things.
CTAN is the Comprehensive TeX Archive Network. CTAN keeps only the
latest version of each file, but old CTAN snapshots will provide many
earlier versions.
I'm working on putting old CTAN files into modern version control.
Martin Scharrer is working in the other direction. He's putting new
files added to CTAN into Mercurial.
http://ctanhg.scharrer-online.de/
My script works already as a proof of concept, but needs more work (and
documentation) before it becomes useful. I've requested that follow up
goes to comp.text.tex.
Longer terms goals are git as
* http://en.wikipedia.org/wiki/Content-addressable_storage
* a resource editing and linking system
If you didn't know, a git tree is much like an immutable JSON object,
except that it does not have arrays or numbers.
If my project interests you, reply to this message or contact me
directly (or both).
--
Jonathan
^ permalink raw reply
* Re: [PATCH] gc --auto: warn gc will soon run, give users a chance to run manually
From: Matthieu Moy @ 2011-11-06 16:37 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1320489212-524-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> + warning(_("Too many loose objects. \"git gc\" will soon run automatically"));
[...]
> + warning(_("Too many packs, \"git gc\" will soon run automatically."));
Nit: you have a period in the second message, but not for the first.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: A Python script to put CTAN into git (from DVDs)
From: Jakub Narebski @ 2011-11-06 16:42 UTC (permalink / raw)
To: Jonathan Fine; +Cc: python-list, git
In-Reply-To: <4EB6A522.3020909@pytex.org>
Jonathan Fine <jfine@pytex.org> writes:
> Hi
>
> This it to let you know that I'm writing (in Python) a script that
> places the content of CTAN into a git repository.
> https://bitbucket.org/jfine/python-ctantools
I hope that you meant "repositories" (plural) here, one per tool,
rather than putting all of CTAN into single Git repository.
> I'm working from the TeX Collection DVDs that are published each year
> by the TeX user groups, which contain a snapshot of CTAN (about
> 100,000 files occupying 4Gb), which means I have to unzip folders and
> do a few other things.
There is 'contrib/fast-import/import-zips.py' in git.git repository.
If you are not using it, or its equivalent, it might be worth checking
out.
> CTAN is the Comprehensive TeX Archive Network. CTAN keeps only the
> latest version of each file, but old CTAN snapshots will provide many
> earlier versions.
There was similar effort done in putting CPAN (Comprehensive _Perl_
Archive Network) in Git, hosting repositories on GitHub[1], by the name
of gitPAN, see e.g.:
"The gitPAN Import is Complete"
http://perlisalive.com/articles/36
[1]: https://github.com/gitpan
> I'm working on putting old CTAN files into modern version
> control. Martin Scharrer is working in the other direction. He's
> putting new files added to CTAN into Mercurial.
> http://ctanhg.scharrer-online.de/
Nb. thanks to tools such as git-hg and fast-import / fast-export
we have quite good interoperability and convertability between
Git and Mercurial.
P.S. I'd point to reposurgeon tool, which can be used to do fixups
after import, but it would probably won't work on such large (set of)
repositories.
P.P.S. Can you forward it to comp.text.tex?
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH] grep: detect number of CPUs for thread spawning
From: Eric Herman @ 2011-11-06 18:00 UTC (permalink / raw)
To: Pete Wyckoff
Cc: Ævar Arnfjörð Bjarmason, git, Junio C Hamano,
Sverre Rabbelier, Fernando Vezzosi
In-Reply-To: <20111106145050.GA4219@arf.padd.com>
Hello Pete,
Thank you for the feedback.
On 11/06/2011 03:50 PM, Pete Wyckoff wrote:
>> From: Eric Herman<eric@freesa.org>
>>
>> Change the number of threads that we spawn from a hardcoded value of
>> "8" to what online_cpus() returns.
> I agree with the need to exploit>8 CPUs, but I lose a lot of
> performance when limiting the threads to the number of physical
> CPUs.
Ah, yes, Being focused on big machines, I did not actually test with low
CPU machines, certainly not with NFS mounts.
>
> Tests without your patch on master, just changing "#define
> THREADS" from 8 to 2. On a 2-core Intel Core2 Duo.
>
> Producing lots of output:
>
> 8 threads:
>
> $ time ~/u/src/git/bin-wrappers/git grep f> /dev/null
> 0m14.02s user 0m3.64s sys 0m11.93s elapsed 148.07 %CPU
> $ time ~/u/src/git/bin-wrappers/git grep f> /dev/null
> 0m13.86s user 0m3.70s sys 0m11.82s elapsed 148.57 %CPU
>
> 2 threads:
>
> $ time ~/u/src/git/bin-wrappers/git grep f> /dev/null
> 0m15.14s user 0m3.52s sys 0m24.22s elapsed 77.05 %CPU
> $ time ~/u/src/git/bin-wrappers/git grep f> /dev/null
> 0m14.85s user 0m3.79s sys 0m24.20s elapsed 77.05 %CPU
>
> Producing no output:
>
> 8 threads:
>
> $ time ~/u/src/git/bin-wrappers/git grep unfindable-string
> 0m1.14s user 0m3.68s sys 0m5.17s elapsed 93.22 %CPU
> $ time ~/u/src/git/bin-wrappers/git grep unfindable-string
> 0m1.28s user 0m3.56s sys 0m5.15s elapsed 94.22 %CPU
>
> 2 threads:
>
> $ time ~/u/src/git/bin-wrappers/git grep unfindable-string
> 0m1.36s user 0m3.64s sys 0m16.82s elapsed 29.75 %CPU
> $ time ~/u/src/git/bin-wrappers/git grep unfindable-string
> 0m1.38s user 0m3.66s sys 0m16.81s elapsed 30.04 %CPU
>
> My workdir is on NFS, where even though the repository is fully
> cached, the open()s must go to the server. Using more threads
> than CPUs makes it more likely that some thread isn't blocked.
This is good data.
It gives me ideas for how I can do some more testing.
>
> You could add a #threads knob,
Sure, adding a knob is not a bad idea.
> but then we'd have to get
> everybody on NFS to set that properly.
Indeed, I think you agree that it would be better if there was no need
for most people to fiddle with yet another knob.
> Or take a look at
> preload_index() to see how it guesses at how many threads it
> needs.
Good tip.
A quick peek at preload_index suggests that it was a bit of guesswork:
/*
* Mostly randomly chosen maximum thread counts: we
* cap the parallelism to 20 threads, and we want
* to have at least 500 lstat's per thread for it to
* be worth starting a thread.
*/
However, your comments make me wonder if a rule-of-thumb like "3 +
online_cpus()" would yield better results across both large and small
numbers of cores with either blazing fast or very slow storage.
I will create a setup similar to the one you describe and do some
exploration.
Cheers,
-Eric
--
http://www.freesa.org/ -- mobile: +31 620719662
aim: ericigps -- skype: eric_herman -- jabber: eric.herman@gmail.com
^ permalink raw reply
* Re: [PATCH v2] pull: introduce a pull.rebase option to enable --rebase
From: Junio C Hamano @ 2011-11-06 18:20 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Eric Herman, Sverre Rabbelier, Fernando Vezzosi,
Johannes Schindelin
In-Reply-To: <1320573010-12296-1-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> We all stood behind my laptop while I explained what it did and
> why. Sverre pointed out that I should use the test_when_finished()
> function for unsetting the config variables, Eric and Fernando looked
> it over as well.
Sounds like fun ;-)
Will re-queue. Thanks.
^ permalink raw reply
* Re: [PATCH na/strtoimax] Compatibility: declare strtoimax() under NO_STRTOUMAX
From: Ramsay Jones @ 2011-11-06 18:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nick Alcock, Junio C Hamano, Git Mailing List
In-Reply-To: <4EB56593.6090402@kdbg.org>
Johannes Sixt wrote:
> Am 05.11.2011 16:37, schrieb Johannes Sixt:
>> Commit f696543d (Add strtoimax() compatibility function) introduced an
>> implementation of the function, but forgot to add a declaration.
>
> On second thought, I'm puzzled: Without this patch and without noticing
> the warning that strtoimax() was not declared, I had built with
> NO_STRTOUMAX on MinGW before, and the build succeeded. This means that
> even though MinGW's headers are not C99, we must have pulled in function
> strtoimax() from somewhere. I'll investigate later this weekend.
Yes, I've noticed the same thing, viz:
ramsay (pu)$ find /mingw/include -type f | xargs egrep 'strto(imax|umax|ull)'
/mingw/include/inttypes.h:intmax_t __cdecl __MINGW_NOTHROW strtoimax (const char
* __restrict__ nptr,
/mingw/include/inttypes.h:uintmax_t __cdecl __MINGW_NOTHROW strtoumax (const cha
r* __restrict__ nptr,
/mingw/include/stdlib.h:unsigned long long __cdecl __MINGW_NOTHROW strtoull (co
nst char* __restrict__, char** __restrict__, int);
ramsay (pu)$ nm /mingw/lib/libmingwex.a | egrep 'strto(imax|umax|ull)'
strtoimax.o:
00000000 T _strtoimax
strtoumax.o:
00000000 T _strtoull
00000000 T _strtoumax
ramsay (pu)$
So, I assume, an earlier version of MinGW did not have the inttypes.h header
file and the NO_STRTOUMAX etc. settings are stale; dunno ;-)
In any event, I guess an '#include <inttypes.h>' on MinGW will be part of the
solution. [Without breaking the MSVC build, of course; see the NO_INTTYPES_H
make variable.] However, I haven't given it too much thought, so take that with
a bucket of salt!
Note, also, that very similar comments apply to NO_LIBGEN_H; viz:
ramsay (pu)$ find /mingw/include -type f | xargs egrep 'char \*(dir|base)name'
/mingw/include/libgen.h:extern __cdecl __MINGW_NOTHROW char *basename (char *);
/mingw/include/libgen.h:extern __cdecl __MINGW_NOTHROW char *dirname (char *);
ramsay (pu)$ nm /mingw/lib/libmingwex.a | egrep '(dir|base)name'
basename.o:
00000000 T _basename
dirname.o:
00000000 T _dirname
ramsay (pu)$
[having said that, I have a patch that adds a compat/dirname.c and modifies
the existing compat/basename.c; the MinGW dirname()/basename() functions
have problems.]
HTH
ATB,
Ramsay Jones
^ permalink raw reply
* Re: A Python script to put CTAN into git (from DVDs)
From: Jonathan Fine @ 2011-11-06 18:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: python-list, git
In-Reply-To: <mailman.2464.1320597747.27778.python-list@python.org>
On 06/11/11 16:42, Jakub Narebski wrote:
> Jonathan Fine<jfine@pytex.org> writes:
>
>> Hi
>>
>> This it to let you know that I'm writing (in Python) a script that
>> places the content of CTAN into a git repository.
>> https://bitbucket.org/jfine/python-ctantools
>
> I hope that you meant "repositories" (plural) here, one per tool,
> rather than putting all of CTAN into single Git repository.
There are complex dependencies among LaTeX macro packages, and TeX is
often distributed and installed from a DVD. So it makes sense here to
put *all* the content of a DVD into a repository.
Once you've done that, it is then possible and sensible to select
suitable interesting subsets, such as releases of a particular package.
Users could even define their own subsets, such as "all resources needed
to process this file, exactly as it processes on my machine".
In addition, many TeX users have a TeX DVD. If they import it into a
git repository (using for example my script) then the update from 2011
to 2012 would require much less bandwidth.
Finally, I'd rather be working within git that modified copy of the ISO
when doing the subsetting. I'm pretty sure that I can manage to pull
the small repositories from the big git-CTAN repository.
But as I proceed, perhaps I'll change my mind (smile).
>> I'm working from the TeX Collection DVDs that are published each year
>> by the TeX user groups, which contain a snapshot of CTAN (about
>> 100,000 files occupying 4Gb), which means I have to unzip folders and
>> do a few other things.
>
> There is 'contrib/fast-import/import-zips.py' in git.git repository.
> If you are not using it, or its equivalent, it might be worth checking
> out.
Well, I didn't know about that. I took a look, and it doesn't do what I
want. I need to walk the tree (on a mounted ISO) and unpack some (but
not all) zip files as I come across them. For details see:
https://bitbucket.org/jfine/python-ctantools/src/tip/ctantools/filetools.py
In addition, I don't want to make a commit. I just want to make a ref
at the end of building the tree. This is because I want the import of a
TeX DVD to give effectively identical results for all users, and so any
commit information would be effectively constant.
>> CTAN is the Comprehensive TeX Archive Network. CTAN keeps only the
>> latest version of each file, but old CTAN snapshots will provide many
>> earlier versions.
>
> There was similar effort done in putting CPAN (Comprehensive _Perl_
> Archive Network) in Git, hosting repositories on GitHub[1], by the name
> of gitPAN, see e.g.:
>
> "The gitPAN Import is Complete"
> http://perlisalive.com/articles/36
>
> [1]: https://github.com/gitpan
This is really good to know!!! Not only has this been done already, for
similar reasons, but github is hosting it. Life is easier when there is
a good example to follow.
>> I'm working on putting old CTAN files into modern version
>> control. Martin Scharrer is working in the other direction. He's
>> putting new files added to CTAN into Mercurial.
>> http://ctanhg.scharrer-online.de/
>
> Nb. thanks to tools such as git-hg and fast-import / fast-export
> we have quite good interoperability and convertability between
> Git and Mercurial.
>
> P.S. I'd point to reposurgeon tool, which can be used to do fixups
> after import, but it would probably won't work on such large (set of)
> repositories.
Thank you for the pointer to reposurgeon. My approach is a bit
different. First, get all the files into git, and then 'edit the tree'
to create new trees. And then commit worthwhile new trees.
As I recall the first 'commit' to the git repository for the Linux
kernel was just a tree, with a reference to that tree as a tag. But no
commit.
> P.P.S. Can you forward it to comp.text.tex?
Done.
--
Jonathan
^ permalink raw reply
* Re: [PATCH 1/3] apply: get rid of useless x < 0 comparison on a size_t type
From: Junio C Hamano @ 2011-11-06 18:35 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, Giuseppe Bilotta
Cc: git, Jim Meyering, Fredrik Gustafsson
In-Reply-To: <1320581184-4557-2-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> According to the C standard size_t is always unsigned, therefore the
> comparison "n1 < 0 || n2 < 0" when n1 and n2 are size_t will always be
> false.
>
> This was raised by clang 2.9 which throws this warning when compiling
> apply.c:
>
> builtin/apply.c:253:9: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
> if (n1 < 0 || n2 < 0)
> ~~ ^ ~
> builtin/apply.c:253:19: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
> if (n1 < 0 || n2 < 0)
> ~~ ^ ~
>
> This check was originally added in v1.6.5-rc0~53^2 by Giuseppe Bilotta
> while adding an option to git-apply to ignore whitespace differences.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
I agree that these quantities can never be negative, so I'll apply the
patch as is.
But I have this suspicion that this was a rather sloppy defensive check to
protect this codepath against potential breakage in another codepath (most
likely update_pre_post_images() touched by the same patch) that adjusts
image->line[].len the caller of this function uses to feed these two
parameters. Giuseppe may have been not confident enough that the code
added to that function ensures not to undershoot when it reduces "len", or
something.
Giuseppe, can you explain what is going on?
Thanks
> builtin/apply.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 84a8a0b..b3b59db 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -250,9 +250,6 @@ static int fuzzy_matchlines(const char *s1, size_t n1,
> const char *last2 = s2 + n2 - 1;
> int result = 0;
>
> - if (n1 < 0 || n2 < 0)
> - return 0;
> -
> /* ignore line endings */
> while ((*last1 == '\r') || (*last1 == '\n'))
> last1--;
^ permalink raw reply
* Re: [PATCH 5/5] sequencer: revert d3f4628e
From: Junio C Hamano @ 2011-11-06 19:10 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, Git List, Christian Couder
In-Reply-To: <20111106004257.GG27272@elie.hsd1.il.comcast.net>
Thanks for detailed reviews, Jonathan; looking forward for a re-roll, as I
think the general direction the series seems to be aiming to go is good.
^ permalink raw reply
* Re: [PATCH] Add abbreviated commit hash to rebase conflict message
From: Sverre Rabbelier @ 2011-11-06 19:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð, Jonas Flodén, Eric Herman,
Fernando Vezzosi, Git List
In-Reply-To: <7vy5vt7uqo.fsf@alter.siamese.dyndns.org>
Heya,
On Sun, Nov 6, 2011 at 05:14, Junio C Hamano <gitster@pobox.com> wrote:
> I am puzzled, but that cannot be true. The existing message uses $msgnum
> and $FIRSTLINE but does not use $commit because it does not necessarily
> exist.
>
> What a value would the variable contain when I am applying your original
> patch message using "git am -s" (or "git am -s3")?
Aaah, I understand the concern you raise now. In that case a spurious
[] would be printed, which I agree is less than desirable. Would
checking 'if test -n $commit' be sufficient?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Sverre Rabbelier @ 2011-11-06 19:38 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov, Johannes Schindelin,
Ævar Arnfjörð, Eric Herman, Fernando Vezzosi
In-Reply-To: <20111106043157.GM27272@elie.hsd1.il.comcast.net>
Heya,
On Sun, Nov 6, 2011 at 05:31, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> This happens only when the corresponding commits are not exported in
>> the current fast-export run. This can happen either when the relevant
>> commit is already marked, or when the commit is explicitly marked
>> as UNINTERESTING with a negative ref by another argument.
>
> The above "This" has no antecedent. I guess you mean that
> fast-export writes no output when passed a range of the form A..A.
Well, it's referring to the subject, how about:
"When a commit has not been exported in the current fast-export run
its ref is not updated correctly. This can happen ...".
>> as they use marks
>> files to store which commits have already been seen. The call graph
>> is something as follows:
>>
>> $ # push master to remote repo
>> $ git fast-export --{im,ex}port-marks=marksfile master
>> $ # make a commit on master and push it to remote
>> $ git fast-export --{im,ex}port-marks=marksfile master
>> $ # run `git branch foo` and push it to remote
>> $ git fast-export --{im,ex}port-marks=marksfile foo
>>
>> When fast-export imports the marksfile and sees that all commits in
>> foo are marked as UNINTERESTING
>
> Hmm, I didn't know about this behavior. Would it be possible to add
> a test for it, too?
What behavior are you referring to here? What kind of test would you want added?
>> t/t9350-fast-export.sh | 11 +++++++++++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> With or without the change suggested above, this new test seems to me
> like a good thing, even though in the longer term it might be nicer to
> teach fast-export to understand a syntax like
>
> git fast-import ^master master:master
>
> Put another way, the possibility of something nicer later shouldn't
> stop us from adding an incremental refinement that improves things
> today.
Yes, extending the capabilities of fast-export is needed if we want
the remote-helpers to be as powerful as native git.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/3] fast-export: do not refer to non-existing marks
From: Sverre Rabbelier @ 2011-11-06 19:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov, Johannes Schindelin,
Ævar Arnfjörð, Eric Herman, Fernando Vezzosi
In-Reply-To: <20111106044514.GN27272@elie.hsd1.il.comcast.net>
Heya,
On Sun, Nov 6, 2011 at 05:45, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Extract a handle_reset function that deals with this, which can then
>> be re-used in a later commit.
>
> So, does this patch drop the confusing behavior and add one that is
> more intuitive for remote helpers? It's not clear from this
> description what sort of deal the patch makes and whether it is a good
> or bad one.
Ah, yes. Perhaps something like:
"Extract a reset_ref function that deals with this situation by
printing the commit sha1 when no mark has been written yet."
> Ah --- the functional change is to use a sha1 when there is no mark
> corresponding to the object.
>
> Why is this codepath being run at all when b is excluded by the
> revision range (a..a a = ^a a a)? Is this the same bug tested
> for in patch 1/3 or something separate?
I must admit that I don't recall how exactly we stumbled on this case.
It might even make sense to instead die when we run into this corner
case, but I'm not convinced that there's no valid use case for this
(which we would block by die-ing).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Sverre Rabbelier @ 2011-11-06 19:48 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov, Johannes Schindelin,
Ævar Arnfjörð, Eric Herman, Fernando Vezzosi
In-Reply-To: <20111106050126.GO27272@elie.hsd1.il.comcast.net>
Heya,
On Sun, Nov 6, 2011 at 06:01, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Thanks. I'd suggest squashing in the test from patch 1/3 for easy
> reference (since each patch makes the other easier to understand).
Yes, agreed. The initial series was 5 patches in total, but splitting
it out for such a small series (and small patch at that) makes less
sense.
> These details seem like good details for the commit message, so the
> next puzzled person looking at the code can see what behavior is
> deliberate and what are the incidental side-effects.
All of it? I wasn't sure what part should go in the commit message.
> The "git fast-export a..$(git rev-parse HEAD^{commit})" case sounds
> worth a test.
A test_must_fail?
>> +#define REF_HANDLED (ALL_REV_FLAGS + 1)
>
> Could TMP_MARK be used for this?
I don't know its usage, is it?
> -static void handle_tags_and_duplicates(struct string_list *extra_refs)
>> +static void handle_tags_and_duplicates(struct rev_info *revs, struct string_list *extra_refs)
>> {
>> int i;
>>
>> + /* even if no commits were exported, we need to export the ref */
>> + for (i = 0; i < revs->cmdline.nr; i++) {
>
> Might be clearer in a new function.
Yes, probably. handle_cmdline_refs?
>> + struct rev_cmdline_entry *elem = &revs->cmdline.rev[i];
>> +
>> + if (elem->flags & UNINTERESTING)
>> + continue;
>> +
>> + if (elem->whence != REV_CMD_REV && elem->whence != REV_CMD_RIGHT)
>> + continue;
>
> Oh, neat.
Yes, I must admit that this bit was easier than I dreaded it would be
(I must admit that's been a large reason that I haven't taken the time
to work on this till now). With the fast-export and remote-helper
tests to guide me, I was able to code-by-accident the right conditions
here :).
>> +
>> + char *full_name;
>
> declaration-after-statement
Ah, yes.
>> + dwim_ref(elem->name, strlen(elem->name), elem->item->sha1, &full_name);
>> +
>> + if (!prefixcmp(full_name, "refs/tags/") &&
>
> What happens if dwim_ref fails, perhaps because a ref was deleted in
> the meantime?
That would be bad. I assumed that we have a lock on the refs, should I
add back the die check that's done by the other dwim_ref caller?
>> + (tag_of_filtered_mode != REWRITE ||
>> + !get_object_mark(elem->item)))
>> + continue;
>
> Style nit: this would be easier to read if the "if" condition doesn't
> line up with the code below it:
>
> if (!prefixcmp(full_name, "refs/tags/")) {
> if (tag_of_filtered_mode != REWRITE ||
> !get_object_mark(elem->item))
> continue;
> }
Yeah, that does look better :).
> If tag_of_filtered_mode == ABORT, we are going to die() soon, right?
I don't know to be honest, perhaps we would have already died by now?
I don't know the details of how the tag_of_filtered_mode part is
implemented.
> So this seems to be about tag_of_filtered_mode == DROP --- makes
> sense.
>
> When does the !get_object_mark() case come up?
Eh, it has something to do with it being a replacement (rather than
the same), maybe? This is mostly just taken from Dscho's original
patch.
>> + if (!(elem->flags & REF_HANDLED)) {
>> + handle_reset(full_name, elem->item);
>> + elem->flags |= REF_HANDLED;
>> + }
>
> Just curious: is the REF_HANDLED handling actually needed? What
> would happen if fast-export included the redundant resets?
That would just be sloppy :). I don't think anything particularly bad
would happen.
> Thanks for a pleasant read.
Thanks for the review.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2] pull: introduce a pull.rebase option to enable --rebase
From: Johannes Sixt @ 2011-11-06 19:53 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Eric Herman, Sverre Rabbelier,
Fernando Vezzosi, Johannes Schindelin
In-Reply-To: <1320573010-12296-1-git-send-email-avarab@gmail.com>
Am 06.11.2011 10:50, schrieb Ævar Arnfjörð Bjarmason:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 5a841da..b2d7d92 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -677,7 +677,9 @@ branch.<name>.mergeoptions::
> branch.<name>.rebase::
> When true, rebase the branch <name> on top of the fetched branch,
> instead of merging the default branch from the default remote when
> - "git pull" is run.
> + "git pull" is run. See "pull.rebase" for doing this in a non
> + branch-specific manner.
> +
> *NOTE*: this is a possibly dangerous operation; do *not* use
> it unless you understand the implications (see linkgit:git-rebase[1]
> for details).
When you continue an indented item in a separate paragraph, then you
must not use an empty line, but have line with '+' and un-indented
continuation paragraphs. See examples in this file.
-- Hannes
^ permalink raw reply
* What's cooking in git.git (Nov 2011, #02; Sun, 6)
From: Junio C Hamano @ 2011-11-06 20:17 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
I was planning to tag -rc1 over the weekend, but will let it slip for a
few days, as a couple of regression fixes came in that I'd like to have
in it. They are in 'next' in today's integration result.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches but not todo, html or man:
https://github.com/gitster/git
I will stop pushing the generated documentation branches to the above
repositories, as they are not sources. The only reason the source
repository at k.org has hosted these branches was because it was the only
repository over there that was writable by me; it was an ugly historical
and administrative workaround and not a demonstration of the best
practice.
These branches are pushed to their own separate repositories instead:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* jc/pull-signed-tag (2011-11-04) 10 commits
- merge: force edit mode when merging a tag object
- fmt-merge-msg: Add contents of merged tag in the merge message
- fmt-merge-msg: package options into a structure
- fmt-merge-msg: avoid early returns
- refs DWIMmery: use the same rule for both "git fetch" and others
- tests: distinguish merges of tags and commits
- fetch: allow "git fetch $there v1.0" to fetch a tag
- merge: notice local merging of tags and keep it unwrapped
- fetch: do not store peeled tag object names in FETCH_HEAD
- Split GPG interface into its own helper library
Fourth round but needs further updates.
Will keep in 'pu' for now.
* sn/http-auth-with-netrc-fix (2011-11-04) 1 commit
(merged to 'next' on 2011-11-06 at 60b7f96)
+ http: don't always prompt for password
Regression fix for the upcoming release.
Will merge by 1.7.8 final.
* ab/clang-lints (2011-11-06) 2 commits
- cast variable in call to free() in builtin/diff.c and submodule.c
- apply: get rid of useless x < 0 comparison on a size_t type
Not urgent.
* ab/i18n-test-fix (2011-11-05) 2 commits
(merged to 'next' on 2011-11-06 at f1de9a6)
+ t/t7508-status.sh: use test_i18ncmp
+ t/t6030-bisect-porcelain.sh: use test_i18ngrep
Will merge by 1.7.8 final.
* ab/pull-rebase-config (2011-11-06) 1 commit
- pull: introduce a pull.rebase option to enable --rebase
Not urgent.
* eh/grep-scale-to-cpunum (2011-11-05) 1 commit
- grep: detect number of CPUs for thread spawning
Kills I/O parallelism and needs to be improved or discarded.
* nd/fsck-progress (2011-11-05) 4 commits
- fsck: print progress
- fsck: avoid reading every object twice
- Stop verify_packfile() as soon as an error occurs
- fsck: return error code when verify_pack() goes wrong
Not urgent.
* nd/prune-progress (2011-11-05) 1 commit
- prune: show progress while marking reachable objects
Not urgent.
* pw/p4-appledouble-fix (2011-11-05) 1 commit
(merged to 'next' on 2011-11-06 at 2ec0af3)
+ git-p4: ignore apple filetype
Regression fix for the upcoming release.
Will merge by 1.7.8 final.
* sr/fix-fast-export-tips (2011-11-05) 3 commits
- fast-export: output reset command for commandline revs
- fast-export: do not refer to non-existing marks
- t9350: point out that refs are not updated correctly
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-10-13) 4 commits
- submodule.c: make two functions static
- allow multiple calls to submodule merge search for the same path
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) would help.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload.
* jc/verbose-checkout (2011-10-16) 2 commits
- checkout -v: give full status output after switching branches
- checkout: move the local changes report to the end
This is just to leave a record that the reason why we do not do this not
because we are incapable of coding this, but because it is not a good idea
to do this. I suspect people who are new to git that might think they need
it would soon realize the don't.
Will keep in 'pu' as a showcase for a while and then will drop.
--------------------------------------------------
[Cooking]
* jc/stream-to-pack (2011-11-03) 4 commits
- Bulk check-in
- finish_tmp_packfile(): a helper function
- create_tmp_packfile(): a helper function
- write_pack_header(): a helper function
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. I think this
codepath to move data from worktree to repository needs to become aware of
streaming, just like the checkout codepath that goes the other way, which
was done in the previous "large file support" topic in the 1.7.7 cycle.
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
- gitweb: Add navigation to select side-by-side diff
- gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
- t9500: Add basic sanity tests for side-by-side diff in gitweb
- t9500: Add test for handling incomplete lines in diff by gitweb
- gitweb: Give side-by-side diff extra CSS styling
- gitweb: Add a feature to show side-by-side diff
- gitweb: Extract formatting of diff chunk header
- gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
* vr/msvc (2011-10-31) 3 commits
- MSVC: Remove unneeded header stubs
- Compile fix for MSVC: Include <io.h>
- Compile fix for MSVC: Do not include sys/resources.h
It seems this needs to be rehashed with msysgit folks.
* mf/curl-select-fdset (2011-11-04) 4 commits
(merged to 'next' on 2011-11-06 at a49516f)
+ http: drop "local" member from request struct
+ http.c: Rely on select instead of tracking whether data was received
+ http.c: Use timeout suggested by curl instead of fixed 50ms timeout
+ http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
Reduces unnecessary waits.
* na/strtoimax (2011-11-05) 3 commits
- Support sizes >=2G in various config options accepting 'g' sizes.
- Compatibility: declare strtoimax() under NO_STRTOUMAX
- Add strtoimax() compatibility function.
* nd/misc-cleanups (2011-10-27) 6 commits
(merged to 'next' on 2011-10-28 at 2527a49)
+ unpack_object_header_buffer(): clear the size field upon error
+ tree_entry_interesting: make use of local pointer "item"
+ tree_entry_interesting(): give meaningful names to return values
+ read_directory_recursive: reduce one indentation level
+ get_tree_entry(): do not call find_tree_entry() on an empty tree
+ tree-walk.c: do not leak internal structure in tree_entry_len()
These are unquestionably good parts taken out of a larger series, so that
we can focus more on the other changes in later rounds of review.
Will keep in 'next' during this cycle.
* rs/allocate-cache-entry-individually (2011-10-26) 2 commits
(merged to 'next' on 2011-10-27 at 2e4acd6)
+ cache.h: put single NUL at end of struct cache_entry
+ read-cache.c: allocate index entries individually
Will keep in 'next' during this cycle.
* mh/ref-api-3 (2011-10-19) 11 commits
(merged to 'next' on 2011-10-23 at 92e2d35)
+ is_refname_available(): reimplement using do_for_each_ref_in_array()
+ names_conflict(): simplify implementation
+ names_conflict(): new function, extracted from is_refname_available()
+ repack_without_ref(): reimplement using do_for_each_ref_in_array()
+ do_for_each_ref_in_array(): new function
+ do_for_each_ref(): correctly terminate while processesing extra_refs
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ parse_ref_line(): add a check that the refname is properly formatted
+ repack_without_ref(): remove temporary
+ Rename another local variable name -> refname
(this branch uses mh/ref-api-2.)
Will keep in 'next' during this cycle.
* rr/revert-cherry-pick (2011-10-23) 5 commits
(merged to 'next' on 2011-10-26 at 27b7496)
+ revert: simplify communicating command-line arguments
+ revert: allow mixed pick and revert instructions
+ revert: make commit subjects in insn sheet optional
+ revert: simplify getting commit subject in format_todo()
+ revert: free msg in format_todo()
The internals of "git revert/cherry-pick" has been further refactored to
serve as the basis for the sequencer.
Will keep in 'next' during this cycle.
* jc/check-ref-format-fixup (2011-10-19) 2 commits
(merged to 'next' on 2011-10-19 at 98981be)
+ Revert "Restrict ref-like names immediately below $GIT_DIR"
(merged to 'next' on 2011-10-15 at 8e89bc5)
+ Restrict ref-like names immediately below $GIT_DIR
This became a no-op except for the bottom one which is part of the other
topic now.
Will discard once the other topic graduates to 'master'.
* cb/daemon-permission-errors (2011-10-17) 2 commits
- daemon: report permission denied error to clients
- daemon: add tests
The tip commit might be loosening things a bit too much.
Will keep in 'pu' until hearing a convincing argument for the patch.
* mh/ref-api-2 (2011-10-17) 14 commits
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is used by mh/ref-api-3.)
Will keep in 'next' during this cycle.
* jc/signed-commit (2011-10-21) 7 commits
(merged to 'next' on 2011-10-23 at 03eec25)
+ pretty: %G[?GS] placeholders
+ parse_signed_commit: really use the entire commit log message
+ test "commit -S" and "log --show-signature"
+ t7004: extract generic "GPG testing" bits
+ log: --show-signature
+ commit: teach --gpg-sign option
+ Split GPG interface into its own helper library
This is to replace the earlier "signed push" experiments.
Will keep in 'next' during this cycle.
* sg/complete-refs (2011-10-21) 9 commits
(merged to 'next' on 2011-10-26 at d65e2b4)
+ completion: remove broken dead code from __git_heads() and __git_tags()
+ completion: fast initial completion for config 'remote.*.fetch' value
+ completion: improve ls-remote output filtering in __git_refs_remotes()
+ completion: query only refs/heads/ in __git_refs_remotes()
+ completion: support full refs from remote repositories
+ completion: improve ls-remote output filtering in __git_refs()
+ completion: make refs completion consistent for local and remote repos
+ completion: optimize refs completion
+ completion: document __gitcomp()
Will keep in 'next' until an Ack or two from completion folks.
* jc/request-pull-show-head-4 (2011-10-15) 11 commits
(merged to 'next' on 2011-10-15 at 7e340ff)
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
(merged to 'next' on 2011-10-10 at 092175e)
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements.
Will keep in 'next' during this cycle.
--------------------------------------------------
[Discarded]
* kk/gitweb-side-by-side-diff (2011-10-17) 2 commits
. gitweb: add a feature to show side-by-side diff
. gitweb: change format_diff_line() to remove leading SP from $diff_class
^ permalink raw reply
* Re: [PATCH] Add abbreviated commit hash to rebase conflict message
From: Junio C Hamano @ 2011-11-06 20:27 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Ævar Arnfjörð, Jonas Flodén, Eric Herman,
Fernando Vezzosi, Git List
In-Reply-To: <CAGdFq_j7NxojZ+82s0GJ8ZF0oyd5sH8t0kcMOTQGtKbASXqYTA@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Sun, Nov 6, 2011 at 05:14, Junio C Hamano <gitster@pobox.com> wrote:
>> I am puzzled, but that cannot be true. The existing message uses $msgnum
>> and $FIRSTLINE but does not use $commit because it does not necessarily
>> exist.
>>
>> What a value would the variable contain when I am applying your original
>> patch message using "git am -s" (or "git am -s3")?
>
> Aaah, I understand the concern you raise now. In that case a spurious
> [] would be printed, which I agree is less than desirable. Would
> checking 'if test -n $commit' be sufficient?
In what situation does it make sense to say "It came from _this_ commit"?
I think there is a separate variable that allows any part of the script if
we are being run as a backend of rebase or not, and that is the condition
you are looking for.
^ permalink raw reply
* Re: A Python script to put CTAN into git (from DVDs)
From: Jakub Narebski @ 2011-11-06 20:29 UTC (permalink / raw)
To: Jonathan Fine; +Cc: python-list, git
In-Reply-To: <4EB6CFBB.2090901@pytex.org>
The following message is a courtesy copy of an article
that has been posted to comp.lang.python,comp.text.tex as well.
Jonathan Fine <jfine@pytex.org> writes:
> On 06/11/11 16:42, Jakub Narebski wrote:
>> Jonathan Fine<jfine@pytex.org> writes:
>>
>>> This it to let you know that I'm writing (in Python) a script that
>>> places the content of CTAN into a git repository.
>>> https://bitbucket.org/jfine/python-ctantools
>>
>> I hope that you meant "repositories" (plural) here, one per tool,
>> rather than putting all of CTAN into single Git repository.
[moved]
>> There was similar effort done in putting CPAN (Comprehensive _Perl_
>> Archive Network) in Git, hosting repositories on GitHub[1], by the name
>> of gitPAN, see e.g.:
>>
>> "The gitPAN Import is Complete"
>> http://perlisalive.com/articles/36
>>
>> [1]: https://github.com/gitpan
[/moved]
> There are complex dependencies among LaTeX macro packages, and TeX is
> often distributed and installed from a DVD. So it makes sense here to
> put *all* the content of a DVD into a repository.
Note that for gitPAN each "distribution" (usually but not always
corresponding to single Perl module) is in separate repository.
The dependencies are handled by CPAN / CPANPLUS / cpanm client
(i.e. during install).
Putting all DVD (is it "TeX Live" DVD by the way?) into single
repository would put quite a bit of stress to git; it was created for
software development (although admittedly of large project like Linux
kernel), not 4GB+ trees.
> Once you've done that, it is then possible and sensible to select
> suitable interesting subsets, such as releases of a particular
> package. Users could even define their own subsets, such as "all
> resources needed to process this file, exactly as it processes on my
> machine".
This could be handled using submodules, by having superrepository that
consist solely of references to other repositories by the way of
submodules... plus perhaps some administrativa files (like README for
whole CTAN, or search tool, or DVD install, etc.)
This could be the used to get for example contents of DVD from 2010.
But even though submodules (c.f. Subversion svn:external, Mecurial
forest extension, etc.) are in Git for quite a bit of time, it doesn't
have best user interface.
> In addition, many TeX users have a TeX DVD. If they import it into a
> git repository (using for example my script) then the update from 2011
> to 2012 would require much less bandwidth.
???
> Finally, I'd rather be working within git that modified copy of the
> ISO when doing the subsetting. I'm pretty sure that I can manage to
> pull the small repositories from the big git-CTAN repository.
No you cannot. It is all or nothing; there is no support for partial
_clone_ (yet), and it looks like it is a hard problem.
Nb. there is support for partial _checkout_, but this is something
different.
> But as I proceed, perhaps I'll change my mind (smile).
>
>>> I'm working from the TeX Collection DVDs that are published each year
>>> by the TeX user groups, which contain a snapshot of CTAN (about
>>> 100,000 files occupying 4Gb), which means I have to unzip folders and
>>> do a few other things.
>>
>> There is 'contrib/fast-import/import-zips.py' in git.git repository.
>> If you are not using it, or its equivalent, it might be worth checking
>> out.
>
> Well, I didn't know about that. I took a look, and it doesn't do what
> I want. I need to walk the tree (on a mounted ISO) and unpack some
> (but not all) zip files as I come across them. For details see:
> https://bitbucket.org/jfine/python-ctantools/src/tip/ctantools/filetools.py
>
> In addition, I don't want to make a commit. I just want to make a ref
> at the end of building the tree. This is because I want the import of
> a TeX DVD to give effectively identical results for all users, and so
> any commit information would be effectively constant.
Commit = tree + parent + metadata.
I think you would very much want to have linear sequence of trees,
ordered via DAG of commits. "Naked" trees are rather bad idea, I think.
> As I recall the first 'commit' to the git repository for the Linux
> kernel was just a tree, with a reference to that tree as a tag. But
> no commit.
That was a bad accident that there is a tag that points directly to a
tree of _initial import_, not something to copy.
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH] Add abbreviated commit hash to rebase conflict message
From: Sverre Rabbelier @ 2011-11-06 20:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð, Jonas Flodén, Eric Herman,
Fernando Vezzosi, Git List
In-Reply-To: <7vaa89573r.fsf@alter.siamese.dyndns.org>
Heya,
On Sun, Nov 6, 2011 at 21:27, Junio C Hamano <gitster@pobox.com> wrote:
> In what situation does it make sense to say "It came from _this_ commit"?
>
> I think there is a separate variable that allows any part of the script if
> we are being run as a backend of rebase or not, and that is the condition
> you are looking for.
The closest I could find is:
if test -f "$dotest/rebasing"
Which is exactly the case when commit is set. Do you prefer the "-f
$dotest/rebasing" test or the "-n $commit" one?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2011, #02; Sun, 6)
From: Jakub Narebski @ 2011-11-06 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vehxl57lt.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> With maint, master, next, pu, todo:
>
> git://git.kernel.org/pub/scm/git/git.git
> git://repo.or.cz/alt-git.git
> https://code.google.com/p/git-core/
> https://github.com/git/git
>
> With only maint and master:
>
> git://git.sourceforge.jp/gitroot/git-core/git.git
> git://git-core.git.sourceforge.net/gitroot/git-core/git-core
>
> With all the topics and integration branches but not todo, html or man:
>
> https://github.com/gitster/git
>
> I will stop pushing the generated documentation branches to the above
> repositories, as they are not sources. The only reason the source
> repository at k.org has hosted these branches was because it was the only
> repository over there that was writable by me; it was an ugly historical
> and administrative workaround and not a demonstration of the best
> practice.
Errr... haven't you *actually stopped* pusing generated documentation
to 'html' and 'man' branches to above repositories? They are not
present anymore (I had to update my pre-separate-remotes config).
> These branches are pushed to their own separate repositories instead:
>
> git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
> git://repo.or.cz/git-{htmldocs,manpages}.git/
> https://code.google.com/p/git-{htmldocs,manpages}.git/
> https://github.com/gitster/git-{htmldocs,manpages}.git/
You can always put the fommowing in .git/config:
[remote "git-manpages"]
url = git://git.kernel.org/pub/scm/git/git-manpages.git
fetch = +refs/heads/master:refs/remotes/origin/man
[remote "git-htmldocs"]
url = git://git.kernel.org/pub/scm/git/git-htmldocs.git
fetch = +refs/heads/master:refs/remotes/origin/html
> --------------------------------------------------
[...]
> * jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
> - gitweb: Add navigation to select side-by-side diff
> - gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
> - t9500: Add basic sanity tests for side-by-side diff in gitweb
> - t9500: Add test for handling incomplete lines in diff by gitweb
> - gitweb: Give side-by-side diff extra CSS styling
> - gitweb: Add a feature to show side-by-side diff
> - gitweb: Extract formatting of diff chunk header
> - gitweb: Refactor diff body line classification
>
> Replaces a series from Kato Kazuyoshi on the same topic.
Thanks.
Sidenote : is there need for wupport for word-diff in gitweb?
If yes, then navigation as in above series i.e.
inline | _side-by-side_
where current style is not linked would be better than alternative,
i.e. just
_side-by-side_
or
_inline_
depending on what style you use.
--
Jakub Narębski
^ 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