* [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
* 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 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: 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
* 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: 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
* Re: Git, Mac OS X and German special characters
From: Albert Zeyer @ 2011-10-01 23:48 UTC (permalink / raw)
To: Michael Witten; +Cc: Andreas Krey, Andreas Ericsson, Git Mailing List
In-Reply-To: <CAMOZ1BuXiQkZG_7mvay-ybm7Q7niwXVhbmbCmkfy=wD1AKsasQ@mail.gmail.com>
On Sun, Oct 2, 2011 at 12:02 AM, Michael Witten <mfwitten@gmail.com> wrote:
> 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.
I just read the very lengthy discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/70688
Basically all the arguments have already been discussed.
There are varios options. Most of them are not mutual exclusive, so it
would also be an option to implement most of them and let the user
pick what (s)he prefers.
* TreatFilenamesAsText or however you would call it. I.e. handle
filenames the same when they equal in Unicode.
Linus is very much against this because in rare situations, it could
destroy your data, like in this example:
echo "foo" > Hütte # "Hütte" in NFC
echo "bar" > Hütte # "Hütte" in NFD
The second write would overwrite silently the file generated by the
first write if those filenames would be handled the same. This (and
such) behavior is to be avoided, claims Linus, because it would more
often lead to not wanted behavior in third party applications.
* On MacOSX, wrap all filesystem functions (like readdir()) to convert
all filenames to NFC.
MacOSX normalizes the UTF8 representation of the filenames to NFD but
in most common situations (on most other systems), you end up with the
filename being in NFC.
As the filename is anyway normalized on OSX, it doesn't matter wether
it is handled as NFC or NFD and NFC will likely generate less trouble.
And this patch doesn't even really need an option.
This was one suggestion by Linus itself:
http://news.gmane.org/find-root.php?message_id=%3calpine.LFD.1.00.0801211323120.2957%40woody.linux%2dfoundation.org%3e
* Disallow any files with filenames which are not in NFC at all. This
makes some things a bit more safe (like on MacOSX; along with the
previous suggestion) and more clear (you always know that your
filename is in NFC).
* Some more clever readdir() which, when it gets a filename which is
not in the Git index but Unicode-equally to one filename in the Git
index, automatically replaces it by the filename in the index.
This is some sort of half way to a TreatFilenamesAsText option but
should produce less trouble.
This probably also doesn't need an extra option as it should very
likely generate less trouble (on OSX at least; and for other systems
which don't mangle the filename, they don't need to use this code at
all).
---
I will probably go and try to implement the clever-readdir(). And/or
maybe also the NFC conversation in such a readdir() wrapper.
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Grant @ 2011-10-02 0:00 UTC (permalink / raw)
To: git
In-Reply-To: <m3lit4oo9q.fsf@localhost.localdomain>
>> 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.
I do want to prevent reading of all but one or a few specified files
at a time. I did some reading on the differences between centralized
and distributed version control systems, and I can see how a
distributed system may be better for open source projects, but a
business project like mine may work better with centralized control.
Would you guys agree in general? Easier read/write control of
individual files in the repository is one benefit of the centralized
model I will put to use.
> 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.
When I started this thread, I didn't realize the fact that my project
is not open-source would help decide which version control system to
use. Now I see that it does factor into the decision so I apologize
for not mentioning it previously.
- Grant
^ permalink raw reply
* [PATCHv3] git-web--browse: avoid the use of eval
From: Chris Packham @ 2011-10-02 0:44 UTC (permalink / raw)
To: git; +Cc: gitster, peff, chriscool, Chris Packham
Using eval causes problems when the URL contains an appropriately
escaped ampersand (\&). Dropping eval from the built-in browser
invocation avoids the problem.
Helped-by: Jeff King <peff@peff.net> (test case)
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
The consensus from the last round of discussion [1] seemed to be to
remove the eval from the built in browsers but quote custom browser
commands appropriately.
I've expanded the tests a little. A semi-colon had the same error as
the ampersand. A hash was another common character that had meaning in
a shell and in URL.
[1] http://article.gmane.org/gmane.comp.version-control.git/181671
git-web--browse.sh | 10 +++++-----
t/t9901-git-web--browse.sh | 37 +++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 5 deletions(-)
create mode 100755 t/t9901-git-web--browse.sh
diff --git a/git-web--browse.sh b/git-web--browse.sh
index e9de241..1e82726 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -156,7 +156,7 @@ firefox|iceweasel|seamonkey|iceape)
;;
google-chrome|chrome|chromium|chromium-browser)
# No need to specify newTab. It's default in chromium
- eval "$browser_path" "$@" &
+ "$browser_path" "$@" &
;;
konqueror)
case "$(basename "$browser_path")" in
@@ -164,10 +164,10 @@ konqueror)
# It's simpler to use kfmclient to open a new tab in konqueror.
browser_path="$(echo "$browser_path" | sed -e 's/konqueror$/kfmclient/')"
type "$browser_path" > /dev/null 2>&1 || die "No '$browser_path' found."
- eval "$browser_path" newTab "$@"
+ "$browser_path" newTab "$@" &
;;
kfmclient)
- eval "$browser_path" newTab "$@"
+ "$browser_path" newTab "$@" &
;;
*)
"$browser_path" "$@" &
@@ -175,7 +175,7 @@ konqueror)
esac
;;
w3m|elinks|links|lynx|open)
- eval "$browser_path" "$@"
+ "$browser_path" "$@"
;;
start)
exec "$browser_path" '"web-browse"' "$@"
@@ -185,7 +185,7 @@ opera|dillo)
;;
*)
if test -n "$browser_cmd"; then
- ( eval $browser_cmd "$@" )
+ ( eval "$browser_cmd \"\$@\"" )
fi
;;
esac
diff --git a/t/t9901-git-web--browse.sh b/t/t9901-git-web--browse.sh
new file mode 100755
index 0000000..c6f48a9
--- /dev/null
+++ b/t/t9901-git-web--browse.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+#
+
+test_description='git web--browse basic tests
+
+This test checks that git web--browse can handle various valid URLs.'
+
+. ./test-lib.sh
+
+test_expect_success \
+ 'URL with an ampersand in it' '
+ echo http://example.com/foo\&bar >expect &&
+ git config browser.custom.cmd echo &&
+ git web--browse --browser=custom \
+ http://example.com/foo\&bar >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success \
+ 'URL with a semi-colon in it' '
+ echo http://example.com/foo\;bar >expect &&
+ git config browser.custom.cmd echo &&
+ git web--browse --browser=custom \
+ http://example.com/foo\;bar >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success \
+ 'URL with a hash in it' '
+ echo http://example.com/foo#bar >expect &&
+ git config browser.custom.cmd echo &&
+ git web--browse --browser=custom \
+ http://example.com/foo#bar >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
1.7.7
^ permalink raw reply related
* Re: Does git have "Path-Based Authorization"?
From: Sitaram Chamarty @ 2011-10-02 1:27 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw3kzAgaVBKNHE5ttJgYnc_csjeHjOLq=EBjLizW=RPUkA@mail.gmail.com>
On Sun, Oct 2, 2011 at 5:30 AM, Grant <emailgrant@gmail.com> wrote:
>>> 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.
>
> I do want to prevent reading of all but one or a few specified files
> at a time. I did some reading on the differences between centralized
> and distributed version control systems, and I can see how a
> distributed system may be better for open source projects, but a
> business project like mine may work better with centralized control.
> Would you guys agree in general? Easier read/write control of
> individual files in the repository is one benefit of the centralized
> model I will put to use.
>
>> 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.
>
> When I started this thread, I didn't realize the fact that my project
> is not open-source would help decide which version control system to
> use. Now I see that it does factor into the decision so I apologize
> for not mentioning it previously.
I'm afraid I did not follow the full thread, but I can assure you we
have several "secret secret" type projects at work, both mine as well
as many others.
There are a few occasions when they need the kind of stuff you seem to
want more regularly, (the only one I can really recall is one of our
largest customers has a custom version of one of our product for
themselves and do not want people working on the generic version to
see those changes in case they propagate to their competitors). We
just do that by using a different repo entirely, and making sure
changes to common code migrate only one way.
Git has too many advantages over legacy VCSs like SVN for people to
throw it over for something as simple as this.
^ 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