* Re: Git, Mac OS X and German special characters
From: Andreas Ericsson @ 2011-10-01 14:24 UTC (permalink / raw)
To: Albert Zeyer, Git Mailing List
In-Reply-To: <CAO1Q+jeLEp2ReNc9eOFoJxdGq6oRE3b+O=JvMNU0Kqx_eAX=7w@mail.gmail.com>
Please don't cull the list when replying. Reply-to-all is the
standard on git@vger.
On 10/01/2011 08:57 AM, Albert Zeyer wrote:
> On Sat, Oct 1, 2011 at 3:39 PM, Andreas Ericsson<ae@op5.se> wrote:
>> On 10/01/2011 07:44 AM, Albert Zeyer wrote:
>>> Hi,
>>>
>>> There are problems on MacOSX with different UTF8 encodings of
>>> filenames. A unicode string has multiple ways to be represented as
>>> UTF8 and Git treats them as different filenames. This is the actual
>>> bug. It should treat them all as the same filename. In some cases (as
>>> on MacOSX), the underlying operating system may use a normalized UTF8
>>> representation in some sort, i.e. change the actual UTF8 filename
>>> representation.
>>>
>>> Similar problems also exists in SVN, for example. This was reported
>>> [here](http://subversion.tigris.org/issues/show_bug.cgi?id=2464).
>>> There you can find also lengthy discussions about the topic. And also
>>> [here](http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames).
>>>
>>> This was already reported for Git earlier and there is also a patch
>>> for Git [here](http://lists-archives.org/git/719832-git-mac-os-x-and-german-special-characters.html).
>>>
>>> I wonder about the state of this. This hasn't been applied yet. Why?
>>>
>>
>> Because the patch didn't address repositories carrying files with
>> more than one possible representation of the filename and that
>> could have lead to silent loss of data for unsuspecting users.
>>
>> The real solution to your problem is, unfortunately, to either use
>> a different and more competent filesystem, or to avoid triggering
>> the bugs in the one you're currently using.
>
> Well, I think it is a bug in Git itself that it treats different UTF8
> representations of the same filename as different filenames. It
> shouldn't have allowed such in the first place.
>
> But I see your point. I guess I will work myself on a patch here or
> extend that one.
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. There are other, far more
"interesting" cases when you involve special chars such as the
german umlaut, or the swedish åäö characters.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: René Scharfe @ 2011-10-01 15:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Fick, Julian Phillips, Christian Couder, git,
Christian Couder, Thomas Rast
In-Reply-To: <4E8607B6.2040800@lsrfire.ath.cx>
Am 30.09.2011 20:17, schrieb René Scharfe:
> Am 30.09.2011 18:52, schrieb Junio C Hamano:
>> It might be a better solution to not bother to clear the marks at
>> all; would it break anything in this codepath?
>
> Unfortunately, yes; the cleanup part was added by 5c08dc48 later,
> when it become apparent that it's really needed.
>
> However, since the patch only buys us a 5% speedup I'm not sure it's
> worth it in its current form.
I found something better: A trick used by bisect and bundle. They copy
the list of pending objects from rev_info before calling
prepare_revision_walk and then go through it to clean up the commit
marks without going through the refs again. And I think we can even
improve it a little.
The following patches tighten some orphan/detached head tests a little,
then comes a resend of my first patch on this topic, only split up into
two, then four patches that introduce the trick mentioned above (which
could be squashed together perhaps) and the last one is a bonus
refactoring patch.
bisect.c | 20 +++++++-------
builtin/checkout.c | 58 +++++++++++++------------------------------
bundle.c | 11 +++-----
commit.c | 14 ++++++++++
commit.h | 1 +
revision.c | 14 +++++++---
revision.h | 2 +
t/t2020-checkout-detach.sh | 7 ++++-
8 files changed, 64 insertions(+), 63 deletions(-)
René
^ permalink raw reply
* [PATCH 1/8] checkout: check for "Previous HEAD" notice in t2020
From: René Scharfe @ 2011-10-01 15:38 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>
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.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
t/t2020-checkout-detach.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
index 2366f0f..068fba4 100755
--- a/t/t2020-checkout-detach.sh
+++ b/t/t2020-checkout-detach.sh
@@ -12,11 +12,14 @@ check_not_detached () {
}
ORPHAN_WARNING='you are leaving .* commit.*behind'
+PREV_HEAD_DESC='Previous HEAD position was'
check_orphan_warning() {
- test_i18ngrep "$ORPHAN_WARNING" "$1"
+ test_i18ngrep "$ORPHAN_WARNING" "$1" &&
+ test_i18ngrep ! "$PREV_HEAD_DESC" "$1"
}
check_no_orphan_warning() {
- test_i18ngrep ! "$ORPHAN_WARNING" "$1"
+ test_i18ngrep ! "$ORPHAN_WARNING" "$1" &&
+ test_i18ngrep "$PREV_HEAD_DESC" "$1"
}
reset () {
--
1.7.7
^ permalink raw reply related
* [PATCH 2/8] revision: factor out add_pending_sha1
From: René Scharfe @ 2011-10-01 15:43 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>
This function is a combination of the static get_reference and
add_pending_object. It can be used to easily queue objects by hash.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
The next patch is going to use it in checkout.
revision.c | 11 ++++++++---
revision.h | 1 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/revision.c b/revision.c
index c46cfaa..2e8aa33 100644
--- a/revision.c
+++ b/revision.c
@@ -185,6 +185,13 @@ static struct object *get_reference(struct rev_info *revs, const char *name, con
return object;
}
+void add_pending_sha1(struct rev_info *revs, const char *name,
+ const unsigned char *sha1, unsigned int flags)
+{
+ struct object *object = get_reference(revs, name, sha1, flags);
+ add_pending_object(revs, object, name);
+}
+
static struct commit *handle_commit(struct rev_info *revs, struct object *object, const char *name)
{
unsigned long flags = object->flags;
@@ -832,9 +839,7 @@ struct all_refs_cb {
static int handle_one_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
{
struct all_refs_cb *cb = cb_data;
- struct object *object = get_reference(cb->all_revs, path, sha1,
- cb->all_flags);
- add_pending_object(cb->all_revs, object, path);
+ add_pending_sha1(cb->all_revs, path, sha1, cb->all_flags);
return 0;
}
diff --git a/revision.h b/revision.h
index 3d64ada..4541265 100644
--- a/revision.h
+++ b/revision.h
@@ -191,6 +191,7 @@ extern void add_object(struct object *obj,
const char *name);
extern void add_pending_object(struct rev_info *revs, struct object *obj, const char *name);
+extern void add_pending_sha1(struct rev_info *revs, const char *name, const unsigned char *sha1, unsigned int flags);
extern void add_head_to_pending(struct rev_info *);
--
1.7.7
^ permalink raw reply related
* [PATCH 3/8] checkout: use add_pending_{object,sha1} in orphan check
From: René Scharfe @ 2011-10-01 15:51 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 building a list of textual arguments for setup_revisions, use
add_pending_object and add_pending_sha1 to queue the objects directly.
This is both faster and simpler.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin/checkout.c | 39 ++++++++++++---------------------------
1 files changed, 12 insertions(+), 27 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 5e356a6..84e0cdc 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -588,24 +588,11 @@ static void update_refs_for_switch(struct checkout_opts *opts,
report_tracking(new);
}
-struct rev_list_args {
- int argc;
- int alloc;
- const char **argv;
-};
-
-static void add_one_rev_list_arg(struct rev_list_args *args, const char *s)
-{
- ALLOC_GROW(args->argv, args->argc + 1, args->alloc);
- args->argv[args->argc++] = s;
-}
-
-static int add_one_ref_to_rev_list_arg(const char *refname,
- const unsigned char *sha1,
- int flags,
- void *cb_data)
+static int add_pending_uninteresting_ref(const char *refname,
+ const unsigned char *sha1,
+ int flags, void *cb_data)
{
- add_one_rev_list_arg(cb_data, refname);
+ add_pending_sha1(cb_data, refname, sha1, flags | UNINTERESTING);
return 0;
}
@@ -685,19 +672,17 @@ static void suggest_reattach(struct commit *commit, struct rev_info *revs)
*/
static void orphaned_commit_warning(struct commit *commit)
{
- struct rev_list_args args = { 0, 0, NULL };
struct rev_info revs;
-
- add_one_rev_list_arg(&args, "(internal)");
- add_one_rev_list_arg(&args, sha1_to_hex(commit->object.sha1));
- add_one_rev_list_arg(&args, "--not");
- for_each_ref(add_one_ref_to_rev_list_arg, &args);
- add_one_rev_list_arg(&args, "--");
- add_one_rev_list_arg(&args, NULL);
+ struct object *object = &commit->object;
init_revisions(&revs, NULL);
- if (setup_revisions(args.argc - 1, args.argv, &revs, NULL) != 1)
- die(_("internal error: only -- alone should have been left"));
+ setup_revisions(0, NULL, &revs, NULL);
+
+ object->flags &= ~UNINTERESTING;
+ add_pending_object(&revs, object, sha1_to_hex(object->sha1));
+
+ for_each_ref(add_pending_uninteresting_ref, &revs);
+
if (prepare_revision_walk(&revs))
die(_("internal error in revision walk"));
if (!(commit->object.flags & UNINTERESTING))
--
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
* [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 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 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 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 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 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] 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
* 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
* 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: 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 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
* [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: 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
* 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: [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: 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: 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: [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: 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
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