* Re: [PATCH v8 00/11] Git filter protocol
From: Lars Schneider @ 2016-09-29 10:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Stefan Beller, Jakub Narębski,
Martin-Louis Bright, Torsten Bögershausen, ramsay
In-Reply-To: <xmqq8tubitjs.fsf@gitster.mtv.corp.google.com>
> On 28 Sep 2016, at 23:49, Junio C Hamano <gitster@pobox.com> wrote:
>
> I suspect that you are preparing a reroll already, but the one that
> is sitting in 'pu' seems to be flaky in t/t0021 and I seem to see
> occasional failures from it.
>
> I didn't trace where the test goes wrong, but one easy mistake you
> could make (I am not saying that is the reason of the failure) is to
> assume your filter will not be called under certain condition (like
> immediately after you checked out from the index to the working
> tree), when the automated test goes fast enough and get you into a
> "racy git" situation---the filter may be asked to filter the
> contents from the working tree again to re-validate what's there is
> still what is in the index.
Thanks for the heads-up!
This is what happens:
1) Git exits
2) The filter process receives EOF and prints "STOP" to the log
3) t0021 checks the content of the log
Sometimes 3 happened before 2 which makes the test fail.
(Example: https://travis-ci.org/git/git/jobs/162660563 )
I added a this to wait until the filter process terminates:
+wait_for_filter_termination () {
+ while ps | grep -v grep | grep -F "/t0021/rot13-filter.pl" >/dev/null 2>&1
+ do
+ echo "Waiting for /t0021/rot13-filter.pl to finish..."
+ sleep 1
+ done
+}
Does this look OK to you?
- Lars
^ permalink raw reply
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Matthieu Moy @ 2016-09-29 10:03 UTC (permalink / raw)
To: Jeff King; +Cc: SZEDER Gábor, Junio C Hamano, torvalds, git
In-Reply-To: <20160929091509.2n4mdrevwxechqol@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Sep 29, 2016 at 04:44:00AM +0200, SZEDER Gábor wrote:
>
>> > So 12 seems reasonable, and the only downside for it (or for "13", for
>> > that matter) is a few extra bytes. I dunno, maybe people will really
>> > hate that, but I have a feeling these are mostly cut-and-pasted anyway.
>>
>> I for one raise my hand in protest...
>>
>> "few extra bytes" is not the only downside, and it's not at all about
>> how many characters are copy-and-pasted. In my opinion it's much more
>> important that this change wastes 5 columns worth of valuable screen
>> real estate e.g. for 'git blame' or 'git log --oneline' in projects
>> that don't need it and certainly won't ever need it.
>
> True. The core of the issue is that we really only care about this
> minimum length when _storing_ an abbreviation, but we don't know when
> the user is just looking at it in the moment, and when they are going to
> stick it in a commit message, email, or bug tracker.
Perhaps a compromise would be to adapt the length to the size of the
project _and_ keep a huge margin. So, essentially, we'd have small
projects stick to the 7 characters, and very quickly bump to 12.
So, for a fast-growing project, there would be a short window at the
beginning of the project where people could cut-and-past short hashes.
OTOH, small projects could keep these few columns of screen real-estate.
That said, I can certainly live without these 5 columns, don't take my
message as an objection to setting to 12 right away.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 1/4] config: allow customizing /etc/gitconfig location
From: Jakub Narębski @ 2016-09-29 9:53 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Jeff King, Linus Torvalds
In-Reply-To: <20160928233047.14313-2-gitster@pobox.com>
W dniu 29.09.2016 o 01:30, Junio C Hamano pisze:
> With a new environment variable GIT_ETC_GITCONFIG, the users can
> specify a file that is used instead of /etc/gitconfig to read (and
> write) the system-wide configuration.
Why it is named GIT_ETC_GITCONFIG (which is Unix-ism), and not
GIT_CONFIG_SYSTEM / GIT_CONFIG_SYSTEM_PATH, that is something
OS-neutral?
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH v7 10/10] convert: add filter.<driver>.process option
From: Jakub Narębski @ 2016-09-29 9:37 UTC (permalink / raw)
To: Torsten Bögershausen, Junio C Hamano, Lars Schneider
Cc: Git Mailing List, Jeff King, Stefan Beller, Johannes Schindelin,
Martin-Louis Bright, Jacob Keller
In-Reply-To: <30461d2d-5a9c-4b0c-25a0-aa3327622764@web.de>
W dniu 29.09.2016 o 08:33, Torsten Bögershausen pisze:
> On 15.09.16 22:04, Junio C Hamano wrote:
>> Lars Schneider <larsxschneider@gmail.com> writes:
>>
>>> Wouldn't that complicate the pathname parsing on the filter side?
>>> Can't we just define in our filter protocol documentation that our
>>> "pathname" packet _always_ has a trailing "\n"? That would mean the
>>> receiver would know a packet "pathname=ABC\n\n" encodes the path
>>> "ABC\n" [1].
>>
>> That's fine, too. If you declare that pathname over the protocol is
>> a binary thing, you can also define that the packet does not have
>> the terminating \n, i.e. the example encodes the path "ABC\n\n",
>> which is also OK ;-)
>>
>> As long as the rule is clearly documented, easy for filter
>> implementors to follow it, and hard for them to get it wrong, I'd be
>> perfectly happy.
>>
>
> (Sorry for the late reply)
>
> In V8 the additional "\n" is clearly documented.
>
> On the long run,
> I would suggest to be more clear what BINARY is:
>
> --- a/Documentation/technical/protocol-common.txt
> +++ b/Documentation/technical/protocol-common.txt
> @@ -61,6 +61,9 @@ the length's hexadecimal representation.
> A pkt-line MAY contain binary data, so implementors MUST ensure
> pkt-line parsing/formatting routines are 8-bit clean.
>
> +Each pkt-line that may contain ASCII control characters should
> +be treated as binary.
> +
Well, it is not as clear cut with pathnames. Sane pathnames should
not contain control characters, even if they are outside US-ASCII,
assuming sane filesystem pathnames charset (like UTF-8).
One thing pathname cannot include is NUL ("\0") character.
So in most cases they are ASCII, but might not be. Not that
pkt-line text packets are binary-unsafe... I think the trailing
"\n" is here for easier debugging.
http://www.dwheeler.com/essays/filenames-in-shell.html
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Jeff King @ 2016-09-29 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, torvalds
In-Reply-To: <20160928233047.14313-5-gitster@pobox.com>
On Wed, Sep 28, 2016 at 04:30:47PM -0700, Junio C Hamano wrote:
> As Peff said, responding in a thread started by Linus's suggestion
> to raise the default abbreviation to 12 hexdigits:
>
> I actually think "12" might be sane for a long time. That's 48 bits of
> sha1, so we'd expect a 50% change of a _single_ collision at 2^24, or 16
> million. The biggest repository I know about (in number of objects) is
> the one holding all of the objects for all of the forks of
> torvalds/linux on GitHub. It's at about 15 million objects.
>
> Which _seems_ close, but remember that's the size where we expect to see
> a single collision. They don't become common until much later (I didn't
> compute an exact number, but Linus's 16x sounds about right). I know
> that the growth of the kernel isn't really linear, but I think the need
> to bump to "13" might not just be decades, but possibly a century or
> more.
>
> So 12 seems reasonable, and the only downside for it (or for "13", for
> that matter) is a few extra bytes. I dunno, maybe people will really
> hate that, but I have a feeling these are mostly cut-and-pasted anyway.
I am not sure my quote is a good rationale for this bump. It was meant
to be a rationale that "12" is big enough, but the "I dunno" at the end
kind of glosses over the downsides.
-Peff
^ permalink raw reply
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Jeff King @ 2016-09-29 9:22 UTC (permalink / raw)
To: Lukas Fleischer; +Cc: git, SZEDER Gábor, torvalds
In-Reply-To: <147512682170.7989.11263315726387435240@typhoon>
On Thu, Sep 29, 2016 at 07:27:01AM +0200, Lukas Fleischer wrote:
> > Sure, users working on smaller repos are free to reset core.abbrev to
> > its original value. I don't have any numbers, of course, but I
> > suspect that there are many more smaller repos out there that this
> > change will affect disadvantageously, than there are large repos for
> > which it's beneficial.
>
> I know this suggestion comes a bit late but would it make sense to let
> the repository owner overwrite the core.abbrev setting?
>
> One possible way to implement this would be adding .gitconfig support to
> repositories with a very limited set of whitelisted variables allowed in
> there (could be core.abbrev only to begin with). Or some entirely
> separate mechanism like .gitignore.
The suggestion for versioned repository-level config comes up from time
to time; you can find other instances in the list archive. Usually the
biggest issue is that usually nobody comes up with a good example of
something that the project would actually want to set. Setting
"core.abbrev" at least seems plausible.
Though...
> With such a mechanism, we could keep the default of 7 which works fine
> for most projects. Linus could bump the default to 12 for linux.git. If
> some users are not happy with that, they can still overwrite it in their
> local Git config. Anybody starting a project could change the initial
> value to a suitable value in one of the first commits -- provided they
> already have an idea how much the project will grow. That way, hashes
> will be "long enough" even for early commits, before any heuristics
> could guess that the project would become large.
I wonder if in practice we would do just as well to size default_abbrev
dynamically based on the number of objects. That doesn't help projects
which are just starting, but will eventually grow gigantic. But I doubt
that most projects would have the foresight to preemptively set
core.abbrev. And that would at least reduce the impact as the project
_does_ get big.
-Peff
^ permalink raw reply
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Jeff King @ 2016-09-29 9:15 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, torvalds, git
In-Reply-To: <20160929024400.22605-1-szeder@ira.uka.de>
On Thu, Sep 29, 2016 at 04:44:00AM +0200, SZEDER Gábor wrote:
> > So 12 seems reasonable, and the only downside for it (or for "13", for
> > that matter) is a few extra bytes. I dunno, maybe people will really
> > hate that, but I have a feeling these are mostly cut-and-pasted anyway.
>
> I for one raise my hand in protest...
>
> "few extra bytes" is not the only downside, and it's not at all about
> how many characters are copy-and-pasted. In my opinion it's much more
> important that this change wastes 5 columns worth of valuable screen
> real estate e.g. for 'git blame' or 'git log --oneline' in projects
> that don't need it and certainly won't ever need it.
True. The core of the issue is that we really only care about this
minimum length when _storing_ an abbreviation, but we don't know when
the user is just looking at it in the moment, and when they are going to
stick it in a commit message, email, or bug tracker.
In an ideal world, anybody who was about to store it would run "git
describe" or something to come up with some canonical reference format.
And we could just bump the default minimum there. Personally, I almost
exclusively cite commits as the output of:
git log -1 --pretty='tformat:%h (%s, %ad)' --date=short
and I'd be fine to stick "--abbrev=12" in there for future-proofing. But
I don't know what the kernel or other projects do.
I'd also be curious to know if the patch I sent in [1] to more
aggressively prefer commits would make this less of an issue, and people
wouldn't care as much about using longer hashes in the first place. So
one option is to merge that (and possibly even make it the default) and
see if people still care in 6 months.
-Peff
[1] http://public-inbox.org/git/20160927123801.3bpdg3hap3kzzfmv@sigill.intra.peff.net/
^ permalink raw reply
* Re: [PATCH 2/4] t13xx: do not assume system config is empty
From: Jeff King @ 2016-09-29 9:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, torvalds
In-Reply-To: <20160928233047.14313-3-gitster@pobox.com>
On Wed, Sep 28, 2016 at 04:30:45PM -0700, Junio C Hamano wrote:
> The tests for show-origin codepath in "git config" however cannot be
> tweaked with "--local" etc., because they wants to read also from
> $HOME/.gitconfig and make sure what comes from where. Disable
> reading from the system-wide config with GIT_CONFIG_NOSYSTEM=1 for
> these tests.
I think anytime you would use GIT_CONFIG_NOSYSTEM over --local, it is an
indication that the test is trying to check how multiple sources
interact. And the right thing to do for them is to set GIT_ETC_GITCONFIG
to some known quantity. We just couldn't do that before, so we skipped
it.
IOW, something like the patch below (on top of yours). Note that the
commands that are doing a "--get" and not a "--list" don't actually seem
to need either (because they are getting the values out of the local
file anyway), so we could drop the setting of GIT_ETC_GITCONFIG from
them entirely.
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index b998568..d2476a8 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1234,6 +1234,11 @@ test_expect_success 'set up --show-origin tests' '
[user]
relative = include
EOF
+ cat >"$HOME"/etc-gitconfig <<-\EOF &&
+ [user]
+ system = true
+ override = system
+ EOF
cat >"$HOME"/.gitconfig <<-EOF &&
[user]
global = true
@@ -1252,6 +1257,8 @@ test_expect_success 'set up --show-origin tests' '
test_expect_success '--show-origin with --list' '
cat >expect <<-EOF &&
+ file:$HOME/etc-gitconfig user.system=true
+ file:$HOME/etc-gitconfig user.override=system
file:$HOME/.gitconfig user.global=true
file:$HOME/.gitconfig user.override=global
file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
@@ -1262,14 +1269,16 @@ test_expect_success '--show-origin with --list' '
file:.git/../include/relative.include user.relative=include
command line: user.cmdline=true
EOF
- GIT_CONFIG_NOSYSTEM=1 \
+ GIT_ETC_GITCONFIG=$HOME/etc-gitconfig \
git -c user.cmdline=true config --list --show-origin >output &&
test_cmp expect output
'
test_expect_success '--show-origin with --list --null' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfigQuser.global
+ file:$HOME/etc-gitconfigQuser.system
+ trueQfile:$HOME/etc-gitconfigQuser.override
+ systemQfile:$HOME/.gitconfigQuser.global
trueQfile:$HOME/.gitconfigQuser.override
globalQfile:$HOME/.gitconfigQinclude.path
$INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
@@ -1280,7 +1289,7 @@ test_expect_success '--show-origin with --list --null' '
includeQcommand line:Quser.cmdline
trueQ
EOF
- GIT_CONFIG_NOSYSTEM=1 \
+ GIT_ETC_GITCONFIG=$HOME/etc-gitconfig \
git -c user.cmdline=true config --null --list --show-origin >output.raw &&
nul_to_q <output.raw >output &&
# The here-doc above adds a newline that the --null output would not
@@ -1304,7 +1313,7 @@ test_expect_success '--show-origin with --get-regexp' '
file:$HOME/.gitconfig user.global true
file:.git/config user.local true
EOF
- GIT_CONFIG_NOSYSTEM=1 \
+ GIT_ETC_GITCONFIG=$HOME/etc-gitconfig \
git config --show-origin --get-regexp "user\.[g|l].*" >output &&
test_cmp expect output
'
@@ -1313,7 +1322,7 @@ test_expect_success '--show-origin getting a single key' '
cat >expect <<-\EOF &&
file:.git/config local
EOF
- GIT_CONFIG_NOSYSTEM=1 \
+ GIT_ETC_GITCONFIG=$HOME/etc-gitconfig \
git config --show-origin user.override >output &&
test_cmp expect output
'
^ permalink raw reply related
* [PATCH 5/5] log: add --commit-header option
From: Jeff King @ 2016-09-29 8:38 UTC (permalink / raw)
To: Kyle J. McKay; +Cc: Git mailing list, Junio C Hamano
In-Reply-To: <20160929083315.vwb3aurwbyjwlkjn@sigill.intra.peff.net>
This lets you stick a header right before a commit, but
suppresses headers that are duplicates. This means you can
do something like:
git log --graph --author-date-order --commit-header='== %as =='
to get a marker in the graph whenever the day changes.
This probably needs some refactoring around the setup of the
pretty-print context.
Signed-off-by: Jeff King <peff@peff.net>
---
log-tree.c | 31 +++++++++++++++++++++++++++++++
revision.c | 4 ++++
revision.h | 3 +++
3 files changed, 38 insertions(+)
diff --git a/log-tree.c b/log-tree.c
index 8c24157..76cef51 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -536,6 +536,28 @@ static void show_mergetag(struct rev_info *opt, struct commit *commit)
for_each_mergetag(show_one_mergetag, commit, opt);
}
+static void show_commit_header(struct rev_info *opt,
+ struct pretty_print_context *pp,
+ struct commit *commit)
+{
+ struct strbuf out = STRBUF_INIT;
+
+ format_commit_message(commit, opt->commit_header, &out, pp);
+ strbuf_complete_line(&out);
+
+ if (!strbuf_cmp(&out, &opt->last_commit_header)) {
+ strbuf_release(&out);
+ return;
+ }
+
+ graph_show_precommit(opt->graph);
+ graph_show_padding(opt->graph);
+ fwrite(out.buf, 1, out.len, opt->diffopt.file);
+
+ strbuf_swap(&out, &opt->last_commit_header);
+ strbuf_release(&out);
+}
+
void show_log(struct rev_info *opt)
{
struct strbuf msgbuf = STRBUF_INIT;
@@ -591,6 +613,15 @@ void show_log(struct rev_info *opt)
}
opt->shown_one = 1;
+ if (opt->commit_header) {
+ /*
+ * XXX probably the initialization of the pretty ctx from "opt"
+ * below should happen sooner so we can use it.
+ */
+ ctx.color = opt->diffopt.use_color;
+ show_commit_header(opt, &ctx, commit);
+ }
+
/*
* If the history graph was requested,
* print the graph, up to this commit's line
diff --git a/revision.c b/revision.c
index 969b3d1..229ff86 100644
--- a/revision.c
+++ b/revision.c
@@ -1361,6 +1361,8 @@ void init_revisions(struct rev_info *revs, const char *prefix)
}
revs->notes_opt.use_default_notes = -1;
+
+ strbuf_init(&revs->last_commit_header, 0);
}
static void add_pending_commit_list(struct rev_info *revs,
@@ -1844,6 +1846,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->verbose_header = 1;
revs->pretty_given = 1;
get_commit_format(arg+9, revs);
+ } else if (skip_prefix(arg, "--commit-header=", &arg)) {
+ revs->commit_header = arg;
} else if (!strcmp(arg, "--expand-tabs")) {
revs->expand_tabs_in_log = 8;
} else if (!strcmp(arg, "--no-expand-tabs")) {
diff --git a/revision.h b/revision.h
index 9fac1a6..39ec092 100644
--- a/revision.h
+++ b/revision.h
@@ -170,6 +170,9 @@ struct rev_info {
int show_log_size;
struct string_list *mailmap;
+ const char *commit_header;
+ struct strbuf last_commit_header;
+
/* Filter by commit log message */
struct grep_opt grep_filter;
/* Negate the match of grep_filter */
--
2.10.0.566.g5365f87
^ permalink raw reply related
* [PATCH 2/5] pretty: allow formatting names as initials
From: Jeff King @ 2016-09-29 8:36 UTC (permalink / raw)
To: Kyle J. McKay; +Cc: Git mailing list, Junio C Hamano
In-Reply-To: <20160929083315.vwb3aurwbyjwlkjn@sigill.intra.peff.net>
Initials are shorter and often unique enough in a
per-project setting, so they can be used to give a more
informative version of --oneline.
The 'S' in the placeholder is for "short" (and 's' is
already taken by DATE_SHORT), but obviously that's pretty
arcane.
Possibly there should be more customization of initials,
asking for only 2-letter initials, etc.
Signed-off-by: Jeff King <peff@peff.net>
---
When I first tested it with "git log --format=%aS" I had to wonder "who
the heck is ntnd?". So using only the first-and-last would match the git
project's practice better, at least.
pretty.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/pretty.c b/pretty.c
index c532c17..de62405 100644
--- a/pretty.c
+++ b/pretty.c
@@ -674,6 +674,23 @@ static int mailmap_name(const char **email, size_t *email_len,
return mail_map->nr && map_user(mail_map, email, email_len, name, name_len);
}
+static void format_initials(struct strbuf *out, const char *name, size_t len)
+{
+ int initial = 1;
+ size_t i;
+
+ for (i = 0; i < len; i++) {
+ char c = name[i];
+ if (isspace(c)) {
+ initial = 1;
+ continue;
+ }
+ if (initial && isalpha(c))
+ strbuf_addch(out, tolower(c));
+ initial = 0;
+ }
+}
+
static size_t format_person_part(struct strbuf *sb, char part,
const char *msg, int len,
const struct date_mode *dmode)
@@ -702,6 +719,10 @@ static size_t format_person_part(struct strbuf *sb, char part,
strbuf_add(sb, mail, maillen);
return placeholder_len;
}
+ if (part == 'S') {
+ format_initials(sb, name, namelen);
+ return placeholder_len;
+ }
if (!s.date_begin)
goto skip;
--
2.10.0.566.g5365f87
^ permalink raw reply related
* [PATCH 4/5] graph: helper functions for printing commit header
From: Jeff King @ 2016-09-29 8:38 UTC (permalink / raw)
To: Kyle J. McKay; +Cc: Git mailing list, Junio C Hamano
In-Reply-To: <20160929083315.vwb3aurwbyjwlkjn@sigill.intra.peff.net>
The idea here is to make it possible to print something
right _before_ a commit in the graph. It's a bit ugly, but
it seems to work.
Signed-off-by: Jeff King <peff@peff.net>
---
graph.c | 14 +++++++++++++-
graph.h | 6 ++++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/graph.c b/graph.c
index d4e8519..56daa70 100644
--- a/graph.c
+++ b/graph.c
@@ -1218,7 +1218,7 @@ int graph_is_commit_finished(struct git_graph const *graph)
return (graph->state == GRAPH_PADDING);
}
-void graph_show_commit(struct git_graph *graph)
+static void graph_show_commit_1(struct git_graph *graph, int only_pre)
{
struct strbuf msgbuf = STRBUF_INIT;
int shown_commit_line = 0;
@@ -1239,6 +1239,8 @@ void graph_show_commit(struct git_graph *graph)
}
while (!shown_commit_line && !graph_is_commit_finished(graph)) {
+ if (only_pre && graph->state == GRAPH_COMMIT)
+ break;
shown_commit_line = graph_next_line(graph, &msgbuf);
fwrite(msgbuf.buf, sizeof(char), msgbuf.len,
graph->revs->diffopt.file);
@@ -1252,6 +1254,16 @@ void graph_show_commit(struct git_graph *graph)
strbuf_release(&msgbuf);
}
+void graph_show_precommit(struct git_graph *graph)
+{
+ graph_show_commit_1(graph, 1);
+}
+
+void graph_show_commit(struct git_graph *graph)
+{
+ graph_show_commit_1(graph, 0);
+}
+
void graph_show_oneline(struct git_graph *graph)
{
struct strbuf msgbuf = STRBUF_INIT;
diff --git a/graph.h b/graph.h
index af62339..e13e97f 100644
--- a/graph.h
+++ b/graph.h
@@ -97,6 +97,12 @@ int graph_width(struct git_graph *graph);
*/
void graph_show_commit(struct git_graph *graph);
+/*
+ * Same as graph_show_commit, but stop just _before_ printing
+ * the actual commit line.
+ */
+void graph_show_precommit(struct git_graph *graph);
+
/*
* If the graph is non-NULL, print one line of the history graph to stdout.
* Does not print a terminating newline on the last line.
--
2.10.0.566.g5365f87
^ permalink raw reply related
* [PATCH 3/5] graph: fix extra spaces in graph_padding_line
From: Jeff King @ 2016-09-29 8:37 UTC (permalink / raw)
To: Kyle J. McKay; +Cc: Git mailing list, Junio C Hamano
In-Reply-To: <20160929083315.vwb3aurwbyjwlkjn@sigill.intra.peff.net>
The graph_padding_line() function outputs a series of "|"
columns, and then pads with spaces to graph->width by
calling graph_pad_horizontally(). However, we tell the
latter that we wrote graph->num_columns characters, which is
not true; we also needed spaces between the columns. Let's
keep a count of how many characters we've written, which is
what all the other callers of graph_pad_horizontally() do.
Without this, any output that is written at the end of a
padding line will be bumped out by at least an extra
graph->num_columns spaces. Presumably nobody ever noticed
the bug because there's no code path that actually writes to
the end of a padding line.
Signed-off-by: Jeff King <peff@peff.net>
---
graph.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/graph.c b/graph.c
index 06f1139..d4e8519 100644
--- a/graph.c
+++ b/graph.c
@@ -1175,6 +1175,7 @@ int graph_next_line(struct git_graph *graph, struct strbuf *sb)
static void graph_padding_line(struct git_graph *graph, struct strbuf *sb)
{
int i;
+ int chars_written = 0;
if (graph->state != GRAPH_COMMIT) {
graph_next_line(graph, sb);
@@ -1190,14 +1191,21 @@ static void graph_padding_line(struct git_graph *graph, struct strbuf *sb)
*/
for (i = 0; i < graph->num_columns; i++) {
struct column *col = &graph->columns[i];
+
strbuf_write_column(sb, col, '|');
- if (col->commit == graph->commit && graph->num_parents > 2)
- strbuf_addchars(sb, ' ', (graph->num_parents - 2) * 2);
- else
+ chars_written++;
+
+ if (col->commit == graph->commit && graph->num_parents > 2) {
+ int len = (graph->num_parents - 2) * 2;
+ strbuf_addchars(sb, ' ', len);
+ chars_written += len;
+ } else {
strbuf_addch(sb, ' ');
+ chars_written++;
+ }
}
- graph_pad_horizontally(graph, sb, graph->num_columns);
+ graph_pad_horizontally(graph, sb, chars_written);
/*
* Update graph->prev_state since we have output a padding line
--
2.10.0.566.g5365f87
^ permalink raw reply related
* [PATCH 1/5] pretty: allow formatting DATE_SHORT
From: Jeff King @ 2016-09-29 8:33 UTC (permalink / raw)
To: Kyle J. McKay; +Cc: Git mailing list, Junio C Hamano
In-Reply-To: <20160929083315.vwb3aurwbyjwlkjn@sigill.intra.peff.net>
There's no way to do this short of "%ad" and --date=short,
but that limits you to having a single date format in the
output.
This would possibly be better done with something more like
"%ad(short)".
Signed-off-by: Jeff King <peff@peff.net>
---
pretty.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/pretty.c b/pretty.c
index 493edb0..c532c17 100644
--- a/pretty.c
+++ b/pretty.c
@@ -727,6 +727,9 @@ static size_t format_person_part(struct strbuf *sb, char part,
case 'I': /* date, ISO 8601 strict */
strbuf_addstr(sb, show_ident_date(&s, DATE_MODE(ISO8601_STRICT)));
return placeholder_len;
+ case 's':
+ strbuf_addstr(sb, show_ident_date(&s, DATE_MODE(SHORT)));
+ return placeholder_len;
}
skip:
--
2.10.0.566.g5365f87
^ permalink raw reply related
* Re: [PATCH/RFC] git log --oneline alternative with dates, times and initials
From: Jeff King @ 2016-09-29 8:33 UTC (permalink / raw)
To: Kyle J. McKay; +Cc: Git mailing list, Junio C Hamano
In-Reply-To: <git-log-times@mackyle-at-gmail-com>
On Wed, Sep 28, 2016 at 10:34:51PM -0700, Kyle J. McKay wrote:
> git log-times --graph --date-order --decorate --no-merges -n 5 v2.5.3
>
> === 2015-09-17 ===
> * ee6ad5f4 12:16 jch (tag: v2.5.3) Git 2.5.3
> === 2015-09-09 ===
> * b9d66899 14:22 js am --skip/--abort: merge HEAD/ORIG_HEAD tree into index
> | === 2015-09-04 ===
> | * 27ea6f85 10:46 jch (tag: v2.5.2) Git 2.5.2
> * 74b67638 10:36 jch (tag: v2.4.9) Git 2.4.9
> ..........
> * ecad27cf 10:32 jch (tag: v2.3.9) Git 2.3.9
I was surprised to see this as a separate script, but it is true that we
cannot quite pull it off with --format. I think we are very close,
though. With the patches below I think you can do:
git log \
--commit-header='%C(auto,bold blue)== %as ==%C(auto,reset)'
--format='%C(auto)%h %C(auto,green)%ad %C(auto,red)%aS/%cS%C(auto)%d%C(auto,reset) %s' \
--graph --no-merges --author-date-order --date=format:%H:%M
and get the same (or very similar) output.
[1/5]: pretty: allow formatting DATE_SHORT
[2/5]: pretty: allow formatting names as initials
[3/5]: graph: fix extra spaces in graph_padding_line
[4/5]: graph: helper functions for printing commit header
[5/5]: log: add --commit-header option
Each of those commits[1] needs some minor polish, and as I'm not really
that interested in fancy log output myself, I don't plan on working on
them further. I was mostly curious just how close we were. But if you'd
like to pursue it, feel free to use them as a starting point.
-Peff
[1] Actually, I think patch 3 is a legitimate bug fix on its own but I
do not think there is any way to actually trigger it in practice
without the rest of this series.
^ permalink raw reply
* Re: [PATCH v7 10/10] convert: add filter.<driver>.process option
From: Torsten Bögershausen @ 2016-09-29 6:33 UTC (permalink / raw)
To: Junio C Hamano, Lars Schneider
Cc: Torsten Bögershausen, Git Mailing List, peff, sbeller,
Johannes.Schindelin, jnareb, mlbright, jacob.keller
In-Reply-To: <xmqq37l1nd42.fsf@gitster.mtv.corp.google.com>
On 15.09.16 22:04, Junio C Hamano wrote:
> Lars Schneider <larsxschneider@gmail.com> writes:
>
>> Wouldn't that complicate the pathname parsing on the filter side?
>> Can't we just define in our filter protocol documentation that our
>> "pathname" packet _always_ has a trailing "\n"? That would mean the
>> receiver would know a packet "pathname=ABC\n\n" encodes the path
>> "ABC\n" [1].
>
> That's fine, too. If you declare that pathname over the protocol is
> a binary thing, you can also define that the packet does not have
> the terminating \n, i.e. the example encodes the path "ABC\n\n",
> which is also OK ;-)
>
> As long as the rule is clearly documented, easy for filter
> implementors to follow it, and hard for them to get it wrong, I'd be
> perfectly happy.
>
(Sorry for the late reply)
In V8 the additional "\n" is clearly documented.
On the long run,
I would suggest to be more clear what BINARY is:
--- a/Documentation/technical/protocol-common.txt
+++ b/Documentation/technical/protocol-common.txt
@@ -61,6 +61,9 @@ the length's hexadecimal representation.
A pkt-line MAY contain binary data, so implementors MUST ensure
pkt-line parsing/formatting routines are 8-bit clean.
+Each pkt-line that may contain ASCII control characters should
+be treated as binary.
+
^ permalink raw reply
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Johannes Sixt @ 2016-09-29 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff, torvalds
In-Reply-To: <20160928233047.14313-5-gitster@pobox.com>
Am 29.09.2016 um 01:30 schrieb Junio C Hamano:
> As Peff said, responding in a thread started by Linus's suggestion
> to raise the default abbreviation to 12 hexdigits:
This is waayy too large for a new default. The vast majority of
repositories is smallish. For those, the long sequences of hex digits
are an uglification that is almost unbearable.
I know that kernel developers are important, but their importance has
long been outnumbered by the anonymous and silent masses of users.
Personally, I use 8 digits just because it is a "rounder" number than 7,
but in all of my repositories 7 would still work just as well.
-- Hannes
^ permalink raw reply
* [PATCH/RFC] git log --oneline alternative with dates, times and initials
From: Kyle J. McKay @ 2016-09-29 5:34 UTC (permalink / raw)
To: Git mailing list; +Cc: Junio C Hamano
Simple example output from the Git repository:
git log-times --graph --date-order --decorate --no-merges -n 5 v2.5.3
=== 2015-09-17 ===
* ee6ad5f4 12:16 jch (tag: v2.5.3) Git 2.5.3
=== 2015-09-09 ===
* b9d66899 14:22 js am --skip/--abort: merge HEAD/ORIG_HEAD tree into index
| === 2015-09-04 ===
| * 27ea6f85 10:46 jch (tag: v2.5.2) Git 2.5.2
* 74b67638 10:36 jch (tag: v2.4.9) Git 2.4.9
..........
* ecad27cf 10:32 jch (tag: v2.3.9) Git 2.3.9
I have been wanting a compact one line output format that included dates,
times and initials for some time that is compatible with --graph, clearly
shows root commits and eliminates confusion over whether or not two adjacent
lines in the output are related as parent/child (the --show-linear-break
option does not work with --graph).
The git-log-times utility is the result. Except for --notes, --pretty and
--format options (which would make the output a non-oneline format) any
other `git log` option may be used (including things like --cherry-mark,
--patch, --raw, --stat, --summary, --show-linear-break etc.),
There are a few new options specific to git-log-times which are described
in the README and the `git-log-times -h` output that can be used to alter
the dates, times and/or initials displayed.
The patch below adds a contrib/git-log-times directory containing the
executable (git-log-times) and the README.
--Kyle
P.S. git am complains about 26 lines with whitespace errors. They are
not whitespace errors. The README is in markdown format and they
are explicit line break instructions to markdown (2 trailing blanks).
Removing them would corrupt the markdown output.
P.P.S A picture is worth a thousand words, so the formatted help text,
and several images of actual git-log-times output are available at
https://gist.github.com/mackyle/4c33e4802a8269b3f200f2c00352ce6a
-- 8< --
Subject: [PATCH] contrib/git-log-times: alternative git log --oneline utility
The git-log-times utility provides an alternative interface to using
git log --oneline that includes dates, times and author initials.
Additionally root commits are marked for easy identification and
when using --graph mode breaks are inserted when necessary to prevent
two adjacent output lines from being misconstrued as having a parent
child relationship when they actually do not.
Other than --notes, --pretty and --format options which are not
allowed (because that would no longer be a one line format) all git
log options are available for use.
Output will be colorized using the same rules used for git log
output.
The three extra items in the output (dates, times and initials) use
'color.log-times.date', 'color.log-times.time' and
'color.log-times.initials' to change their default color.
Other options specific to git-log-times may be shown by using the
-h option (i.e. `git-log-times -h`).
One or more default options which behave as though they are the
first option argument(s) on the command line may be set by assigning
them to the 'log-times.defaults' config value as space-separated
options each including its leading '-' or '--'.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
---
contrib/git-log-times/README | 256 ++++++++++++++++++++
contrib/git-log-times/git-log-times | 464 ++++++++++++++++++++++++++++++++++++
2 files changed, 720 insertions(+)
create mode 100644 contrib/git-log-times/README
create mode 100755 contrib/git-log-times/git-log-times
diff --git a/contrib/git-log-times/README b/contrib/git-log-times/README
new file mode 100644
index 00000000..65f1d2c5
--- /dev/null
+++ b/contrib/git-log-times/README
@@ -0,0 +1,256 @@
+git-log-times
+=============
+
+An alterative to `git log --oneline` that includes dates, times and
+author initials in a compact one line output format.
+
+The `--notes`, `--pretty` and `--format` options are not allowed but any
+other `git log` options should work fine including `--graph`.
+
+In both `--graph` and non `--graph` modes:
+
+ * Root commits are identified by `_` on either side of the hash
+
+When `--graph` mode is enabled, the graph output is enhanced as follows:
+
+ * Breaks are inserted when necessary to avoid parent/child ambiguity
+
+
+Installation
+------------
+
+Put the `git-log-times` executable file in one of the directories
+included in the `PATH` environment variable.
+
+Optionally set a global alias to save typing such as `lo` like so:
+
+ git config --global alias.lo log-times
+
+Optionally set global default options such as `--two-initials` and
+`--abbrev=8` like so:
+
+ git config --global log-times.defaults "--two-initials --abbrev=8"
+
+
+Dates & Times
+-------------
+
+Dates and times are shown in the local timezone. Set the TZ variable
+before running `git log-times` (e.g. `TZ=UTC git log-times` to show
+dates and times in UTC) or use the `--time-zone=` option (e.g.
+`git log-times --time-zone=UTC`) to change that.
+
+Dates are shown on a date line all by themselves like so:
+
+ === 2015-11-13 ===
+
+The date line indicates that the times on all the following lines
+(regardless of whether or not `--reverse` is being used) up until
+the next date line take place on the indicated date. For example
+this output:
+
+ === 2015-09-28 ===
+ be08dee9 13:18 jc (tag: v2.6.0) Git 2.6
+ === 2015-09-21 ===
+ 8d530c4d 13:26 jc (tag: v2.6.0-rc3) Git 2.6-rc3
+ 904f6e7c 10:51 bn send-email: fix uninitialized var warning for $
+ === 2015-09-20 ===
+ 18a21c19 09:49 ps l10n: de.po: better language for one string
+ 2e0f3663 09:49 rt l10n: de.po: translate 2 messages
+ 5fc31c1f 09:44 tq l10n: Update and review Vietnamese translation
+
+shows one commit on 2015-09-28, two commits on 2015-09-21 and three
+commits on 2015-09-20.
+
+Note that a date line may appear more than once for the same date
+(this is especially common when using `--graph` with its defualt
+`--topo-order`).
+
+The purpose of a date line is to indicate what date has been elided
+from the following lines, nothing more.
+
+
+Examples
+--------
+
+For example, running `git log-times --decorate --graph -n 17 v2.6.1`
+on the Git repository produces this output (which will be colorized
+on the terminal if color is enabled):
+
+ === 2015-09-28 ===
+ * 22f698cb 19:19 jch (tag: v2.6.1) Git 2.6.1
+ * 3adc4ec7 19:16 jch Sync with v2.5.4
+ |\
+ | * 24358560 15:34 jch (tag: v2.5.4) Git 2.5.4
+ | * 11a458be 15:33 jch Sync with 2.4.10
+ | |\
+ | | * a2558fb8 15:30 jch (tag: v2.4.10) Git 2.4.10
+ | | * 6343e2f6 15:28 jch Sync with 2.3.10
+ | | |\
+ | | | * 18b58f70 15:26 jch (tag: v2.3.10) Git 2.3.10
+ | | | * 92cdfd21 14:59 jch Merge branch 'jk/xdiff-memory-limits
+ | | | |\
+ | | | | * 83c4d380 14:58 jk merge-file: enforce MAX_XDIFF_SIZE o
+ | | | | * dcd1742e 14:57 jk xdiff: reject files larger than ~1GB
+ | | | | * 3efb9880 14:57 jk react to errors in xdi_diff
+ | | | * | f2df3104 14:46 jch Merge branch 'jk/transfer-limit-re
+ | | | |\ \
+ | | | | | | === 2015-09-25 ===
+ | | | | * | b2581164 15:32 bb http: limit redirection depth
+ | | | | * | f4113cac 15:30 bb http: limit redirection to protoco
+ | | | | * | 5088d3b3 15:28 jk transport: refactor protocol white
+ | | | | | | === 2015-09-28 ===
+ | | | * | | df37727a 14:33 jch Merge branch 'jk/transfer-limit-
+ | | | |\ \ \
+ | | | | |/ /
+ | | | | | /
+ | | | | |/
+ | | | |/|
+ | | | | | === 2015-09-23 ===
+ | | | | * 33cfccbb 11:35 jk submodule: allow only certain protoc
+
+The output will be colorized according to the same settings used to enable/
+disable color for git log output.
+
+Additionally, the color of the three new items (dates, times and
+initials) can be controlled with the `color.log-times.date`,
+`color.log-times.time` and `color.log-times.initials` config options.
+
+Running `git log-times --graph --max-parents=0` on the Git repository gives:
+
+ === 2009-04-24 ===
+ *_0ca71b37_11:13 ap basic options parsing and whatnot.
+ === 2007-01-30 ===
+ *_16d6b8ab_15:16 sh Initial import of a python script to import ch
+ === 2006-11-06 ===
+ *_cb07fc2a_11:20 sop git-gui: Initial revision.
+ === 2005-08-07 ===
+ *_161332a5_10:49 ks first working version
+ === 2005-04-11 ===
+ *_2744b234_23:46 lt Start of early patch applicator tools for git.
+ === 2005-05-08 ===
+ *_1db95b00_21:08 pm Add initial version of gitk to the CVS reposit
+ === 2005-04-07 ===
+ *_e83c5163_15:13 lt Initial revision of "git", the information man
+
+Notice the `_` on either side of the hash identifying those commits
+as root commits. The `_` will only appear on the left side of the
+hash if the selected output format would have normally included a
+space there. In `--graph` mode, all the spaces between the commit mark
+(e.g. `*`) and the hash are turned into `_`.
+
+Running `git log-times --decorate --graph --no-merges -n 13 v2.6.1`
+on the Git repository results in this output:
+
+ === 2015-09-28 ===
+ * 22f698cb 19:19 jch (tag: v2.6.1) Git 2.6.1
+ ..........
+ * 24358560 15:34 jch (tag: v2.5.4) Git 2.5.4
+ ..........
+ * a2558fb8 15:30 jch (tag: v2.4.10) Git 2.4.10
+ ..........
+ * 18b58f70 15:26 jch (tag: v2.3.10) Git 2.3.10
+ ..........
+ * 83c4d380 14:58 jk merge-file: enforce MAX_XDIFF_SIZE on incomi
+ * dcd1742e 14:57 jk xdiff: reject files larger than ~1GB
+ * 3efb9880 14:57 jk react to errors in xdi_diff
+ | === 2015-09-25 ===
+ | * b2581164 15:32 bb http: limit redirection depth
+ | * f4113cac 15:30 bb http: limit redirection to protocol-whitel
+ | * 5088d3b3 15:28 jk transport: refactor protocol whitelist cod
+ | | === 2015-09-23 ===
+ | * 33cfccbb 11:35 jk submodule: allow only certain protocols fo
+ | * a5adaced 11:35 jk transport: add a protocol-whitelist enviro
+ |/
+ | === 2015-09-28 ===
+ | * be08dee9 13:18 jch (tag: v2.6.0) Git 2.6
+
+Notice how four linear breaks (`..........`) were automatically
+inserted to avoid parent child relationship confusion.
+
+In non `--graph` mode, linear breaks are NOT automatically inserted.
+They must be requested with the usual `--show-linear-break` option.
+
+
+Options
+-------
+
+In addition to allowing all the normal `git log` options except for
+`--notes`, `--format` and `--pretty` (`--oneline` is allowed and
+silently ignored), the following additional options may be utilized:
+
+ * `--seconds`
+ include seconds in the time (i.e. HH:MM:SS instead of just HH:MM)
+
+ * `--minutes`
+ include minutes but not seconds in the time (i.e. HH:MM not HH:MM:SS)
+ This is the default
+
+ * `--no-times`
+ omit the time field entirely
+
+ * `--two-initials`
+ only show at most two initials instead of the usual three
+ This is the default if `--initials=author,committer` or
+ `--initials=committer,author` is used.
+
+ * `--three-initials`
+ show at most three initials
+ This is the default unless `--initials=author,committer` or
+ `--initials=committer,author` is used.
+
+ * `--no-initials`
+ omit the initials field entirely
+
+ * `--commit-message`
+ when using `--walk-reflogs` show commit message not reflog message
+
+ * `--author-date`
+ force use of author dates and times
+ The default is to use committer dates and times unless
+ `--author-date-order` is in effect. This option forces author
+ dates and times to always be used and overrides `--committer-date`.
+
+ * `--committer-date`
+ force use of committer dates and times
+ The default is to use committer dates and times if `--date-order` or
+ `--topo-order` is in effect or `--author-date-order` is NOT in effect.
+ This option forces committer dates and times to always be used and
+ overrides a previous `--author-date` option.
+
+ * `--initials=author`
+ show author initials
+ This is the default behavior
+
+ * `--initials=committer`
+ show committer initials instead of author initials
+
+ * `--initials=author,committer`
+ show author and commiter initials separated by a `/`
+ This changes the initials width default from three to two.
+
+ * `--initials=committer,author`
+ show commiter and author initials separated by a `/`
+ This changes the initials width default from three to two.
+
+ * `--time-zone=zone`
+ set the TZ environment variable to `zone`
+ This is an alterative to setting TZ before running `git log-times`
+ and will affect the time zone dates and times are displayed in.
+
+ * `--weekday`
+ show the weekday with the date
+
+ * `--no-weekday`
+ do not show the weekday with the date
+ This is the default behavior
+
+In addition to the above options, color output is controlled as normal
+for `git log` with the addition of `color.log-times.date`,
+`color.log-times.time` and `color.log-times.initials` config options to alter
+the default colors for dates, times and initials respectively.
+
+Furthermore, default options may be set in the `log-times.defaults`
+config value and they will be treated as though they appeared at
+the very beginning of the `git log-times` command line option list
+(e.g. `git config log-times.defaults "--abbrev=8 --seconds"`).
diff --git a/contrib/git-log-times/git-log-times b/contrib/git-log-times/git-log-times
new file mode 100755
index 00000000..d0e5face
--- /dev/null
+++ b/contrib/git-log-times/git-log-times
@@ -0,0 +1,464 @@
+#!/usr/bin/env perl
+
+# git-log-times.pl -- git log --oneline variation with dates, times and initials
+# Copyright (C) 2015,2016 Kyle J. McKay <mackyle@gmail.com>. All rights reserved.
+
+# License GPL v2
+
+# Version 1.0
+
+use 5.008;
+use strict;
+use warnings;
+use File::Basename qw(basename);
+use POSIX qw(strftime _exit);
+use Encode;
+
+my $USAGE = <<'USAGE';
+usage: git%slog-times [<options>] [<revision-range>] [[--] <path>...]
+
+ -h Show this help
+ --seconds Use HH:MM:SS instead of just the default HH:MM
+ --minutes Use just HH:MM (default) for times not HH:MM:SS
+ --no-times Omit the time field entirely
+ --two-initials Use maximum of two initials instead of default three
+ --three-initials Use maximum of three initials (default)
+ --no-initials Omit the initials field entirely
+ --commit-message Show the commit message when using --walk-reflogs
+ --author-date Use author dates and times
+ --committer-date Use committer dates and times (default)
+ --initials=author Use author initials (default)
+ --initials=committer Use committer initials
+ --intiials=author,committer
+ Use author/committer initials and --two-initials
+ --intiials=committer,author
+ Use committer/author initials and --two-initials
+ --time-zone=<zone> Set TZ environment variable to <zone>
+ --weekday Show the weekday with the date
+ --no-weekday Do not show the weekday with the date (default)
+
+ other log options See `git help log` for more information
+
+Default colors for dates, times and initials may be changed by setting
+`color.log-times.date`, `color.log-times.time` and/or
+`color.log-times.initials` config values. Dates and times are shown in the
+local time zone if TZ is not set in the environment and the `--time-zone`
+option has not been used. Default options may be set in the
+`log-times.defaults` config value and they will be treated as though they were
+listed first in the command line options list (e.g.
+`git config log-times.defaults "--abbrev=8 --seconds"`)
+USAGE
+
+my $timeformat = "%H:%M";
+
+$SIG{PIPE} = sub {_exit 1};
+
+sub dodie {
+ my $msg = join(" ", @_);
+ chomp $msg;
+ die basename($0).": fatal: ".$msg."\n";
+}
+
+my ($setusedecorate, $usedecorate);
+sub use_decorate {
+ return $usedecorate if $setusedecorate;
+ my $do = qx(git config --get log.decorate 2>/dev/null) || "0";
+ chomp $do;
+ return 0 if $do eq "0" || $do eq "false" || $do eq "off";
+ return 0 if $do eq "auto" && ! -t STDOUT;
+ return 1;
+}
+
+my $iw;
+sub get_initials {
+ my $initials = shift;
+ my $wasutf8 = utf8::decode($initials);
+ $initials = lc($initials)." ";
+ $initials =~ s/[.]/ /g;
+ $initials =~ s/ iii? / /g;
+ $initials =~ s/ iv / /g;
+ $initials =~ s/ [js]r / /g;
+ $initials =~ s/[,;:'\042+_-]//g;
+ $initials =~ s/\([^(]*?\)/ /g;
+ $initials =~ s/\[[^[]*?\]/ /g;
+ $initials =~ s/\s+/ /g;
+ $initials =~ s/^ //g;
+ return "jc" if $iw == 2 && $initials eq "junio c hamano ";
+ $initials =~ s/([^ ])[^ ]* /$1/g;
+ if ($iw == 2) {
+ $initials =~ s/^(.).+(.)$/$1$2/;
+ } else {
+ $initials =~ s/^(..).+(.)$/$1$2/;
+ }
+ utf8::encode($initials) if $wasutf8;
+ return $initials;
+}
+
+sub get_nocolor_indent {
+ my $indent = shift;
+ $indent =~ s/\033[^m]*m//g;
+ $indent =~ s/\s+$//;
+ $indent =~ s/-+\.$//;
+ return $indent;
+}
+
+sub get_blank_graph_indent {
+ my $indent = shift;
+ chomp $indent;
+ $indent =~ s/\033[^m]*m//g;
+ $indent =~ s/^[\s|]+//;
+ return $indent;
+}
+
+sub get_first_indent {
+ my $indent = shift;
+ $indent =~ s/\033[^m]*m//g;
+ $indent =~ s/./ /gs;
+ return $indent;
+}
+
+my $nobar;
+my $barcolor;
+my $resetcolor = "";
+
+sub get_bar_color {
+ my ($prefix, $index) = @_;
+ my $c = (split(m{[-=^<>*+o /|\\_]}, $prefix))[$index];
+ $c =~ s/\Q$resetcolor\E//g if $resetcolor;
+ return $c;
+}
+
+sub get_indent {
+ my $indent = shift;
+ if ($nobar) {
+ $indent =~ tr/\-=^<>*+o./ /;
+ } else {
+ $indent =~ s/[-=^<>*+o]/$barcolor ? $barcolor."|".$resetcolor : "|"/e;
+ $indent =~ tr/\-./ /;
+ }
+ return $indent;
+}
+
+sub get_prefix {
+ my $indent = shift;
+ $indent =~ tr'\/'||';
+ return $indent;
+}
+
+sub get_defaults {
+ # defaults are cumulative, but an empty setting resets
+ my @defaults = ();
+ my $opts = qx(git config --get-all log-times.defaults 2>/dev/null);
+ chomp($opts);
+ foreach (split(/\r\n|\r|\n/, $opts, -1)) {
+ s/^\s+//; s/\s+$//;
+ if ($_ eq "") {
+ @defaults = ();
+ next;
+ }
+ push(@defaults, $_);
+ }
+ return split(" ", join(" ", @defaults));
+}
+
+system("git rev-parse --git-dir >/dev/null") == 0 or exit(1);
+my ($usemark, $usegraph, $usereflog, $useboundary, $useleftright, $usecherry, $setusecolor, $usecolor, $usecad);
+my @args = ();
+my $lastwasgrep;
+my $dateopt = "%ct";
+my $usewkday;
+my $reflogsubj = "%gs";
+my $sawdashdash;
+$iw = undef;
+my $iw2 = "";
+my ($committer, $author, $ivar, $ivar2);
+$ivar = \$author;
+foreach my $arg (get_defaults(), @ARGV) {
+ my $nextisgrep;
+ if ($sawdashdash || $lastwasgrep) {
+ push(@args, $arg);
+ $lastwasgrep = $nextisgrep;
+ next;
+ }
+ if ($arg eq "-h") {
+ my $dash = "-";
+ my $exec_path = qx(git --exec-path 2>/dev/null);
+ chomp $exec_path;
+ $dash = " " if $ENV{PATH} =~ /^\Q$exec_path\E:/;
+ printf "$USAGE\n", $dash;
+ exit 0;
+ } elsif ($arg eq "--oneline") {
+ # silently ignore --oneline as we are always in a one line format
+ next;
+ } elsif ($arg eq "--seconds") {
+ # extra option
+ $timeformat = "%H:%M:%S";
+ next;
+ } elsif ($arg eq "--minutes") {
+ # extra option
+ $timeformat = "%H:%M";
+ next;
+ } elsif ($arg eq "--no-times") {
+ # extra option
+ $timeformat = "";
+ next;
+ } elsif ($arg eq "--two-initials") {
+ # extra option
+ $iw = 2;
+ next;
+ } elsif ($arg eq "--three-initials") {
+ # extra option
+ $iw = 3;
+ next;
+ } elsif ($arg eq "--no-initials") {
+ # extra option
+ $iw = 0;
+ next;
+ } elsif ($arg eq "--two-initials") {
+ # extra option
+ $iw = 3;
+ next;
+ } elsif ($arg eq "--commit-message") {
+ # extra option
+ $reflogsubj = "%s";
+ next;
+ } elsif ($arg eq "--author-date") {
+ # extra option
+ $dateopt = "%at";
+ $usecad = 1;
+ next;
+ } elsif ($arg eq "--committer-date") {
+ # extra option
+ $dateopt = "%ct";
+ $usecad = 1;
+ next;
+ } elsif ($arg eq "--weekday") {
+ # extra option
+ $usewkday = 1;
+ next;
+ } elsif ($arg eq "--no-weekday") {
+ # extra option
+ $usewkday = undef;
+ next;
+ } elsif ($arg =~ /^--initials=/) {
+ # extra option
+ $arg =~ s/^--initials=//;
+ if ($arg eq "author") {
+ $ivar = \$author;
+ $ivar2 = undef;
+ } elsif ($arg eq "committer") {
+ $ivar = \$committer;
+ $ivar2 = undef;
+ } elsif ($arg eq "committer,author" || $arg eq "committer/author") {
+ $ivar = \$committer;
+ $ivar2 = \$author;
+ } elsif ($arg eq "author,committer" || $arg eq "author/committer") {
+ $ivar = \$author;
+ $ivar2 = \$committer;
+ } else {
+ dodie "--initials= requires 'author', 'committer' or 'committer,author'";
+ }
+ next;
+ } elsif ($arg =~ /^--time-zone=/) {
+ # extra option
+ $arg =~ s/^--time-zone=//;
+ $ENV{TZ} = $arg;
+ next;
+ } elsif ($arg eq "--date-order" || $arg eq "--topo-order") {
+ $dateopt = "%ct" unless $usecad;
+ } elsif ($arg eq "--author-date-order") {
+ $dateopt = "%at";
+ } elsif ($arg =~ /^--(pretty|pretty=.*|format=.*|notes|show-notes|show-notes=.*|standard-notes)$/) {
+ dodie "formatting/notes option not allowed: $arg";
+ } elsif ($arg eq "--no-decorate" || $arg eq "--decorate=no") {
+ $setusedecorate = 1;
+ $usedecorate = undef;
+ } elsif ($arg eq "--decorate=auto") {
+ $setusedecorate = 1;
+ $usedecorate = -t STDOUT ? 1 : undef;
+ } elsif ($arg eq "--decorate" || $arg =~ /^--decorate=/) {
+ $setusedecorate = 1;
+ $usedecorate = 1;
+ } elsif ($arg eq "--color" || $arg eq "--color=always") {
+ $setusecolor = 1;
+ $usecolor = 1;
+ } elsif ($arg eq "--no-color" || $arg eq "--color=never") {
+ $setusecolor = 1;
+ $usecolor = undef;
+ } elsif ($arg eq "--color=auto") {
+ $setusecolor = 1;
+ $usecolor = -t STDOUT ? 1 : undef;
+ } elsif ($arg eq "-g" || $arg eq "--walk-reflogs") {
+ $usereflog = 1;
+ } elsif ($arg eq "--boundary") {
+ $useboundary = 1;
+ $usemark = 1;
+ } elsif ($arg eq "--cherry-mark" || $arg eq "--cherry") {
+ $usecherry = 1;
+ $usemark = 1;
+ } elsif ($arg eq "--left-right") {
+ $useleftright = 1;
+ $usemark = 1;
+ } elsif ($arg eq "--graph") {
+ $usegraph = 1;
+ } elsif ($arg =~ /^(--grep|--grep-reflog|-S|-G)$/) {
+ $nextisgrep = 1;
+ } elsif ($arg eq "--") {
+ $sawdashdash = 1;
+ }
+ push(@args, $arg);
+ $lastwasgrep = $nextisgrep;
+}
+$iw = defined($ivar2) ? 2 : 3 unless defined($iw);
+$iw = "" if !$iw;
+$iw2 = $iw if defined($ivar2);
+my ($mark, $fixmark) = ("");
+$mark = "%m " unless $usegraph || !$usemark;
+if ($mark && !$useleftright) {
+ $fixmark = " ";
+ $fixmark = "+" if $usecherry;
+}
+
+my $color = "never";
+my ($hashcolor, $datecolor, $timecolor, $initialscolor, $autocolor) = ("", "", "", "", "");
+$usecolor = 1 if !$setusecolor && system("git", "config", "--get-colorbool", "color.diff") == 0;
+if ($usecolor) {
+ $color = "always";
+ $autocolor = "%C(auto)";
+ $hashcolor= qx(git config --get-color color.diff.commit "yellow");
+ $datecolor= qx(git config --get-color color.log-times.date "bold blue");
+ $timecolor= qx(git config --get-color color.log-times.time "green") if $timeformat;
+ $initialscolor = qx(git config --get-color color.log-times.initials "red") if $iw;
+ $resetcolor = qx(git config --get-color "" "reset");
+}
+my $decopt = "";
+$decopt = "$autocolor%d" if use_decorate;
+my $pager = qx(git var GIT_PAGER);
+defined($pager) and chomp $pager;
+$ENV{LESS} = "-FRX" unless exists $ENV{LESS};
+$ENV{LV} = "-c" unless exists $ENV{LV};
+
+my ($lastdate, $lastprefix, $lastplainprefix) = ("");
+my $msgopt = "%s";
+$msgopt = "%gd: $reflogsubj" if $usereflog;
+my $lastwasroot = 1;
+open(LOG, '-|', "git", "log", "--color=$color",
+ "--format=tformat:$mark%x1fCOMMIT %H %h $dateopt%x1f%cn%x1f%an%x1f%P%x1f$decopt $msgopt%x1f",
+ @args) or exit(1);
+if (defined($pager) && $pager ne "cat") {
+ open OUT, "|$pager" or dodie "could not run pager \"$pager\": $!\n";
+} else {
+ open OUT, '>&STDOUT' or die "could not dupe STDOUT: $!";
+}
+select((select(OUT),$|=1)[0]);
+my $delblank;
+my @lastparents = ();
+my $lastwascommit;
+my ($prefix, $data, $parentlist, $subject);
+while (my $logline = <LOG>) {
+ ($prefix, $data, $committer, $author, $parentlist, $subject) = split(/\x1f/, $logline, -1);
+ $subject =~ s/ // if $subject;
+ my ($flag, $fullhash, $hash, $timestamp) = split(" ", $data, 4) if defined($data);
+ if (!defined($flag) || $flag ne "COMMIT") {
+ chomp $prefix;
+ $delblank = 0, next if $delblank && !$usegraph && $prefix =~ /^\s*$/;
+ $delblank = 0, next if $delblank && $usegraph && !get_blank_graph_indent($prefix);
+ print OUT "$prefix\n";
+ $lastprefix = $prefix;
+ $lastplainprefix = undef;
+ @lastparents = ();
+ $lastwascommit = undef;
+ next;
+ }
+ my $isroot = !$parentlist;
+ my @parents = split(' ', $parentlist) if $usegraph;
+ my $initials = $iw ? get_initials($$ivar) : "";
+ my $initials2 = $iw2 ? get_initials($$ivar2) : "";
+ my ($newdate, $newday, $newtime) = split(" ", strftime("%Y-%m-%d %a $timeformat", localtime($timestamp)));
+ $newdate .= " " . $newday if $usewkday;
+ my $mightneedbreak = $lastwascommit && !$lastwasroot && $usegraph && !grep($_ eq $fullhash, @lastparents);
+ if ($lastdate ne $newdate || $mightneedbreak) {
+ my $indent = "";
+ if (!$lastdate || $mark) {
+ $indent = get_first_indent($prefix);
+ $lastprefix = $prefix;
+ $lastplainprefix = undef;
+ } elsif ($prefix ne "") {
+ my $newplainprefix = get_nocolor_indent($prefix);
+ defined($lastplainprefix) or $lastplainprefix = get_nocolor_indent($lastprefix);
+ $nobar = undef;
+ $barcolor = undef;
+ if ($newplainprefix =~ /^(.*?[-=^<>*+o])/) {{
+ my $marklen = length($1);
+ my $difflen = length($lastplainprefix) - length($1);
+ $nobar = 1;
+ if ($difflen >= 0) {
+ my $lastmark = substr($lastplainprefix, $marklen-1, 1);
+ $lastmark =~ /[-=^<>*+o]/ and $nobar = $lastwasroot || $mightneedbreak, last;
+ $lastmark eq "|" && $lastdate ne $newdate and
+ $nobar = 0,
+ $barcolor = get_bar_color($lastprefix, $marklen - 1),
+ last;
+ }
+ if ($lastdate eq $newdate) {
+ $lastprefix = $prefix;
+ $lastplainprefix = $newplainprefix;
+ goto NOBREAKNEEDED;
+ }
+ $difflen >= -1 or last;
+ substr($lastplainprefix, $marklen-2, 1) eq "\\" and
+ $nobar = 0,
+ $barcolor = get_bar_color($lastprefix, $marklen - 2),
+ last;
+ $difflen >= 1 &&
+ substr($lastplainprefix, $marklen, 1) eq "/" and
+ $nobar = 0,
+ $barcolor = get_bar_color($lastprefix, $marklen);
+ }}
+ $indent = get_indent($prefix);
+ $lastprefix = $prefix;
+ $prefix = get_prefix($prefix);
+ $lastplainprefix = $newplainprefix;
+ }
+ if ($lastdate ne $newdate) {
+ printf OUT "%s%s=== %s ===%s\n", $indent,
+ $datecolor, $newdate, $resetcolor;
+ $lastdate = $newdate;
+ } else {
+ printf OUT "%s%s %s%s%-${iw}s%s%-${iw2}s %s\n", $indent,
+ ' ' x length($hash), ' ' x length($newtime),
+ ($iw ? " " : ""), "", ($iw2 ? " " : ""), "",
+ "..........";
+ }
+ } else {
+ $lastprefix = $prefix;
+ $lastplainprefix = undef;
+ }
+NOBREAKNEEDED:
+ $lastwasroot = $isroot;
+ @lastparents = @parents;
+ $lastwascommit = 1;
+ my $rootflag = " ";
+ if ($isroot) {
+ $rootflag = "_";
+ $prefix = substr($prefix, 0, length($prefix) - 1) . "_"
+ if length($prefix);
+ if ($prefix =~ /^(.*?[-=^<>*+o])(.+)$/) {
+ my ($initial, $trail) = ($1, $2);
+ $trail =~ tr/ /_/;
+ $prefix = $initial . $trail;
+ }
+ }
+ if ($fixmark) {
+ $prefix = $fixmark . substr($prefix, 1)
+ if $prefix =~ /^[<>]/;
+ }
+ printf OUT "%s%s%s%s%s%-${iw}s%s%-${iw2}s%s%s\n", $prefix,
+ "$hashcolor$hash$resetcolor",
+ $rootflag, ($timeformat ? "$timecolor$newtime$resetcolor " : ""),
+ $initialscolor, $initials, ($iw2 ? "/" : ""), $initials2,
+ ($iw ? "$resetcolor " : ""), $subject;
+ $delblank = 1;
+}
+close LOG;
+close OUT;
---
^ permalink raw reply related
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Lukas Fleischer @ 2016-09-29 5:27 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor, peff, torvalds, git
In-Reply-To: <20160929024400.22605-1-szeder@ira.uka.de>
On Thu, 29 Sep 2016 at 04:44:00, SZEDER Gábor wrote:
> I for one raise my hand in protest...
>
> "few extra bytes" is not the only downside, and it's not at all about
> how many characters are copy-and-pasted. In my opinion it's much more
> important that this change wastes 5 columns worth of valuable screen
> real estate e.g. for 'git blame' or 'git log --oneline' in projects
> that don't need it and certainly won't ever need it.
>
> Sure, users working on smaller repos are free to reset core.abbrev to
> its original value. I don't have any numbers, of course, but I
> suspect that there are many more smaller repos out there that this
> change will affect disadvantageously, than there are large repos for
> which it's beneficial.
I know this suggestion comes a bit late but would it make sense to let
the repository owner overwrite the core.abbrev setting?
One possible way to implement this would be adding .gitconfig support to
repositories with a very limited set of whitelisted variables allowed in
there (could be core.abbrev only to begin with). Or some entirely
separate mechanism like .gitignore.
With such a mechanism, we could keep the default of 7 which works fine
for most projects. Linus could bump the default to 12 for linux.git. If
some users are not happy with that, they can still overwrite it in their
local Git config. Anybody starting a project could change the initial
value to a suitable value in one of the first commits -- provided they
already have an idea how much the project will grow. That way, hashes
will be "long enough" even for early commits, before any heuristics
could guess that the project would become large.
Opinions?
Regards,
Lukas
^ permalink raw reply
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: SZEDER Gábor @ 2016-09-29 2:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER Gábor, peff, torvalds, git
In-Reply-To: <20160928233047.14313-5-gitster@pobox.com>
> As Peff said, responding in a thread started by Linus's suggestion
> to raise the default abbreviation to 12 hexdigits:
>
> I actually think "12" might be sane for a long time. That's 48 bits of
> sha1, so we'd expect a 50% change of a _single_ collision at 2^24, or 16
s/change/chance/
I know it's quoted, but still.
> million. The biggest repository I know about (in number of objects) is
> the one holding all of the objects for all of the forks of
> torvalds/linux on GitHub. It's at about 15 million objects.
>
> Which _seems_ close, but remember that's the size where we expect to see
> a single collision. They don't become common until much later (I didn't
> compute an exact number, but Linus's 16x sounds about right). I know
> that the growth of the kernel isn't really linear, but I think the need
> to bump to "13" might not just be decades, but possibly a century or
> more.
>
> So 12 seems reasonable, and the only downside for it (or for "13", for
> that matter) is a few extra bytes. I dunno, maybe people will really
> hate that, but I have a feeling these are mostly cut-and-pasted anyway.
I for one raise my hand in protest...
"few extra bytes" is not the only downside, and it's not at all about
how many characters are copy-and-pasted. In my opinion it's much more
important that this change wastes 5 columns worth of valuable screen
real estate e.g. for 'git blame' or 'git log --oneline' in projects
that don't need it and certainly won't ever need it.
Sure, users working on smaller repos are free to reset core.abbrev to
its original value. I don't have any numbers, of course, but I
suspect that there are many more smaller repos out there that this
change will affect disadvantageously, than there are large repos for
which it's beneficial.
> And this does exactly that.
>
> Keep the tests working by explicitly asking for the old 7 hexdigits
> setting in the fake system-wide configuration file used for tests.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* [PATCH 1/4] config: allow customizing /etc/gitconfig location
From: Junio C Hamano @ 2016-09-28 23:30 UTC (permalink / raw)
To: git; +Cc: peff, torvalds
In-Reply-To: <20160928233047.14313-1-gitster@pobox.com>
With a new environment variable GIT_ETC_GITCONFIG, the users can
specify a file that is used instead of /etc/gitconfig to read (and
write) the system-wide configuration.
Earlier, we introduced GIT_CONFIG_NOSYSTEM environment variable
ab88c363 ("allow suppressing of global and system config",
2008-02-06), primarily to protect our tests from random set of
configuration variables the system administrators would put in their
/etc/gitconfig file. We can replace the use of this mechanism in
our tests by pointing GIT_ETC_GITCONFIG at our own instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* The next step is to add "[core]abbrev=7" to this file and update
default_abbrev to 12 in environment.c and see what breaks. I
suspect that "git worktree list" would break without my recent
patch. I also know some tests expect "git config -l" to show
only values they set to their local configuration, which would
need to be corrected. We'll see them in next steps.
cache.h | 1 +
config.c | 2 ++
t/gitconfig-for-test | 6 ++++++
t/t1300-repo-config.sh | 15 +++++++++++++++
t/test-lib.sh | 4 ++--
5 files changed, 26 insertions(+), 2 deletions(-)
create mode 100644 t/gitconfig-for-test
diff --git a/cache.h b/cache.h
index b0dae4b..81a07bf 100644
--- a/cache.h
+++ b/cache.h
@@ -408,6 +408,7 @@ static inline enum object_type object_type(unsigned int mode)
#define GIT_NAMESPACE_ENVIRONMENT "GIT_NAMESPACE"
#define GIT_WORK_TREE_ENVIRONMENT "GIT_WORK_TREE"
#define GIT_PREFIX_ENVIRONMENT "GIT_PREFIX"
+#define GIT_ETC_GITCONFIG_ENVIRONMENT "GIT_ETC_GITCONFIG"
#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
#define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
diff --git a/config.c b/config.c
index 0dfed68..124699b 100644
--- a/config.c
+++ b/config.c
@@ -1253,6 +1253,8 @@ const char *git_etc_gitconfig(void)
{
static const char *system_wide;
if (!system_wide)
+ system_wide = getenv(GIT_ETC_GITCONFIG_ENVIRONMENT);
+ if (!system_wide)
system_wide = system_path(ETC_GITCONFIG);
return system_wide;
}
diff --git a/t/gitconfig-for-test b/t/gitconfig-for-test
new file mode 100644
index 0000000..4598885
--- /dev/null
+++ b/t/gitconfig-for-test
@@ -0,0 +1,6 @@
+;; This file is used as if it were /etc/gitconfig while running the
+;; test scripts in this directory.
+;;
+;; [user]
+;; name = A U Thor
+;; email = author@example.com
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 923bfc5..1184f43 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1372,4 +1372,19 @@ test_expect_success !MINGW '--show-origin blob ref' '
test_cmp expect output
'
+test_expect_success 'system-wide configuration' '
+ system="$TRASH_DIRECTORY/system-wide" &&
+ >"$system" &&
+ git config -f "$system" --add frotz.nitfol xyzzy &&
+
+ git config -f "$system" frotz.nitfol >expect &&
+ GIT_ETC_GITCONFIG="$system" \
+ git config --system frotz.nitfol >actual &&
+
+ GIT_ETC_GITCONFIG="$system" \
+ git config --system --replace-all frotz.nitfol blorb &&
+ echo blorb >expect &&
+ GIT_ETC_GITCONFIG="$system" git config --system frotz.nitfol >actual
+'
+
test_done
diff --git a/t/test-lib.sh b/t/test-lib.sh
index ac56512..6803212 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -851,9 +851,9 @@ else # normal case, use ../bin-wrappers only unless $with_dashes:
fi
fi
GIT_TEMPLATE_DIR="$GIT_BUILD_DIR"/templates/blt
-GIT_CONFIG_NOSYSTEM=1
+GIT_ETC_GITCONFIG="$GIT_BUILD_DIR/t/gitconfig-for-test"
GIT_ATTR_NOSYSTEM=1
-export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_ATTR_NOSYSTEM
+export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_ETC_GITCONFIG GIT_ATTR_NOSYSTEM
if test -z "$GIT_TEST_CMP"
then
--
2.10.0-584-gc9e068c
^ permalink raw reply related
* [PATCH 2/4] t13xx: do not assume system config is empty
From: Junio C Hamano @ 2016-09-28 23:30 UTC (permalink / raw)
To: git; +Cc: peff, torvalds
In-Reply-To: <20160928233047.14313-1-gitster@pobox.com>
Most parts of these two tests want to read from the local
configuration file they prepare and make sure expected names and
values appear with "git config --list".
Once we add custom configuration items that we want to affect the
tests with globally to t/gitconfig-for-test file, these will start
seeing the contents from there and break. Clarify with --local that
they only care about the contents from their local configuration.
The tests for show-origin codepath in "git config" however cannot be
tweaked with "--local" etc., because they wants to read also from
$HOME/.gitconfig and make sure what comes from where. Disable
reading from the system-wide config with GIT_CONFIG_NOSYSTEM=1 for
these tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t1300-repo-config.sh | 24 +++++++++++++-----------
t/t1308-config-set.sh | 1 +
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 1184f43..b998568 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -341,13 +341,11 @@ version.1.2.3eX.alpha=beta
EOF
test_expect_success 'working --list' '
- git config --list > output &&
+ git config --local --list > output &&
test_cmp expect output
'
-cat > expect << EOF
-EOF
-
-test_expect_success '--list without repo produces empty output' '
+test_expect_success '--list without repo shows only from the global' '
+ git config --system --list >expect &&
git --git-dir=nonexistent config --list >output &&
test_cmp expect output
'
@@ -360,7 +358,7 @@ version.1.2.3eX.alpha
EOF
test_expect_success '--name-only --list' '
- git config --name-only --list >output &&
+ git config --local --name-only --list >output &&
test_cmp expect output
'
@@ -370,7 +368,7 @@ nextsection.nonewline wow2 for me
EOF
test_expect_success '--get-regexp' '
- git config --get-regexp in >output &&
+ git config --local --get-regexp in >output &&
test_cmp expect output
'
@@ -380,7 +378,7 @@ nextsection.nonewline
EOF
test_expect_success '--name-only --get-regexp' '
- git config --name-only --get-regexp in >output &&
+ git config --local --name-only --get-regexp in >output &&
test_cmp expect output
'
@@ -391,7 +389,7 @@ EOF
test_expect_success '--add' '
git config --add nextsection.nonewline "wow4 for you" &&
- git config --get-all nextsection.nonewline > output &&
+ git config --local --get-all nextsection.nonewline > output &&
test_cmp expect output
'
@@ -935,7 +933,7 @@ section.quotecont=cont;inued
EOF
test_expect_success 'value continued on next line' '
- git config --list > result &&
+ git config --local --list > result &&
test_cmp result expect
'
@@ -959,7 +957,7 @@ Qsection.sub=section.val4
Qsection.sub=section.val5Q
EOF
test_expect_success '--null --list' '
- git config --null --list >result.raw &&
+ git config --null --local --list >result.raw &&
nul_to_q <result.raw >result &&
echo >>result &&
test_cmp expect result
@@ -1264,6 +1262,7 @@ test_expect_success '--show-origin with --list' '
file:.git/../include/relative.include user.relative=include
command line: user.cmdline=true
EOF
+ GIT_CONFIG_NOSYSTEM=1 \
git -c user.cmdline=true config --list --show-origin >output &&
test_cmp expect output
'
@@ -1281,6 +1280,7 @@ test_expect_success '--show-origin with --list --null' '
includeQcommand line:Quser.cmdline
trueQ
EOF
+ GIT_CONFIG_NOSYSTEM=1 \
git -c user.cmdline=true config --null --list --show-origin >output.raw &&
nul_to_q <output.raw >output &&
# The here-doc above adds a newline that the --null output would not
@@ -1304,6 +1304,7 @@ test_expect_success '--show-origin with --get-regexp' '
file:$HOME/.gitconfig user.global true
file:.git/config user.local true
EOF
+ GIT_CONFIG_NOSYSTEM=1 \
git config --show-origin --get-regexp "user\.[g|l].*" >output &&
test_cmp expect output
'
@@ -1312,6 +1313,7 @@ test_expect_success '--show-origin getting a single key' '
cat >expect <<-\EOF &&
file:.git/config local
EOF
+ GIT_CONFIG_NOSYSTEM=1 \
git config --show-origin user.override >output &&
test_cmp expect output
'
diff --git a/t/t1308-config-set.sh b/t/t1308-config-set.sh
index 7655c94..5d5adb1 100755
--- a/t/t1308-config-set.sh
+++ b/t/t1308-config-set.sh
@@ -260,6 +260,7 @@ test_expect_success 'iteration shows correct origins' '
name=
scope=cmdline
EOF
+ GIT_CONFIG_NOSYSTEM=1 \
GIT_CONFIG_PARAMETERS=$cmdline_config test-config iterate >actual &&
test_cmp expect actual
'
--
2.10.0-584-gc9e068c
^ permalink raw reply related
* [PATCH 0/4] raising core.abbrev default to 12 hexdigits
From: Junio C Hamano @ 2016-09-28 23:30 UTC (permalink / raw)
To: git; +Cc: peff, torvalds
In-Reply-To: <CA+55aFy0_pwtFOYS1Tmnxipw9ZkRNCQHmoYyegO00pjMiZQfbg@mail.gmail.com>
Per request/suggestion by Linus.
This took far more effort to keep the existing tests working than
the actual change.
Junio C Hamano (4):
config: allow customizing /etc/gitconfig location
t13xx: do not assume system config is empty
worktree: honor configuration variables
core.abbrev: raise the default abbreviation to 12 hexdigits
builtin/worktree.c | 2 ++
cache.h | 1 +
config.c | 2 ++
environment.c | 2 +-
t/gitconfig-for-test | 9 +++++++++
t/t1300-repo-config.sh | 39 ++++++++++++++++++++++++++++-----------
t/t1308-config-set.sh | 1 +
t/test-lib.sh | 4 ++--
8 files changed, 46 insertions(+), 14 deletions(-)
create mode 100644 t/gitconfig-for-test
--
2.10.0-584-gc9e068c
^ permalink raw reply
* [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Junio C Hamano @ 2016-09-28 23:30 UTC (permalink / raw)
To: git; +Cc: peff, torvalds
In-Reply-To: <20160928233047.14313-1-gitster@pobox.com>
As Peff said, responding in a thread started by Linus's suggestion
to raise the default abbreviation to 12 hexdigits:
I actually think "12" might be sane for a long time. That's 48 bits of
sha1, so we'd expect a 50% change of a _single_ collision at 2^24, or 16
million. The biggest repository I know about (in number of objects) is
the one holding all of the objects for all of the forks of
torvalds/linux on GitHub. It's at about 15 million objects.
Which _seems_ close, but remember that's the size where we expect to see
a single collision. They don't become common until much later (I didn't
compute an exact number, but Linus's 16x sounds about right). I know
that the growth of the kernel isn't really linear, but I think the need
to bump to "13" might not just be decades, but possibly a century or
more.
So 12 seems reasonable, and the only downside for it (or for "13", for
that matter) is a few extra bytes. I dunno, maybe people will really
hate that, but I have a feeling these are mostly cut-and-pasted anyway.
And this does exactly that.
Keep the tests working by explicitly asking for the old 7 hexdigits
setting in the fake system-wide configuration file used for tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
environment.c | 2 +-
t/gitconfig-for-test | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/environment.c b/environment.c
index ca72464..25daddb 100644
--- a/environment.c
+++ b/environment.c
@@ -16,7 +16,7 @@ int trust_executable_bit = 1;
int trust_ctime = 1;
int check_stat = 1;
int has_symlinks = 1;
-int minimum_abbrev = 4, default_abbrev = 7;
+int minimum_abbrev = 4, default_abbrev = 12;
int ignore_case;
int assume_unchanged;
int prefer_symlink_refs;
diff --git a/t/gitconfig-for-test b/t/gitconfig-for-test
index 4598885..8c28442 100644
--- a/t/gitconfig-for-test
+++ b/t/gitconfig-for-test
@@ -4,3 +4,6 @@
;; [user]
;; name = A U Thor
;; email = author@example.com
+
+[core]
+ abbrev = 7
--
2.10.0-584-gc9e068c
^ permalink raw reply related
* [PATCH 3/4] worktree: honor configuration variables
From: Junio C Hamano @ 2016-09-28 23:30 UTC (permalink / raw)
To: git; +Cc: peff, torvalds
In-Reply-To: <20160928233047.14313-1-gitster@pobox.com>
The command accesses default_abbrev (defined in environment.c and is
updated via core.abbrev configuration), but never makes any call to
git_config(). The output from "worktree list" ignores the abbrev
setting for this reason.
Make a call to git_config() to read the default set of configuration
variables at the beginning of the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is already queued separately from this series.
builtin/worktree.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 6dcf7bd..5c4854d 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -528,6 +528,8 @@ int cmd_worktree(int ac, const char **av, const char *prefix)
OPT_END()
};
+ git_config(git_default_config, NULL);
+
if (ac < 2)
usage_with_options(worktree_usage, options);
if (!prefix)
--
2.10.0-584-gc9e068c
^ permalink raw reply related
* Re: [PATCH v8 01/11] pkt-line: rename packet_write() to packet_write_fmt()
From: Jakub Narębski @ 2016-09-28 23:15 UTC (permalink / raw)
To: Lars Schneider
Cc: git, Jeff King, Junio C Hamano, Stefan Beller,
Martin-Louis Bright, Torsten Bögershausen, Ramsay Jones
In-Reply-To: <13E00B0F-41FC-4FBE-9ABD-2E9B11743E2B@gmail.com>
W dniu 26.09.2016 o 20:49, Lars Schneider pisze:
> On 24 Sep 2016, at 23:14, Jakub Narębski <jnareb@gmail.com> wrote:
>> W dniu 20.09.2016 o 21:02, larsxschneider@gmail.com pisze:
>>
>>> From: Lars Schneider <larsxschneider@gmail.com>
>>>
>>> packet_write() should be called packet_write_fmt() as the string
>>> parameter can be formatted.
>>
>> I would say:
>>
>> packet_write() should be called packet_write_fmt() because it
>> is printf-like function where first parameter is format string.
>>
>> Or something like that. But such minor change might be not worth
>> yet another reroll of this patch series.
>>
>> Perhaps it would be a good idea to explain the reasoning behind
>> this change:
>>
>> This is important distinction to know from the name if the
>> function accepts arbitrary binary data and/or arbitrary
>> strings to be written - packet_write[_fmt()] do not.
>
> packet_write() should be called packet_write_fmt() because it is a
> printf-like function that takes a format string as first parameter.
>
> packet_write_fmt() should be used for text strings only. Arbitrary
> binary data should use a new packet_write() function that is introduced
> in a subsequent patch.
>
> Better?
Better.
>
>>> pkt-line.h | 2 +-
>>> shallow.c | 2 +-
>>> upload-pack.c | 30 +++++++++++++++---------------
>>> 11 files changed, 29 insertions(+), 29 deletions(-)
>>
>> Diffstat looks correct. Was the patch generated by doing search
>> and replace?
>
> Yes.
Good.
--
Jakub Narębski
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox