* Re: Git, Mac OS X and German special characters
From: Michael Witten @ 2011-10-01 23:26 UTC (permalink / raw)
To: Jakub Narebski
Cc: Andreas Krey, Andreas Ericsson, Albert Zeyer, Git Mailing List
In-Reply-To: <m3hb3snw4b.fsf@localhost.localdomain>
2011/10/1 Jakub Narebski <jnareb@gmail.com>:
> Michael Witten <mfwitten@gmail.com> writes:
>> On Sat, Oct 1, 2011 at 19:47, Andreas Krey <a.krey@gmx.de> wrote:
>>
>> > The question is, should git forbid two filenames that consist
>> > of the *same* characters, only differently uni-encoded? I don't
>> > think anyone would make two files named 'Büro', with different
>> > unicode encodings. But as far as I know that is a shady area.
>>
>> So, let's leave git's current behavior as the default and provide
>> a config variable that when set, tells git to handle file names
>> in terms of characters rather than bytes.
>
> You meant here _graphemes_, not Unicode codepoint when talking about
> characters, didn't you?
Yes.
^ permalink raw reply
* NOTIFICATION 2011
From: E-MAIL.BALLOT.rosilawati @ 2011-10-01 23:12 UTC (permalink / raw)
To: Recipients
NOTIFICATION
This is to inform you of the release of the WINNERS of the E-MAIL LOTTERY
BALLOT / WORLD GAMING BOARD held 2011.Your name attached to ticket number
219028657434 with serial number 918735625 You have therefore been approved
for a payment (€1,500,000.00 Euros only. Your Email ID has won
Email : einfobak@yahoo.com.hk
Tel: +31-64-536-0288
Fax: +31-84-7312-763
Full names,Address,Age,Occupation,Phone/ numbers.
Yours Sincerely,
NAME: MRS LOECKX MARGARETA MARIA CAROLINA
(Web-Email Information Manager)
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Jakub Narebski @ 2011-10-01 23:14 UTC (permalink / raw)
To: Michael Witten
Cc: Andreas Krey, Andreas Ericsson, Albert Zeyer, Git Mailing List
In-Reply-To: <CAMOZ1BuXiQkZG_7mvay-ybm7Q7niwXVhbmbCmkfy=wD1AKsasQ@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> On Sat, Oct 1, 2011 at 19:47, Andreas Krey <a.krey@gmx.de> wrote:
>
> > The question is, should git forbid two filenames that consist
> > of the *same* characters, only differently uni-encoded? I don't
> > think anyone would make two files named 'Büro', with different
> > unicode encodings. But as far as I know that is a shady area.
>
> So, let's leave git's current behavior as the default and provide
> a config variable that when set, tells git to handle file names
> in terms of characters rather than bytes.
You meant here _graphemes_, not Unicode codepoint when talking about
characters, didn't you?
IIRC the problem with MacOS X is that it accepts different composition
when creating a file from what it returns when asking for contents of
directory (NFD if I remember correctly, which is less used).
There are some beginnings of sanely handling filesystem encoding in
Git (the framework), but it is currently underutilized only to handle
case-sensitivity and case-preserving.
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 22:06 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111001T232414-84@post.gmane.org>
Peter Shenkin <shenkin <at> gmail.com> writes:
> But it leaves unexplained and undocumented the fact
> that the user's specification of an *additional* refspec is
> observed if the additional refspec is given on the
> command line but ignored if the additional refspec is
> given in the config file.
I have to take this back. It makes sense that a refspec on
the cmdline overrides one in the config file.
I understand the behavior now, and Michael's suggestion of a
--default to add the refspec in the config file to the cmdline
is IMO a good one.
'Nuff said. (By me, anyway....)
Thanks for your help and patience, everyone.
-P.
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Michael Witten @ 2011-10-01 22:02 UTC (permalink / raw)
To: Andreas Krey; +Cc: Andreas Ericsson, Albert Zeyer, Git Mailing List
In-Reply-To: <20111001194746.GA16826@inner.h.iocl.org>
On Sat, Oct 1, 2011 at 19:47, Andreas Krey <a.krey@gmx.de> wrote:
> The question is, should git forbid two filenames that consist
> of the *same* characters, only differently uni-encoded? I don't
> think anyone would make two files named 'Büro', with different
> unicode encodings. But as far as I know that is a shady area.
So, let's leave git's current behavior as the default and provide
a config variable that when set, tells git to handle file names
in terms of characters rather than bytes.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <CAMOZ1BsYYmH6hqcB4vfCq2LAu+fxJ4MzPQ1+-erUSqU1ptx2mQ@mail.gmail.com>
Michael Witten <mfwitten <at> gmail.com> writes:
> On Sat, Oct 1, 2011 at 20:22, Peter Shenkin <shenkin <at> gmail.com> wrote:
> [--tags] is merely a shorthand for writing the refspec
> `refs/tags/\*:refs/tags/\*'; that is,
Yes, I understand that fully and it makes perfect sense.
But it leaves unexplained and undocumented the fact
that the user's specification of an *additional* refspec is
observed if the additional refspec is given on the
command line but ignored if the additional refspec is
given in the config file.
-P.
^ permalink raw reply
* Re: [PATCH v2] gitk: Show patch for initial commit
From: Zbigniew Jędrzejewski-Szmek @ 2011-10-01 21:03 UTC (permalink / raw)
To: Marcus Karlsson; +Cc: git, gitster, Paul Mackerras
In-Reply-To: <20111001190554.GA5854@kennedy.acc.umu.se>
[cc: Paul Mackerras]
Hi,
I think that the historical explanation that Junio gave could
be used as a basis for a commit message:
In early days, all projects managed by git (except for git itself) had the
product of a fairly mature development history in their first commit, and
it was deemed unnecessary clutter to show additions of these thousands of
paths as a patch.
"git log" learned to show the patch for the initial commit without requiring
--root command line option at 0f03ca9 (config option log.showroot to show
the diff of root commits, 2006-11-23).
Teach gitk to respect log.showroot.
Also the gitk should be mentioned in the man-page for git-config log.showroot.
The current description of this option seems suboptimal because it explains
how it used to be, which is not really relevant:
log.showroot
If true, the initial commit will be shown as a big creation event. This is
equivalent to a diff against an empty tree. Tools like git-log(1) or git-
whatchanged(1), which normally hide the root commit will now show it. True by
default.
This could be changed to:
If true (the default), the root commit will be shown as a big creation
event --- a diff against an empty tree. This diff can be very large for
a project which was imported into git after some development history.
If log.showroot is false tools like git-log(1), git-whatchanged(1), or
gitk(1) will not display the added files.
Zbyszek
On 10/01/2011 09:05 PM, Marcus Karlsson wrote:
> Make gitk show the patch for the initial commit by default.
> Override with log.showroot.
>
> Signed-off-by: Marcus Karlsson<mk@acc.umu.se>
> ---
> gitk-git/gitk | 13 +++++++++++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index 4cde0c4..40ea73f 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -7402,7 +7402,7 @@ proc addtocflist {ids} {
> }
>
> proc diffcmd {ids flags} {
> - global nullid nullid2
> + global log_showroot nullid nullid2
>
> set i [lsearch -exact $ids $nullid]
> set j [lsearch -exact $ids $nullid2]
> @@ -7436,7 +7436,11 @@ proc diffcmd {ids flags} {
> lappend cmd HEAD
> }
> } else {
> - set cmd [concat | git diff-tree -r $flags $ids]
> + set cmd [concat | git diff-tree -r]
> + if {$log_showroot eq true} {
> + set cmd [concat $cmd --root]
> + }
> + set cmd [concat $cmd $flags $ids]
> }
> return $cmd
> }
> @@ -11403,6 +11407,11 @@ catch {
> }
> }
>
> +set log_showroot true
> +catch {
> + set log_showroot [exec git config --get log.showroot]
> +}
> +
> if {[tk windowingsystem] eq "aqua"} {
> set mainfont {{Lucida Grande} 9}
> set textfont {Monaco 9}
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-10-01 20:56 UTC (permalink / raw)
To: Peter Shenkin; +Cc: git
In-Reply-To: <loom.20111001T214551-834@post.gmane.org>
On Sat, Oct 1, 2011 at 20:22, Peter Shenkin <shenkin@gmail.com> wrote:
>
> The question is not how the --tags option should be
> documented, but rather why "--tags" should behave
> differently when the refspec is given on the commandline
> than when the refspec is given in the .git/config file.
Again, see here:
[PATCH v3] Docs: Clarify the --tags option of `git fetch'
Message-ID: <686c38876d5a4ad6bfac67ca77fe9bb3-mfwitten@gmail.com>
http://article.gmane.org/gmane.comp.version-control.git/181887
namely:
This option is merely a shorthand for writing the refspec
`refs/tags/\*:refs/tags/\*'; that is,
git fetch origin --tags
git fetch origin --tags frotz
are equivalent to:
git fetch origin 'refs/tags/*:refs/tags/*'
git fetch origin frotz 'refs/tags/*:refs/tags/*'
In other words, by writing "--tags", you are actually writing
"refs/tags/\*:refs/tags/\*"; because you are stating an *explicit*
refspec, "git fetch" doesn't bother with any *implicit* default
in your config, which is consistent with how "git fetch" works.
It would probably be a good idea if there were a "--defaults", too.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Junio C Hamano @ 2011-10-01 20:41 UTC (permalink / raw)
To: Martin Fick
Cc: git, Christian Couder, Thomas Rast, René Scharfe,
Julian Phillips, Michael Haggerty
In-Reply-To: <201109301606.31748.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> I guess this makes sense, we invalidate the cache and have
> to rebuild it after every new ref is added? Perhaps a
> simple fix would be to move the invalidation right after all
> the refs are updated? Maybe write_ref_sha1 could take in a
> flag to tell it to not invalidate the cache so that during
> iterative updates it could be disabled and then run manually
> after the update?
It might make sense, on top of Julian's patch, to add a bit that says "the
contents of this ref-array is current but the array is not sorted", and
whenever somebody runs add_ref(), append it also to the ref-array (so that
the contents do not have to be re-read from the filesystem) but flip the
"unsorted" bit on. Then update look-up and iteration to sort the array
when "unsorted" bit is on without re-reading the contents from the
filesystem.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 20:22 UTC (permalink / raw)
To: git
In-Reply-To: <CAMOZ1Bsc2idQnKxeggruPi1rrY3+vsa=DoMydHY4+BM+qoW69w@mail.gmail.com>
Michael Witten <mfwitten <at> gmail.com> writes:
> git fetch --tags origin '+refs/heads/*:refs/remotes/origin/*'
Well, Junio had just about convinced me that there was
nothing wrong with the documentation -- just with the
way I was reading it -- until I read the above.
I tried it and yes, it does do what I want. Which was not
at all my expectation, having read Junio's comment about
how the documentation is to be read.
Junio argued that the man-page mod I suggested --
namely, "This flag causes all tags and their associated
objects (only) to be downloaded." -- was unneeded
because the meaning, though correct, is clear already and
therefore redundant.
But the real problem is that the reading he gives is just
wrong.
I have the following in my .git/config file:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
tagopt = --tags
url = <whatever>
Given this, I do not see how anyone could infer from
anything in the documentation that
git fetch
would do anything different from:
git fetch --tags origin +refs/heads/*:refs/remotes/origin/*
If I am wrong about this, please cite chapter and verse.
The question is not how the --tags option should be
documented, but rather why "--tags" should behave
differently when the refspec is given on the commandline
than when the refspec is given in the .git/config file.
In fact, I no longer think it is a documentation error. It
is a just a really terrible implementation decision. If it
was desired to allow "git fetch --tags" to work without
using the user's specified refspec, then a "--no-heads"
option should have been provided to override the user's
refspec -- no matter where it was given.
Though a retrofit would likely break too many workflows,
the best one might hope for now would likely be the
addition of a "--heads" option, which would have the
effect of bringing down the branch heads even though
this would not normally be done."
But then it would still be necessary to say that "--tags"
does not normally obey the user's refspec if given in the
config file, but does if given on the command line.
I might still be missing something. If anyone thinks the
current behavior is clear from a careful reading of the
documentation, I would like to hear how that inference
could be drawn. For no matter how one reads the --tags
description, it seems it is wrong in one of the two cases.
It is either wrong for a refspec on the command-line (if
you think it says it downloads tags only) or else it is wrong
for refspec in the config file (if you think it says it downloads
tags and heads).
^ permalink raw reply
* Re: [PATCH] gitk: Show patch for initial commit
From: Junio C Hamano @ 2011-10-01 20:20 UTC (permalink / raw)
To: Marcus Karlsson; +Cc: Zbigniew J??drzejewski-Szmek, git, gitster
In-Reply-To: <20111001184216.GA5796@kennedy.acc.umu.se>
Marcus Karlsson <mk@acc.umu.se> writes:
>> >diff --git a/gitk-git/gitk b/gitk-git/gitk
>> >index 4cde0c4..20aeae6 100755
>> >--- a/gitk-git/gitk
>> >+++ b/gitk-git/gitk
>> >@@ -7436,7 +7436,7 @@ proc diffcmd {ids flags} {
>> > lappend cmd HEAD
>> > }
>> > } else {
>> >- set cmd [concat | git diff-tree -r $flags $ids]
>> >+ set cmd [concat | git diff-tree -r --root $flags $ids]
>> > }
>> > return $cmd
>> > }
>> Cool, this works for me! But I think I would be really nice if gitk
>> respected the configuration value of log.showroot. This would give
>> nice consistency amongst the various tools.
>
> I agree, that would be reasonable. I'll prepare a new patch with that
> behavior.
That would be good, but whatever you do please keep the maintainer of
gitk, Paul Mackerras <paulus@samba.org>, in the loop.
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Andreas Krey @ 2011-10-01 19:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Albert Zeyer, Git Mailing List
In-Reply-To: <4E872288.10503@op5.se>
On Sat, 01 Oct 2011 09:24:08 +0000, Andreas Ericsson wrote:
...
> The trouble is that they may represent two different files on a
> different filesystem. The Linux kernel repo has plenty of files
> that exist with both uppercase and lowercase characters, like so:
> SOMEFILE_driver.c
> somefile_driver.c
>
> This is perfectly valid on all sensible and case-sensitive
> filesystems, but breaks horribly on HFS.
It also breaks on windows, except in at least one country[1].
And the latter alone is good reason why no VCS should try to
forbid to use different characters that some filesystems
(and only some) consider the same.
> There are other, far more
> "interesting" cases when you involve special chars such as the
> german umlaut, or the swedish åäö characters.
Care to share some?
The question is, should git forbid two filenames that consist
of the *same* characters, only differently uni-encoded? I don't
think anyone would make two files named 'Büro', with different
unicode encodings. But as far as I know that is a shady area.
Andreas
[1] Which has 'i with dot' and 'i without dot' both in uppercase
and lowercase variant, so I and i are not the 'same'.
^ permalink raw reply
* [PATCH v2] gitk: Show patch for initial commit
From: Marcus Karlsson @ 2011-10-01 19:05 UTC (permalink / raw)
To: git; +Cc: gitster, zbyszek
Make gitk show the patch for the initial commit by default.
Override with log.showroot.
Signed-off-by: Marcus Karlsson <mk@acc.umu.se>
---
gitk-git/gitk | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 4cde0c4..40ea73f 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7402,7 +7402,7 @@ proc addtocflist {ids} {
}
proc diffcmd {ids flags} {
- global nullid nullid2
+ global log_showroot nullid nullid2
set i [lsearch -exact $ids $nullid]
set j [lsearch -exact $ids $nullid2]
@@ -7436,7 +7436,11 @@ proc diffcmd {ids flags} {
lappend cmd HEAD
}
} else {
- set cmd [concat | git diff-tree -r $flags $ids]
+ set cmd [concat | git diff-tree -r]
+ if {$log_showroot eq true} {
+ set cmd [concat $cmd --root]
+ }
+ set cmd [concat $cmd $flags $ids]
}
return $cmd
}
@@ -11403,6 +11407,11 @@ catch {
}
}
+set log_showroot true
+catch {
+ set log_showroot [exec git config --get log.showroot]
+}
+
if {[tk windowingsystem] eq "aqua"} {
set mainfont {{Lucida Grande} 9}
set textfont {Monaco 9}
--
1.7.7
^ permalink raw reply related
* Re: [PATCH 1/8] checkout: check for "Previous HEAD" notice in t2020
From: Sverre Rabbelier @ 2011-10-01 19:02 UTC (permalink / raw)
To: René Scharfe
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8733FA.6070201@lsrfire.ath.cx>
Heya,
On Sat, Oct 1, 2011 at 17:38, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> If we leave a detached head, exactly one of two things happens: either
> checkout warns about it being an orphan or describes it as a courtesy.
> Test t2020 already checked that the warning is shown as needed. This
> patch also checks for the description.
A cover letter would have been nice for such a long series :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-10-01 18:45 UTC (permalink / raw)
To: Peter Shenkin; +Cc: git
In-Reply-To: <loom.20111001T191413-25@post.gmane.org>
On Sat, Oct 1, 2011 at 17:16, Peter Shenkin <shenkin@gmail.com> wrote:
> Michael Witten <mfwitten <at> gmail.com> writes:
>> However, my point was this:
>>
>> You can still tell git to fetch anything else you want in addition.
>
> Michael,
>
> Yes, you are right. I am still missing how to do that.
>
> Can you show me a sample fetch invocation that would
> have the effect of downloading all tags and also branch heads?
Unfortunately, there's currently no way to tell "git fetch" to
download whatever your configuration files specify as default, but you
can at least be explicit by using what's called a "refspec" (which is
documented in "git help fetch"):
git fetch --tags origin '+refs/heads/*:refs/remotes/origin/*'
You could probably get your hands on the default refspec by rigging
something up with "git symbolic-ref" and "git config", but that's so
much hassle; currently, it is probably best just to run "git fetch"
twice.
Sincerely,
Michael Witten
You might also find this email insightful:
http://article.gmane.org/gmane.comp.version-control.git/181911
Message-ID: <7142366f54c44cea82542adf8aea5bb9-mfwitten@gmail.com>
Subject: Re: any way to "re-sync" a bare repository against
another bare repository?
^ permalink raw reply
* Re: [PATCH] gitk: Show patch for initial commit
From: Marcus Karlsson @ 2011-10-01 18:42 UTC (permalink / raw)
To: Zbigniew J??drzejewski-Szmek; +Cc: git, gitster
In-Reply-To: <4E86E343.5070704@in.waw.pl>
On Sat, Oct 01, 2011 at 11:54:11AM +0200, Zbigniew J??drzejewski-Szmek wrote:
> On 09/30/2011 11:50 PM, Marcus Karlsson wrote:
> >Make gitk show the patch for the initial commit.
> >
> >Signed-off-by: Marcus Karlsson<mk@acc.umu.se>
> >---
> > gitk-git/gitk | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> >diff --git a/gitk-git/gitk b/gitk-git/gitk
> >index 4cde0c4..20aeae6 100755
> >--- a/gitk-git/gitk
> >+++ b/gitk-git/gitk
> >@@ -7436,7 +7436,7 @@ proc diffcmd {ids flags} {
> > lappend cmd HEAD
> > }
> > } else {
> >- set cmd [concat | git diff-tree -r $flags $ids]
> >+ set cmd [concat | git diff-tree -r --root $flags $ids]
> > }
> > return $cmd
> > }
> Cool, this works for me! But I think I would be really nice if gitk
> respected the configuration value of log.showroot. This would give
> nice consistency amongst the various tools.
I agree, that would be reasonable. I'll prepare a new patch with that
behavior.
Marcus
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 17:16 UTC (permalink / raw)
To: git
In-Reply-To: <CAMOZ1Bvn64q5sVfo2-ZhTSpBttpjG1pHELJMM9sEmWsrqANCkw@mail.gmail.com>
Michael Witten <mfwitten <at> gmail.com> writes:
> However, my point was this:
>
> You can still tell git to fetch anything else you want in addition.
Michael,
Yes, you are right. I am still missing how to do that.
Can you show me a sample fetch invocation that would
have the effect of downloading all tags and also branch heads?
Thanks,
-P.
^ permalink raw reply
* [PATCH] name-rev: split usage string
From: René Scharfe @ 2011-10-01 17:04 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Pierre Habouzit
Give each mode of operation (all, from stdin, given commits) its own usage
line to make it easier to see that they are mutually exclusive.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin/name-rev.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 31f5c1c..7864056 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -172,7 +172,9 @@ static void show_name(const struct object *obj,
}
static char const * const name_rev_usage[] = {
- "git name-rev [options] ( --all | --stdin | <commit>... )",
+ "git name-rev [options] <commit>...",
+ "git name-rev [options] --all",
+ "git name-rev [options] --stdin",
NULL
};
--
1.7.7
^ permalink raw reply related
* [PATCH 2/2] test-ctype: add test for is_pathspec_magic
From: René Scharfe @ 2011-10-01 16:39 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <4E87417E.1060100@lsrfire.ath.cx>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
test-ctype.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/test-ctype.c b/test-ctype.c
index b4d1f74..707a821 100644
--- a/test-ctype.c
+++ b/test-ctype.c
@@ -36,6 +36,7 @@ int main(int argc, char **argv)
TEST_CLASS(isalnum, LOWER UPPER DIGIT);
TEST_CLASS(is_glob_special, "*?[\\");
TEST_CLASS(is_regex_special, "$()*+.?[\\^{|");
+ TEST_CLASS(is_pathspec_magic, "!\"#%&',-/:;<=>@_`~");
return rc;
}
--
1.7.7
^ permalink raw reply related
* [PATCH 1/2] test-ctype: macrofy
From: René Scharfe @ 2011-10-01 16:36 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
Rewrite test-ctype to use a global variable and a macro instead of
wrapper functions for each character class and complicated structs
with loops going through them. The resulting code may be uglier,
but that's OK for a test program, and it's actually easier to read
and extend. And much shorter.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
test-ctype.c | 79 +++++++++++++++------------------------------------------
1 files changed, 21 insertions(+), 58 deletions(-)
diff --git a/test-ctype.c b/test-ctype.c
index 033c749..b4d1f74 100644
--- a/test-ctype.c
+++ b/test-ctype.c
@@ -1,78 +1,41 @@
#include "cache.h"
+static int rc;
-static int test_isdigit(int c)
+static void report_error(const char *class, int ch)
{
- return isdigit(c);
+ printf("%s classifies char %d (0x%02x) wrongly\n", class, ch, ch);
+ rc = 1;
}
-static int test_isspace(int c)
+static int is_in(const char *s, int ch)
{
- return isspace(c);
+ /* We can't find NUL using strchr. It's classless anyway. */
+ if (ch == '\0')
+ return 0;
+ return !!strchr(s, ch);
}
-static int test_isalpha(int c)
-{
- return isalpha(c);
-}
-
-static int test_isalnum(int c)
-{
- return isalnum(c);
-}
-
-static int test_is_glob_special(int c)
-{
- return is_glob_special(c);
-}
-
-static int test_is_regex_special(int c)
-{
- return is_regex_special(c);
+#define TEST_CLASS(t,s) { \
+ int i; \
+ for (i = 0; i < 256; i++) { \
+ if (is_in(s, i) != t(i)) \
+ report_error(#t, i); \
+ } \
}
#define DIGIT "0123456789"
#define LOWER "abcdefghijklmnopqrstuvwxyz"
#define UPPER "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
-static const struct ctype_class {
- const char *name;
- int (*test_fn)(int);
- const char *members;
-} classes[] = {
- { "isdigit", test_isdigit, DIGIT },
- { "isspace", test_isspace, " \n\r\t" },
- { "isalpha", test_isalpha, LOWER UPPER },
- { "isalnum", test_isalnum, LOWER UPPER DIGIT },
- { "is_glob_special", test_is_glob_special, "*?[\\" },
- { "is_regex_special", test_is_regex_special, "$()*+.?[\\^{|" },
- { NULL }
-};
-
-static int test_class(const struct ctype_class *test)
-{
- int i, rc = 0;
-
- for (i = 0; i < 256; i++) {
- int expected = i ? !!strchr(test->members, i) : 0;
- int actual = test->test_fn(i);
-
- if (actual != expected) {
- rc = 1;
- printf("%s classifies char %d (0x%02x) wrongly\n",
- test->name, i, i);
- }
- }
- return rc;
-}
-
int main(int argc, char **argv)
{
- const struct ctype_class *test;
- int rc = 0;
-
- for (test = classes; test->name; test++)
- rc |= test_class(test);
+ TEST_CLASS(isdigit, DIGIT);
+ TEST_CLASS(isspace, " \n\r\t");
+ TEST_CLASS(isalpha, LOWER UPPER);
+ TEST_CLASS(isalnum, LOWER UPPER DIGIT);
+ TEST_CLASS(is_glob_special, "*?[\\");
+ TEST_CLASS(is_regex_special, "$()*+.?[\\^{|");
return rc;
}
--
1.7.7
^ permalink raw reply related
* [PATCH 8/8] commit: factor out clear_commit_marks_for_object_array
From: René Scharfe @ 2011-10-01 16:16 UTC (permalink / raw)
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8731AF.2040305@lsrfire.ath.cx>
Factor out the code to clear the commit marks for a whole struct
object_array from builtin/checkout.c into its own exported function
clear_commit_marks_for_object_array and use it in bisect and bundle
as well. It handles tags and commits and ignores objects of any
other type.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
bisect.c | 7 ++-----
builtin/checkout.c | 8 +-------
bundle.c | 3 +--
commit.c | 14 ++++++++++++++
commit.h | 1 +
5 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/bisect.c b/bisect.c
index a05504f..b4547b9 100644
--- a/bisect.c
+++ b/bisect.c
@@ -826,7 +826,7 @@ static int check_ancestors(const char *prefix)
{
struct rev_info revs;
struct object_array pending_copy;
- int i, res;
+ int res;
bisect_rev_setup(&revs, prefix, "^%s", "%s", 0);
@@ -843,10 +843,7 @@ static int check_ancestors(const char *prefix)
res = (revs.commits != NULL);
/* Clean up objects used, as they will be reused. */
- for (i = 0; i < pending_copy.nr; i++) {
- struct object *o = pending_copy.objects[i].item;
- clear_commit_marks((struct commit *)o, ALL_REV_FLAGS);
- }
+ clear_commit_marks_for_object_array(&pending_copy, ALL_REV_FLAGS);
free(pending_copy.objects);
return res;
diff --git a/builtin/checkout.c b/builtin/checkout.c
index cfd7e59..683819b 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -664,7 +664,6 @@ static void orphaned_commit_warning(struct commit *commit)
struct rev_info revs;
struct object *object = &commit->object;
struct object_array refs;
- unsigned int i;
init_revisions(&revs, NULL);
setup_revisions(0, NULL, &revs, NULL);
@@ -684,12 +683,7 @@ static void orphaned_commit_warning(struct commit *commit)
else
describe_detached_head(_("Previous HEAD position was"), commit);
- for (i = 0; i < refs.nr; i++) {
- struct object *o = refs.objects[i].item;
- struct commit *c = lookup_commit_reference_gently(o->sha1, 1);
- if (c)
- clear_commit_marks(c, ALL_REV_FLAGS);
- }
+ clear_commit_marks_for_object_array(&refs, ALL_REV_FLAGS);
free(refs.objects);
}
diff --git a/bundle.c b/bundle.c
index 26cc9ab..a8ea918 100644
--- a/bundle.c
+++ b/bundle.c
@@ -141,8 +141,7 @@ int verify_bundle(struct bundle_header *header, int verbose)
refs.objects[i].name);
}
- for (i = 0; i < refs.nr; i++)
- clear_commit_marks((struct commit *)refs.objects[i].item, -1);
+ clear_commit_marks_for_object_array(&refs, ALL_REV_FLAGS);
free(refs.objects);
if (verbose) {
diff --git a/commit.c b/commit.c
index 97b4327..50af007 100644
--- a/commit.c
+++ b/commit.c
@@ -430,6 +430,20 @@ void clear_commit_marks(struct commit *commit, unsigned int mark)
}
}
+void clear_commit_marks_for_object_array(struct object_array *a, unsigned mark)
+{
+ struct object *object;
+ struct commit *commit;
+ unsigned int i;
+
+ for (i = 0; i < a->nr; i++) {
+ object = a->objects[i].item;
+ commit = lookup_commit_reference_gently(object->sha1, 1);
+ if (commit)
+ clear_commit_marks(commit, mark);
+ }
+}
+
struct commit *pop_commit(struct commit_list **stack)
{
struct commit_list *top = *stack;
diff --git a/commit.h b/commit.h
index 12d100b..0a4c730 100644
--- a/commit.h
+++ b/commit.h
@@ -126,6 +126,7 @@ struct commit *pop_most_recent_commit(struct commit_list **list,
struct commit *pop_commit(struct commit_list **stack);
void clear_commit_marks(struct commit *commit, unsigned int mark);
+void clear_commit_marks_for_object_array(struct object_array *a, unsigned mark);
/*
* Performs an in-place topological sort of list supplied.
--
1.7.7
^ permalink raw reply related
* [PATCH 7/8] checkout: use leak_pending flag
From: René Scharfe @ 2011-10-01 16:09 UTC (permalink / raw)
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8731AF.2040305@lsrfire.ath.cx>
Instead of going through all the references again when we clear the
commit marks, do it like bisect and bundle and gain ownership of the
list of pending objects which we constructed from those references.
We simply copy the struct object_array that points to the list, set
the flag leak_pending and then prepare_revision_walk won't destroy
it and it's ours. We use it to clear the marks and free it at the
end.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin/checkout.c | 25 ++++++++++++-------------
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 84e0cdc..cfd7e59 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -596,17 +596,6 @@ static int add_pending_uninteresting_ref(const char *refname,
return 0;
}
-static int clear_commit_marks_from_one_ref(const char *refname,
- const unsigned char *sha1,
- int flags,
- void *cb_data)
-{
- struct commit *commit = lookup_commit_reference_gently(sha1, 1);
- if (commit)
- clear_commit_marks(commit, -1);
- return 0;
-}
-
static void describe_one_orphan(struct strbuf *sb, struct commit *commit)
{
parse_commit(commit);
@@ -674,6 +663,8 @@ static void orphaned_commit_warning(struct commit *commit)
{
struct rev_info revs;
struct object *object = &commit->object;
+ struct object_array refs;
+ unsigned int i;
init_revisions(&revs, NULL);
setup_revisions(0, NULL, &revs, NULL);
@@ -683,6 +674,9 @@ static void orphaned_commit_warning(struct commit *commit)
for_each_ref(add_pending_uninteresting_ref, &revs);
+ refs = revs.pending;
+ revs.leak_pending = 1;
+
if (prepare_revision_walk(&revs))
die(_("internal error in revision walk"));
if (!(commit->object.flags & UNINTERESTING))
@@ -690,8 +684,13 @@ static void orphaned_commit_warning(struct commit *commit)
else
describe_detached_head(_("Previous HEAD position was"), commit);
- clear_commit_marks(commit, -1);
- for_each_ref(clear_commit_marks_from_one_ref, NULL);
+ for (i = 0; i < refs.nr; i++) {
+ struct object *o = refs.objects[i].item;
+ struct commit *c = lookup_commit_reference_gently(o->sha1, 1);
+ if (c)
+ clear_commit_marks(c, ALL_REV_FLAGS);
+ }
+ free(refs.objects);
}
static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
--
1.7.7
^ permalink raw reply related
* [PATCH 6/8] bundle: use leak_pending flag
From: René Scharfe @ 2011-10-01 16:02 UTC (permalink / raw)
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8731AF.2040305@lsrfire.ath.cx>
Instead of creating a copy of the list of pending objects, copy the
struct object_array that points to it, turn on leak_pending, and thus
cause prepare_revision_walk to leave it to us. And free it once
we're done.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
bundle.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/bundle.c b/bundle.c
index f48fd7d..26cc9ab 100644
--- a/bundle.c
+++ b/bundle.c
@@ -122,11 +122,8 @@ int verify_bundle(struct bundle_header *header, int verbose)
req_nr = revs.pending.nr;
setup_revisions(2, argv, &revs, NULL);
- memset(&refs, 0, sizeof(struct object_array));
- for (i = 0; i < revs.pending.nr; i++) {
- struct object_array_entry *e = revs.pending.objects + i;
- add_object_array(e->item, e->name, &refs);
- }
+ refs = revs.pending;
+ revs.leak_pending = 1;
if (prepare_revision_walk(&revs))
die("revision walk setup failed");
@@ -146,6 +143,7 @@ int verify_bundle(struct bundle_header *header, int verbose)
for (i = 0; i < refs.nr; i++)
clear_commit_marks((struct commit *)refs.objects[i].item, -1);
+ free(refs.objects);
if (verbose) {
struct ref_list *r;
--
1.7.7
^ permalink raw reply related
* [PATCH 5/8] bisect: use leak_pending flag
From: René Scharfe @ 2011-10-01 16:01 UTC (permalink / raw)
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8731AF.2040305@lsrfire.ath.cx>
Instead of creating a copy of the list of pending objects, copy the
struct object_array that points to it, turn on leak_pending, and thus
cause prepare_revision_walk to leave it to us. And free it once
we're done.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
bisect.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/bisect.c b/bisect.c
index c7b7d79..a05504f 100644
--- a/bisect.c
+++ b/bisect.c
@@ -831,12 +831,14 @@ static int check_ancestors(const char *prefix)
bisect_rev_setup(&revs, prefix, "^%s", "%s", 0);
/* Save pending objects, so they can be cleaned up later. */
- memset(&pending_copy, 0, sizeof(pending_copy));
- for (i = 0; i < revs.pending.nr; i++)
- add_object_array(revs.pending.objects[i].item,
- revs.pending.objects[i].name,
- &pending_copy);
+ pending_copy = revs.pending;
+ revs.leak_pending = 1;
+ /*
+ * bisect_common calls prepare_revision_walk right away, which
+ * (together with .leak_pending = 1) makes us the sole owner of
+ * the list of pending objects.
+ */
bisect_common(&revs);
res = (revs.commits != NULL);
@@ -845,6 +847,7 @@ static int check_ancestors(const char *prefix)
struct object *o = pending_copy.objects[i].item;
clear_commit_marks((struct commit *)o, ALL_REV_FLAGS);
}
+ free(pending_copy.objects);
return res;
}
--
1.7.7
^ permalink raw reply related
* [PATCH 4/8] revision: add leak_pending flag
From: René Scharfe @ 2011-10-01 15:56 UTC (permalink / raw)
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8731AF.2040305@lsrfire.ath.cx>
The new flag leak_pending in struct rev_info can be used to prevent
prepare_revision_walk from freeing the list of pending objects. It
will still forget about them, so it really is leaked. This behaviour
may look weird at first, but it can be useful if the pointer to the
list is saved before calling prepare_revision_walk.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
The next three patches are going to use this flag.
revision.c | 3 ++-
revision.h | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 2e8aa33..6d329b4 100644
--- a/revision.c
+++ b/revision.c
@@ -1974,7 +1974,8 @@ int prepare_revision_walk(struct rev_info *revs)
}
e++;
}
- free(list);
+ if (!revs->leak_pending)
+ free(list);
if (revs->no_walk)
return 0;
diff --git a/revision.h b/revision.h
index 4541265..366a9b4 100644
--- a/revision.h
+++ b/revision.h
@@ -97,6 +97,7 @@ struct rev_info {
date_mode_explicit:1,
preserve_subject:1;
unsigned int disable_stdin:1;
+ unsigned int leak_pending:1;
enum date_mode date_mode;
--
1.7.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox