* 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
* [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 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 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
* 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
* 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: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-10-01 14:11 UTC (permalink / raw)
To: Peter Shenkin; +Cc: git
In-Reply-To: <loom.20111001T073652-884@post.gmane.org>
On Sat, Oct 1, 2011 at 05:40, Peter Shenkin <shenkin@gmail.com> wrote:
> Michael Witten <mfwitten <at> gmail.com> writes:
>> Well, you're missing the fact that it not only causes those to
>> be downloaded, but it also causes the defaults to be ignored,
>> which is why you don't get the other stuff. You can still tell
>> git to fetch anything else you want in addition.
>
> I was no longer missing it at the time I posted.
>
> But that is indeed what I was missing when I first encountered
> the behavior. The purpose of posting was to point out that
> with a very small change in the documentation, I would not
> have missed it.
However, my point was this:
You can still tell git to fetch anything else you want in addition.
That point doesn't seem clear with your proposed alteration.
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Andreas Ericsson @ 2011-10-01 13:39 UTC (permalink / raw)
To: Albert Zeyer; +Cc: git
In-Reply-To: <CAO1Q+jf=RO=sE90-mQdi+=fUWH1RLM+JTubSgSVGC5uDyhU+2A@mail.gmail.com>
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.
--
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: Does git have "Path-Based Authorization"?
From: Jakub Narebski @ 2011-10-01 13:06 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw0QXkNSF8+qGu+pCrv5dgy1OEvtq-53f23GRd4RrZ1GcQ@mail.gmail.com>
Grant <emailgrant@gmail.com> writes:
> Hello, I'm trying to decide between git and subversion. Subversion
> has "Path-Based Authorization" so I can give a developer access to
> only specific files instead of everything. Does git have something
> similar?
>
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
In distributed version control systems each developers gets full copy
(a clone) of a repository (separate repository instance). This means that
if you want for developer to see only specified subset of repository
(specific subdirectories) you would have to split repository into
submodules, and control access on (sub)repository basis.
However if you want only to prevent developer from making changes outside
specific subdirectory or specified files, you can do that on publish time
via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
repository management tool such as Gitolite. That would prevent a push if
any of commits being published touches files that it shouldn't.
P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
writes that social solutions wrt. restricting contributors to given area
are better than technical solutions such as (overly-)strict access
control.
HTH
--
Jakub Narębski
^ permalink raw reply
* Git, Mac OS X and German special characters
From: Albert Zeyer @ 2011-10-01 12:44 UTC (permalink / raw)
To: git
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?
Regards,
Albert
^ 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