* [PATCH v7 05/11] log --stat: use the full terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-24 20:32 UTC (permalink / raw)
To: git, gitster
Cc: Michael J Gruber, pclouds, j.sixt,
Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1330115538-1576-1-git-send-email-zbyszek@in.waw.pl>
Make log --stat behave like diff --stat and use the full terminal
width.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
builtin/log.c | 1 +
t/t4052-stat-output.sh | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index d37ae26..075a427 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -77,6 +77,7 @@ static void cmd_log_init_defaults(struct rev_info *rev)
get_commit_format(fmt_pretty, rev);
rev->verbose_header = 1;
DIFF_OPT_SET(&rev->diffopt, RECURSIVE);
+ rev->diffopt.stat_width = -1; /* use full terminal width */
rev->abbrev_commit = default_abbrev_commit;
rev->show_root_diff = default_show_root;
rev->subject_prefix = fmt_patch_subject_prefix;
diff --git a/t/t4052-stat-output.sh b/t/t4052-stat-output.sh
index 91c4ba8..acc54cd 100755
--- a/t/t4052-stat-output.sh
+++ b/t/t4052-stat-output.sh
@@ -96,7 +96,7 @@ done <<\EOF
ignores expect80 format-patch -1 --stdout
respects expect200 diff HEAD^ HEAD --stat
respects expect200 show --stat
-ignores expect80 log -1 --stat
+respects expect200 log -1 --stat
EOF
cat >expect <<'EOF'
@@ -164,7 +164,7 @@ done <<\EOF
ignores expect80 format-patch -1 --stdout
respects expect200 diff HEAD^ HEAD --stat
respects expect200 show --stat
-ignores expect80 log -1 --stat
+respects expect200 log -1 --stat
EOF
cat >expect <<'EOF'
--
1.7.9.2.332.g05f13
^ permalink raw reply related
* [PATCH v7 04/11] show --stat: use the full terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-24 20:32 UTC (permalink / raw)
To: git, gitster
Cc: Michael J Gruber, pclouds, j.sixt,
Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1330115538-1576-1-git-send-email-zbyszek@in.waw.pl>
Make show --stat behave like diff --stat and use the full terminal
width.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
builtin/log.c | 2 ++
t/t4052-stat-output.sh | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 7d1f6f8..d37ae26 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -447,6 +447,8 @@ int cmd_show(int argc, const char **argv, const char *prefix)
rev.diff = 1;
rev.always_show_header = 1;
rev.no_walk = 1;
+ rev.diffopt.stat_width = -1; /* Scale to real terminal size */
+
memset(&opt, 0, sizeof(opt));
opt.def = "HEAD";
opt.tweak = show_rev_tweak_rev;
diff --git a/t/t4052-stat-output.sh b/t/t4052-stat-output.sh
index 4bfd6a5..91c4ba8 100755
--- a/t/t4052-stat-output.sh
+++ b/t/t4052-stat-output.sh
@@ -95,7 +95,7 @@ do
done <<\EOF
ignores expect80 format-patch -1 --stdout
respects expect200 diff HEAD^ HEAD --stat
-ignores expect80 show --stat
+respects expect200 show --stat
ignores expect80 log -1 --stat
EOF
@@ -163,7 +163,7 @@ do
done <<\EOF
ignores expect80 format-patch -1 --stdout
respects expect200 diff HEAD^ HEAD --stat
-ignores expect80 show --stat
+respects expect200 show --stat
ignores expect80 log -1 --stat
EOF
--
1.7.9.2.332.g05f13
^ permalink raw reply related
* [PATCH v7 03/11] diff --stat: use the full terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-24 20:32 UTC (permalink / raw)
To: git, gitster
Cc: Michael J Gruber, pclouds, j.sixt,
Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1330115538-1576-1-git-send-email-zbyszek@in.waw.pl>
Default to the real terminal width for diff --stat output, instead
of the hard-coded 80 columns.
Some projects (especially in Java), have long filename paths, with
nested directories or long individual filenames. When files are
renamed, the filename part in stat output can be almost useless. If
the middle part between { and } is long (because the file was moved to
a completely different directory), then most of the path would be
truncated.
It makes sense to detect and use the full terminal width and display
full filenames if possible.
The are commands like diff, show, and log, which can adapt the output
to the terminal width. There are also commands like format-patch,
whose output should be independent of the terminal width. Since it is
safer to use the 80-column default, the real terminal width is only
used if requested by the calling code by setting diffopts.stat_width=-1.
Normally this value is 0, and can be set by the user only to a
non-negative value, so -1 is safe to use internally.
This patch only changes the diff builtin to use the full terminal width.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
builtin/diff.c | 3 +++
diff.c | 5 ++++-
t/t4052-stat-output.sh | 11 +++++++++--
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/builtin/diff.c b/builtin/diff.c
index 387afa7..81b6bae 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -285,6 +285,9 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
/* Otherwise, we are doing the usual "git" diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
+ /* Scale to real terminal size */
+ rev.diffopt.stat_width = -1;
+
/* Default to let external and textconv be used */
DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
diff --git a/diff.c b/diff.c
index a1c06b5..1062f27 100644
--- a/diff.c
+++ b/diff.c
@@ -1389,7 +1389,10 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
line_prefix = msg->buf;
}
- width = options->stat_width ? options->stat_width : 80;
+ if (options->stat_width == -1)
+ width = term_columns();
+ else
+ width = options->stat_width ? options->stat_width : 80;
name_width = options->stat_name_width ? options->stat_name_width : 50;
count = options->stat_count ? options->stat_count : data->nr;
diff --git a/t/t4052-stat-output.sh b/t/t4052-stat-output.sh
index 031107b..4bfd6a5 100755
--- a/t/t4052-stat-output.sh
+++ b/t/t4052-stat-output.sh
@@ -81,6 +81,10 @@ cat >expect80 <<'EOF'
abcd | 1000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
EOF
+cat >expect200 <<'EOF'
+ abcd | 1000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+EOF
+
while read verb expect cmd args
do
test_expect_success "$cmd $verb COLUMNS (big change)" '
@@ -90,7 +94,7 @@ do
'
done <<\EOF
ignores expect80 format-patch -1 --stdout
-ignores expect80 diff HEAD^ HEAD --stat
+respects expect200 diff HEAD^ HEAD --stat
ignores expect80 show --stat
ignores expect80 log -1 --stat
EOF
@@ -146,6 +150,9 @@ EOF
cat >expect80 <<'EOF'
...aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | 1000 ++++++++++++++++++++
EOF
+cat >expect200 <<'EOF'
+ ...aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | 1000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+EOF
while read verb expect cmd args
do
test_expect_success "$cmd $verb COLUMNS (long filename)" '
@@ -155,7 +162,7 @@ do
'
done <<\EOF
ignores expect80 format-patch -1 --stdout
-ignores expect80 diff HEAD^ HEAD --stat
+respects expect200 diff HEAD^ HEAD --stat
ignores expect80 show --stat
ignores expect80 log -1 --stat
EOF
--
1.7.9.2.332.g05f13
^ permalink raw reply related
* [PATCH v7 02/11] diff --stat: tests for long filenames and big change counts
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-24 20:32 UTC (permalink / raw)
To: git, gitster
Cc: Michael J Gruber, pclouds, j.sixt,
Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1330115538-1576-1-git-send-email-zbyszek@in.waw.pl>
In preparation for updates to the "diff --stat" that updates the logic
to split the allotted columns into the name part and the graph part to
make the output more readable, add a handful of tests to document the
corner case behaviour in which long filenames and big changes are shown.
When a pathname is so long that it cannot fit on the column, the current
code truncates it to make sure that the graph part has enough room to show
a meaningful graph. If the actual change is small (e.g. only one line
changed), this results in the final output that is shorter than the width
we aim for. A couple of new tests marked with test_expect_failure
demonstrate this bug.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
t/t4052-stat-output.sh | 182 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 182 insertions(+)
create mode 100755 t/t4052-stat-output.sh
diff --git a/t/t4052-stat-output.sh b/t/t4052-stat-output.sh
new file mode 100755
index 0000000..031107b
--- /dev/null
+++ b/t/t4052-stat-output.sh
@@ -0,0 +1,182 @@
+#!/bin/sh
+#
+# Copyright (c) 2012 Zbigniew Jędrzejewski-Szmek
+#
+
+test_description='test --stat output of various commands'
+
+. ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-terminal.sh
+
+# 120 character name
+name=aaaaaaaaaa
+name=$name$name$name$name$name$name$name$name$name$name$name$name
+test_expect_success 'preparation' '
+ >"$name" &&
+ git add "$name" &&
+ git commit -m message &&
+ echo a >"$name" &&
+ git commit -m message "$name"
+'
+cat >expect80 <<'EOF'
+ ...aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | 1 +
+EOF
+
+cat >expect40 <<-'EOF'
+ ...aaaaaaaaaaaaaaaaaaaaaaaaaa | 1 +
+EOF
+
+while read cmd args
+do
+ test_expect_failure "$cmd graph width defaults to 80 columns" '
+ git $cmd $args >output &&
+ grep " | " output >actual &&
+ test_cmp expect80 actual
+ '
+
+ test_expect_failure "$cmd --stat=width with long name" '
+ git $cmd $args --stat=40 >output &&
+ grep " | " output >actual &&
+ test_cmp expect40 actual
+ '
+
+ test_expect_failure "$cmd --stat-width=width with long name" '
+ git $cmd $args --stat-width=40 >output &&
+ grep " | " output >actual &&
+ test_cmp expect40 actual
+ '
+
+ test_expect_success "$cmd --stat=...,name-width with long name" '
+ git $cmd $args --stat=60,29 >output &&
+ grep " | " output >actual &&
+ test_cmp expect40 actual
+ '
+
+ test_expect_success "$cmd --stat-name-width with long name" '
+ git $cmd $args --stat-name-width=29 >output &&
+ grep " | " output >actual &&
+ test_cmp expect40 actual
+ '
+done <<\EOF
+format-patch -1 --stdout
+diff HEAD^ HEAD --stat
+show --stat
+log -1 --stat
+EOF
+
+
+test_expect_success 'preparation for big change tests' '
+ >abcd &&
+ git add abcd &&
+ git commit -m message &&
+ i=0 &&
+ while test $i -lt 1000
+ do
+ echo $i && i=$(($i + 1))
+ done >abcd &&
+ git commit -m message abcd
+'
+
+cat >expect80 <<'EOF'
+ abcd | 1000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+EOF
+
+while read verb expect cmd args
+do
+ test_expect_success "$cmd $verb COLUMNS (big change)" '
+ COLUMNS=200 git $cmd $args >output
+ grep " | " output >actual &&
+ test_cmp "$expect" actual
+ '
+done <<\EOF
+ignores expect80 format-patch -1 --stdout
+ignores expect80 diff HEAD^ HEAD --stat
+ignores expect80 show --stat
+ignores expect80 log -1 --stat
+EOF
+
+cat >expect <<'EOF'
+ abcd | 1000 ++++++++++++++++++++++++++
+EOF
+
+while read cmd args
+do
+ test_expect_success "$cmd --stat=width with big change" '
+ git $cmd $args --stat=40 >output
+ grep " | " output >actual &&
+ test_cmp expect actual
+ '
+
+ test_expect_success "$cmd --stat-width=width with big change" '
+ git $cmd $args --stat-width=40 >output
+ grep " | " output >actual &&
+ test_cmp expect actual
+ '
+done <<\EOF
+format-patch -1 --stdout
+diff HEAD^ HEAD --stat
+show --stat
+log -1 --stat
+EOF
+
+test_expect_success 'preparation for long filename tests' '
+ cp abcd aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa &&
+ git add aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa &&
+ git commit -m message
+'
+
+cat >expect <<'EOF'
+ ...aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | 1000 +++++
+EOF
+
+while read cmd args
+do
+ test_expect_success "$cmd --stat=width with big change and long name" '
+ git $cmd $args --stat-width=60 >output &&
+ grep " | " output >actual &&
+ test_cmp expect actual
+ '
+done <<\EOF
+format-patch -1 --stdout
+diff HEAD^ HEAD --stat
+show --stat
+log -1 --stat
+EOF
+
+cat >expect80 <<'EOF'
+ ...aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | 1000 ++++++++++++++++++++
+EOF
+while read verb expect cmd args
+do
+ test_expect_success "$cmd $verb COLUMNS (long filename)" '
+ COLUMNS=200 git $cmd $args >output
+ grep " | " output >actual &&
+ test_cmp "$expect" actual
+ '
+done <<\EOF
+ignores expect80 format-patch -1 --stdout
+ignores expect80 diff HEAD^ HEAD --stat
+ignores expect80 show --stat
+ignores expect80 log -1 --stat
+EOF
+
+cat >expect <<'EOF'
+ abcd | 1000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+EOF
+test_expect_success 'merge --stat ignores COLUMNS (big change)' '
+ git checkout -b branch HEAD^^ &&
+ COLUMNS=100 git merge --stat --no-ff master^ >output &&
+ grep " | " output >actual
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+ ...aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | 1000 ++++++++++++++++++++
+EOF
+test_expect_success 'merge --stat ignores COLUMNS (long filename)' '
+ COLUMNS=100 git merge --stat --no-ff master >output &&
+ grep " | " output >actual
+ test_cmp expect actual
+'
+
+test_done
--
1.7.9.2.332.g05f13
^ permalink raw reply related
* [PATCH v7 01/11] make lineno_width() from blame reusable for others
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-24 20:32 UTC (permalink / raw)
To: git, gitster
Cc: Michael J Gruber, pclouds, j.sixt,
Zbigniew Jędrzejewski-Szmek
In-Reply-To: <4F47F394.5070007@in.waw.pl>
builtin/blame.c has a helper function to compute how many columns we
need to show a line-number, whose implementation is reusable as a more
generic helper function to count the number of columns necessary to
show any cardinal number.
Rename it to decimal_width(), move it to pager.c and export it for use
by future callers.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
builtin/blame.c | 18 +++---------------
cache.h | 1 +
| 13 +++++++++++++
3 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 01956c8..b35bd62 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1829,18 +1829,6 @@ static int read_ancestry(const char *graft_file)
}
/*
- * How many columns do we need to show line numbers in decimal?
- */
-static int lineno_width(int lines)
-{
- int i, width;
-
- for (width = 1, i = 10; i <= lines; width++)
- i *= 10;
- return width;
-}
-
-/*
* How many columns do we need to show line numbers, authors,
* and filenames?
*/
@@ -1880,9 +1868,9 @@ static void find_alignment(struct scoreboard *sb, int *option)
if (largest_score < ent_score(sb, e))
largest_score = ent_score(sb, e);
}
- max_orig_digits = lineno_width(longest_src_lines);
- max_digits = lineno_width(longest_dst_lines);
- max_score_digits = lineno_width(largest_score);
+ max_orig_digits = decimal_width(longest_src_lines);
+ max_digits = decimal_width(longest_dst_lines);
+ max_score_digits = decimal_width(largest_score);
}
/*
diff --git a/cache.h b/cache.h
index 881524f..d908184 100644
--- a/cache.h
+++ b/cache.h
@@ -1187,6 +1187,7 @@ extern const char *pager_program;
extern int pager_in_use(void);
extern int pager_use_color;
extern int term_columns(void);
+extern int decimal_width(uintmax_t number);
extern const char *editor_program;
extern const char *askpass_program;
--git a/pager.c b/pager.c
index b790967..60be7bb 100644
--- a/pager.c
+++ b/pager.c
@@ -147,3 +147,16 @@ int term_columns(void)
return term_columns_at_startup;
}
+
+/*
+ * How many columns do we need to show this number in decimal?
+ */
+int decimal_width(uintmax_t number)
+{
+ int width;
+ uintmax_t i;
+
+ for (width = 1, i = 10; i <= number; width++)
+ i *= 10;
+ return width;
+}
--
1.7.9.2.332.g05f13
^ permalink raw reply related
* [PATCH v7 0/11] diff --stat: use the full terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-24 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael J Gruber, pclouds, j.sixt
In-Reply-To: <7vr4xmac6f.fsf@alter.siamese.dyndns.org>
Hi,
I accept your reasoning that a graph narrower than 80 columns would not
look good.
On 02/22/2012 08:41 PM, Junio C Hamano wrote:
> It might be just the matter of raising the artificial cap to much higher
> than 40-column (say, 80-column). A possible alternative may be to declare
> that the perceived ugliness is the user's problem of having overly wide
> terminal in the first place and do without any such cap.
>
> Either is fine, but regressing output on 80-column terminal when showing a
> patch with short filenames and large changes is unacceptable, not because
> I personally use 80-col terminal myself (I don't---mine is a bit wider but
> not 200), but because it changes behaviour from the old code without any
> good justification to do so.
I've taken both options :) The graph-width-limit is turned into an
option (commandline --stat-graph-width and config diff.statGraphWidth),
off by default. Now no tests need to be changed. But if somebody doesn't
like very wide graph output, they can set the config option to something
like 80 and forget about this.
This is on top of today's next. I'm sending 1/11 'make lineno_width()
from blame reusable for others' again, because the version in next is
the previous version before s/int/uintmax_t/.
Changes since v6:
- 40 column limit for the graph part is changed in an optional,
configurable limit, off by default
- parts 7.1/8, 7.2/8, 7.3/8 get their own numbers, and 7.3 is split into
two parts (9/10 is --stat-graph-width and 10/10 is diff.statGraphWidth).
v6:
[1/8] make lineno_width() from blame reusable for others
This is very close to what was in pu, but I'm sending a new version:
- the function argument is changed from int to uintmax_t
(max_change is uintmax_t and 9/9 does decimal_width(max_change).)
[2/8] diff --stat: tests for long filenames and big change counts
- Tests are run for format-patch, diff, log, show, and merge.
- Since tests are not only for format-patch, they are added in a new
file t/t4052-stat-output.sh.
[3/8] diff --stat: use the full terminal width
Add logic to use term_columns() when diffopts.stat_width==-1 and
turn it on in git-diff --stat.
- show_stats() output is adapted to full terminal width only when
diffopts.stat_width==-1.
[4/8] show --stat: use the full terminal width
Enable for git-show.
[5/8] log --stat: use the full terminal width
Enable for log-show.
[6/8] merge --stat: use the full terminal width
Enable for git-merge.
[7/8] diff --stat: limit graph part to 40 columns
Change the logic to divide columns. This part is the unchanged from
v5, just separated from 3/9.
[8/8] diff --stat: use less columns for change counts
This one is optional, to be applied or not, "when the dust settles".
v5:
- tests are moved to an earlier patch
- seq is replaced with a while loop for windows compatibility
- grep -m 1 is replaced with grep " | "
- redirects are made portable
- piped output is split into two commands to verify that the first
command
sucessfully runs to completion
- using decimal_width(change count) is moved to a later patch
- "histogram" is really not used
v4:
- comments are updated and the word "histogram" is banished
- "mopping up" is removed (but the minimum width are guaranteed)
v3:
- use decimal_width(max_change) to calculate number of columns
required for change counts
- rework the logic to divide columns
- document the logic in comments, update docs
- add more tests
v2:
- style fixes
- some tests for git-format-patch added
- patches 3 and 4 squashed together, since they touch the same lines
- graph width is limited to 40 columns, even if there's more space
- patch descriptions extended and cleared up
^ permalink raw reply
* Re: git log -z doesn't separate commits with NULs
From: Junio C Hamano @ 2012-02-24 20:03 UTC (permalink / raw)
To: Jeff King; +Cc: Nikolaj Shurkaev, Jakub Narebski, git
In-Reply-To: <20120224095253.GC11846@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> DESCRIPTION
>> -----------
>> @@ -219,6 +220,12 @@ you can use `--suffix=-patch` to get
>> `0001-description-of-my-change-patch`.
>> range are always formatted as creation patches, independently
>> of this flag.
>>
>> +[\--] <path>...::
>> + Put in patches only those modifications that affect specified files
>> + and folders. It's important to understand that log message of the
>> + commit may become inappropriate because some parts of patch may be
>> + cut off.
>> +
>
> I think that text looks OK. But to my mind, it is not that format-patch
> accepts a path parameter, but rather that it takes arbitrary log-like
> arguments.
The above text is not telling the entire truth, though.
When the command is run with the "--full-diff" option, seleted commits
will be shown in full. This is useful for example when you want to pick
commits that add a new "frotz" driver, which obviously needs to include
"drivers/frotz/" subdirectory, without missing necessary changes to the
Makefiles in the higher level (e.g. "drivers/Makefile"), e.g.
git format-patch --full-diff v1.0..v1.1 -- drivers/frotz
In such a case, "some parts may be cut off" does not make the log message
inappropriate.
On the other hand, people often do not use the resulting history of taking
partial patches (i.e. without --full-diff) and feeding them to "am" as-is.
The operation is used merely to give them a starting point for working on
(possibly) an unrelated topic, and the history is further tweaked with
"rebase -i" or even "commit --amend". It is not "inappropriate" that the
log says more than what the patch does in such a use case. What the log
says is irrelevant.
> I don't know how well tested every option is, though, so maybe it's not
> a good idea to encourage the use of random options.
I obviously agree and also suspect that the real question is not "how well
tested" but "if it makes sense".
I am reasonably sure that over time the options and features that make
sense in the context of producing something that is useful with "am" have
been already made to work well, but I also am fairly certain that the
coverage of the code to explicitly reject options that do not make sense
in that context would be spotty at best. For example, did we carefully
design and implement how format-patch should behave when "-z" is given,
or does the code happen to do whatever it happens to do? If the latter,
did we consider rejecting "-z" when given from the command line and
implement such safety?
^ permalink raw reply
* Re: [PATCH v3] contrib: added git-diffall
From: Junio C Hamano @ 2012-02-24 20:03 UTC (permalink / raw)
To: Tim Henigan; +Cc: git, davvid, stefano.lattarini
In-Reply-To: <1330044581-792-1-git-send-email-tim.henigan@gmail.com>
Tim Henigan <tim.henigan@gmail.com> writes:
> The 'git difftool' command allows the user to view diffs using an
> external tool. It runs a separate instance of the tool for each
> file in the diff. This makes it tedious to review changes spanning
> multiple files.
>
> The 'git-diffall' script instead prepares temporary directories
> with the files to be compared and launches a single instance of
> the external diff tool to view them (i.e. a directory diff).
>
> The 'diff.tool' or 'merge.tool' configuration variable is used
> to specify which external tool is used.
Shouldn't the primary interface "--extcmd=" also be advertised here?
> diff --git a/contrib/diffall/README b/contrib/diffall/README
> new file mode 100644
> index 0000000..111f3f6
> --- /dev/null
> +++ b/contrib/diffall/README
> @@ -0,0 +1,24 @@
> +The git-diffall script provides a directory based diff mechanism
> +for git. The script relies on the diff.tool configuration option
> +to determine what diff viewer is used.
Same here.
> +This script is compatible with most common forms used to specify a
> +range of revisions to diff:
> +
> + 1. git diffall: shows diff between working tree and staged changes
> + 2. git diffall --cached [<commit>]: shows diff between staged
> + changes and HEAD (or other named commit)
> + 3. git diffall <commit>: shows diff between working tree and named
> + commit
> + 4. git diffall <commit> <commit>: show diff between two named commit
I seem to recall the previous round said "named commits" here...
> + 5. git diffall <commit>..<commit>: same as above
> + 6. git diffall <commit>...<commit>: show the changes on the branch
> + containing and up to the second , starting at a common ancestor
> + of both <commit>
> +
> +Note: all forms take an optional path limiter [--] [<path>*]
Doesn't 3. above make "--" mandatory if you give a pathspec? I.e.
... take an optional pathspec [-- <pathspec>]*
> diff --git a/contrib/diffall/git-diffall b/contrib/diffall/git-diffall
> new file mode 100755
> index 0000000..e00fe89
> --- /dev/null
> +++ b/contrib/diffall/git-diffall
> @@ -0,0 +1,261 @@
> ...
> +# mktemp is not available on all platforms (missing from msysgit)
> +# Use a hard-coded tmp dir if it is not available
> +tmp="$(mktemp -d -t tmp.XXXXXX 2>/dev/null)" || {
> + tmp=/git-diffall-tmp.$$
Missing /tmp in front?
> + mkdir "$tmp" || exit 1
> +}
> + ...
> +while test $# != 0
> +do
> + case "$1" in
> + -h|--h|--he|--hel|--help)
> + usage
> + ;;
> + --cached)
> + compare_staged=1
> + ;;
> + --copy-back)
> + copy_back=1
> + ;;
> + -x|--e|--ex|--ext|--extc|--extcm|--extcmd)
> + if test -z $2
testing $# would be more logical, no?
> + then
> + echo You must specify the tool for use with --extcmd
> + usage
> + else
> + diff_tool=$2
> + shift
> + fi
> + ;;
> + --)
> + path_sep=1
The name path_sep makes one wonder "are we somehow talking about
differences between '/' vs '\' here?" In other parts of the system, this
is typically called "dashdash_seen"; the meaning of it is "expect nothing
but pathspecs from here on", so "expect_pathspec" could be an alternative
name for it.
> ...
> +elif test -n "$compare_staged"
> +then
> + while read name
> + do
> + ls_list=$(git ls-files -- "$name")
Ok, the use of $name is now slightly tightened with the surrounding dq
throughout the script. Better (even though $paths are still prone to
splitting by $IFS).
Thanks, will replace what was queued in 'pu'.
^ permalink raw reply
* Re: [BUG?] bulk checkin does not respect filters
From: Junio C Hamano @ 2012-02-24 20:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120224093924.GA11680@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 24, 2012 at 03:28:03AM -0500, Jeff King wrote:
>
>> I don't like repeating all of the convert_to_git policy logic. Perhaps
>> if you pass a NULL buffer to convert_to_git, it should run through its
>> usual logic, stopping just short of actually writing anything, and
>> return a flag indicating whether it _would_ convert...
Makes very good sense. Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] do not stream large files to pack when filters are in use
From: Junio C Hamano @ 2012-02-24 20:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120224094805.GB11846@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'm on the fence about the performance regression above. On the one
> hand, if you're telling git to autocrlf your gigantic binary files, you
> should fix your attributes, and expect not to use the streaming
> optimization until you do.
That is a sensible angle to view the issue from, I would think.
> diff --git a/sha1_file.c b/sha1_file.c
> index f9f8d5e..61f597b 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2720,7 +2720,8 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st,
>
> if (!S_ISREG(st->st_mode))
> ret = index_pipe(sha1, fd, type, path, flags);
> - else if (size <= big_file_threshold || type != OBJ_BLOB)
> + else if (size <= big_file_threshold || type != OBJ_BLOB ||
> + convert_to_git(path, NULL, 0, NULL, 0))
Nice. It would be even nicer to give a readability macro whose name makes
it clear that this is a query (unfortunately we cannot add '?' at the end
of the function name) and not a conversion. Any name suggestions?
By the way, I tried this with the tip of 'pu' as of last night, and the
result segfaults on me in t1050 (hash-object -w) ;-).
^ permalink raw reply
* RE: git and SSL certificates
From: Edward Ned Harvey @ 2012-02-24 20:01 UTC (permalink / raw)
To: 'Shawn Pearce'; +Cc: git
In-Reply-To: <CAJo=hJuyHv_L_zajW-MWEj6fDGggrVDkRWT32mD5TBzD_GzReQ@mail.gmail.com>
> From: Shawn Pearce [mailto:spearce@spearce.org]
> Sent: Friday, February 24, 2012 2:27 PM
>
> Nope. Git uses the system's libcurl, which is probably using the
> system's libssl or libgnutls, which is using the system's
> certificates.
Thanks, this gives me more fuel to go on, because now I know I can reproduce
the problem using any other tool I want - curl for example. Where I'm able
to specify -v for verbose, and get its cert search path.
It's still really bizarre, because the Startcom root CA is indeed present in
the search path, and it is indeed the same root CA that was used to sign my
server cert. So now I'll go ask startcom what they think about it...
If anyone is interested, please say so, and I'll report back here.
Otherwise, I'll probably just let the thread die.
^ permalink raw reply
* Re: FW: question about merge in 1.7.10
From: Junio C Hamano @ 2012-02-24 20:00 UTC (permalink / raw)
To: Marlene Cote; +Cc: git@vger.kernel.org
In-Reply-To: <1F026B57884A5841B330471696849DE9114503D7@MBX021-W4-CA-5.exch021.domain.local>
Marlene Cote <Marlene_Cote@affirmednetworks.com> writes:
> I used merge with -no-commit -no-ff. So, I assume I won't see any
> change in behavior, since merge is not performing commits, right?
The _only_ difference is when
(1) "git merge" is run interactively;
(2) the merge goes cleanly that it does not need to ask help from the
user to resolve conflicts; and
(3) it records the result by creating a commit.
Because your use case with "--no-commit" does not satisfy the last
criteria, I do not expect you to see any difference. Otherwise you may
have found a bug.
As noted in
http://git-blame.blogspot.com/2012/02/anticipating-git-1710.html
please try out the version from the 'master' branch before it gets
released, so that you can help us avoid surprises in the corner cases.
Thanks.
^ permalink raw reply
* Re: [Not A BugReport] git tag -a / git show
From: Romain Vimont (®om) @ 2012-02-24 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsji0yprw.fsf@alter.siamese.dyndns.org>
Thank you for the details.
> *1* technically, tag can apply to any type of object, but it is most
common to apply to a commit.
To what other type of object can you apply a tag ?
Good evening.
Le vendredi 24 février 2012 à 11:50 -0800, Junio C Hamano a écrit :
> "Romain Vimont (®om)" <rom@rom1v.com> writes:
>
> > Now, I edit some files (for example in a config file
> > "mock_data=true"), then I want to tag without commiting this change.
>
> Tag applies to an existing commit [*1*]. Your change in the working tree
> is purely ephemeral until it is committed.
>
> In other words, you don't "tag without committing".
>
> > $ git tag -a v0.1 -m 'My v0.1 with mock data'
>
> By omitting the [<head>] part from your command line for a command whose
> usage is:
>
> usage: git tag [-a|-s|-u <key-id>] [-f] [-m <msg>|-F <file>] <tagname> [<head>]
>
> you asked <head> to default to HEAD, the most recent commit, so the tag
> points at your 0ef41513d0b6 (This is the last commit). The tag message
> should say "My v0.1" without anything else.
>
> And show naturally shows the patch to bring its parent to that tagged
> commit.
>
> If you wanted to keep your mainline pristine without mock data, and want
> to have a playpen that uses mock data, a way to do so is to use a separate
> branch, e.g.
>
> $ git checkout -b playpen
>
> Now, you are on your 'playpen' branch that was forked from the tip of
> whatever branch you were on, perhaps 'master'. Then commit that state
> with whatever change that is specific to the playpen you want to keep out
> of the mainline:
>
> $ edit config.txt ;# set mock_data=true
> $ git commit -a -m 'With mock data'
>
> You can optionally tag the resulting commit if you want to. You are still
> on the 'playpen' branch, so you probably would want to come back to the
> previous branch after you are done.
>
>
> [Footnote]
>
> *1* technically, tag can apply to any type of object, but it is most
> common to apply to a commit.
>
^ permalink raw reply
* Re: [BugReport] git tag -a / git show
From: Romain Vimont (®om) @ 2012-02-24 19:55 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git
In-Reply-To: <4F47E48D.4080501@in.waw.pl>
Thank you for your answer.
After my message this morning, that's what I did: I commited with the
mock data then tag.
Tonight, I just tried something which do exactly what I wanted to do
this morning:
$ git checkout -b temp
$ git commit -a -m 'My config file with mock_data=true'
$ git tag -a v0.1 -m v0.1
$ git checkout master
$ git branch -D temp
With these commands, the tag is associated to a commit which is not in
any branch.
Regards,
©om
Le vendredi 24 février 2012 à 20:27 +0100, Zbigniew Jędrzejewski-Szmek a
écrit :
> On 02/24/2012 11:24 AM, Romain Vimont (®om) wrote:
> > $ git log --pretty=online
> > 0ef41513d0b6d0ad28f21d0ac1da7096ad1dc6ff This is the last commit
> > a4702c69c28484d357179166cf3b116764da20a4 This is a commit
> >
> > Now, I edit some files (for example in a config file "mock_data=true"),
> > then I want to tag without commiting this change.
> >
> > $ git tag -a v0.1 -m 'My v0.1 with mock data'
>
> > And it shows the diff between a4702c69c28484d357179166cf3b116764da20a4
> > and 0ef41513d0b6d0ad28f21d0ac1da7096ad1dc6ff (the two last commits).
>
> Hi Romain,
> git tag attaches the tag to the last commit, 0ef41513 in your case.
> Dirty changes in your tree are ignored by the tag command. You would
> have to commit them first, and attach the tag to this new commit.
>
> zbyszek
>
^ permalink raw reply
* Re: [Not A BugReport] git tag -a / git show
From: Junio C Hamano @ 2012-02-24 19:50 UTC (permalink / raw)
To: Romain Vimont (®om); +Cc: git
In-Reply-To: <b05f03b381140ca57a7d03a934f605bd@rom1v.com>
"Romain Vimont (®om)" <rom@rom1v.com> writes:
> Now, I edit some files (for example in a config file
> "mock_data=true"), then I want to tag without commiting this change.
Tag applies to an existing commit [*1*]. Your change in the working tree
is purely ephemeral until it is committed.
In other words, you don't "tag without committing".
> $ git tag -a v0.1 -m 'My v0.1 with mock data'
By omitting the [<head>] part from your command line for a command whose
usage is:
usage: git tag [-a|-s|-u <key-id>] [-f] [-m <msg>|-F <file>] <tagname> [<head>]
you asked <head> to default to HEAD, the most recent commit, so the tag
points at your 0ef41513d0b6 (This is the last commit). The tag message
should say "My v0.1" without anything else.
And show naturally shows the patch to bring its parent to that tagged
commit.
If you wanted to keep your mainline pristine without mock data, and want
to have a playpen that uses mock data, a way to do so is to use a separate
branch, e.g.
$ git checkout -b playpen
Now, you are on your 'playpen' branch that was forked from the tip of
whatever branch you were on, perhaps 'master'. Then commit that state
with whatever change that is specific to the playpen you want to keep out
of the mainline:
$ edit config.txt ;# set mock_data=true
$ git commit -a -m 'With mock data'
You can optionally tag the resulting commit if you want to. You are still
on the 'playpen' branch, so you probably would want to come back to the
previous branch after you are done.
[Footnote]
*1* technically, tag can apply to any type of object, but it is most
common to apply to a commit.
^ permalink raw reply
* RE: FW: question about merge in 1.7.10
From: Marlene Cote @ 2012-02-24 19:33 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git@vger.kernel.org
In-Reply-To: <4F47E51B.6080401@in.waw.pl>
I know that the tree will be dirty. The change to git in 1.7.10 says that the merge will require a commit message when the command is run. Since I am not committing, I need to supply a message, but only later when I commit. Not when I execute the merge command. This means my scripts don't have to change.
-----Original Message-----
From: Zbigniew Jędrzejewski-Szmek [mailto:zbyszek@in.waw.pl]
Sent: Friday, February 24, 2012 2:30 PM
To: Marlene Cote
Cc: git@vger.kernel.org
Subject: Re: FW: question about merge in 1.7.10
On 02/24/2012 03:33 PM, Marlene Cote wrote:
>
> I used merge with -no-commit -no-ff. So, I assume I won't see any change in behavior, since merge is not performing commits, right?
Hi Marlene,
--no-commit only stops the last step, i.e. making of the commit. The tree (working files) is changed before that. So basically after a merge with --no-commit, your tree will be dirty and git status will show modified files.
zbyszek
^ permalink raw reply
* Re: Improving merge messages for 1.7.10 and making "pull" easier
From: Junio C Hamano @ 2012-02-24 19:39 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Git Mailing List, Thomas Rast, Linus Torvalds
In-Reply-To: <CACBZZX5UVq9k7jvSy3m+yMVj7_JbfLp8ugFWf2gGFdMz_8GPEA@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Firstly (and as a more general thing) I think we should add a mention
> of "git merge --abort" to the message, just saving an empty file is
> not sufficient to fully clear the merge state:
Makes sense, but the new message does not quite parse.
>> "Lines starting with '#' will be ignored, and an empty message followed\n"
>> "by 'git merge --abort' the merge.\n");
Perhaps s/the merge/aborts &/ or something.
> Additionally, perhaps it would be a good idea to:
>
> * Detect if the user didn't run this explicitly but implicitly from a
> "git pull". We could pass some env var along or another option
> (e.g. --internal-from-porcelain=pull) and add this:
>
> You've merged implicitly via a "git pull", if you're just
> updating some local work in progress to keep up with upstream
> you may want to use "git pull --rebase" instead (or set the
> pull.rebase configuration variable) to rebase instead of merge.
Won't this message be given to _all_ users of "git pull", even to the ones
who already have decided correctly that "pull" is the right thing in their
situation? With a new advice.* settings to squelch it, perhaps.
> * Explicitly check if we're merging an updated upstream into the
> work-in-progress topic,...
It might be a worthy goal, but how would we detect it? A few examples
that we shouldn't give an unhelpful advice with a false positive are
merges into:
- The 'master' branch used by people who use Git as an improved CVS, when
they do an equivalent of 'cvs update'. Merging the updated 'master'
from the central repository into their 'master' that contains their
work that may or may not be ready to be pushed back is how their
project works. It is a norm for them to make such a merge, even though
more experienced people may prefer to see the history of their project
kept cleaner by suggesting their project participants to use their own
topic branches.
- Integration branches like my 'next', when it gets a merge from
'master'. This is "merging an updated upstream" but is done in order to
keep the promise that 'next' would contain everything in 'master'.
And what alternative would we offer? If we were to suggest "rebase", we
would also need to consider the topic of the other a-couple-of-days-old
thread to detect which part of history is no longer subject to rewrite.
> I work with a lot of inexperienced git users and a lot of them are
> going to be very confused by this change. I still think it's a good
> change to make, but we could do a lot more to mitigate the inevitable
> confusion.
What exact change are you talking about with "this change"? Earlier you
had a chance to edit the merge log only when it needed your help resolving
(hence you did a separate "git commit" to record it) but you had to "git
commit --amend" (or start with "git merge --no-commit") to edit the merge
log if it did not need any help resolving conflicts, but now you do not
have to. Is that the change you have in mind?
I would like to know how that would lead to an "inevitable confusion".
Admittedly, the original without any "# Please do X" comment, the user may
wonder what is being asked of him when he sees the editor for the first
time, but I thought Thomas's patch took care of that issue.
> One thing that would help these users in particular would be to have
> some easy to use replacement for their frequent use of "git
> pull".
After this part, I think you shifted into a different topic.
I have mixed feelings about "rebase your unpublished work and keep it
always a descendant of the upstream" workflow you seem to be advocating.
It _might_ deserve a bit more visibility, but I do not think rewording
this message done during "merge" is the place to do so.
> They don't often commit their work (because of git inexperience) so
> rebasing will error out because the tree is unclean.
That is a *good* thing, isn't it? There lies the perfect opportunity for
them to train their fingers to commit first and then rebase.
^ permalink raw reply
* Re: FW: question about merge in 1.7.10
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-24 19:29 UTC (permalink / raw)
To: Marlene Cote; +Cc: git@vger.kernel.org
In-Reply-To: <1F026B57884A5841B330471696849DE9114503D7@MBX021-W4-CA-5.exch021.domain.local>
On 02/24/2012 03:33 PM, Marlene Cote wrote:
>
> I used merge with -no-commit -no-ff. So, I assume I won't see any change in behavior, since merge is not performing commits, right?
Hi Marlene,
--no-commit only stops the last step, i.e. making of the commit. The
tree (working files) is changed before that. So basically after a merge
with --no-commit, your tree will be dirty and git status will show
modified files.
zbyszek
^ permalink raw reply
* Re: git and SSL certificates
From: Shawn Pearce @ 2012-02-24 19:27 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000501ccf328$1efe1070$5cfa3150$@nedharvey.com>
On Fri, Feb 24, 2012 at 11:11, Edward Ned Harvey <git@nedharvey.com> wrote:
> I have a git server hosted on https (github enterprise virtual appliance),
> using a valid signed cert from startcom, which passes all the SSL checks for
> any browser I use on any OS (IE, Firefox, Safari, Chrome, on Ubuntu, Mac
> OSX, MS Win7) but when I connect to it using git, git complains about the
> cert, but it's platform dependent, and it doesn't seem to make any sense...
> Does git have its own set of SSL trusted root CA's compiled in at build time
> or something? It seems weird that it's apparently not using the trusted
> root CA's from the OS...
Nope. Git uses the system's libcurl, which is probably using the
system's libssl or libgnutls, which is using the system's
certificates.
^ permalink raw reply
* Re: [BugReport] git tag -a / git show
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-24 19:27 UTC (permalink / raw)
To: "Romain Vimont (®om)"; +Cc: git
In-Reply-To: <b05f03b381140ca57a7d03a934f605bd@rom1v.com>
On 02/24/2012 11:24 AM, Romain Vimont (®om) wrote:
> $ git log --pretty=online
> 0ef41513d0b6d0ad28f21d0ac1da7096ad1dc6ff This is the last commit
> a4702c69c28484d357179166cf3b116764da20a4 This is a commit
>
> Now, I edit some files (for example in a config file "mock_data=true"),
> then I want to tag without commiting this change.
>
> $ git tag -a v0.1 -m 'My v0.1 with mock data'
> And it shows the diff between a4702c69c28484d357179166cf3b116764da20a4
> and 0ef41513d0b6d0ad28f21d0ac1da7096ad1dc6ff (the two last commits).
Hi Romain,
git tag attaches the tag to the last commit, 0ef41513 in your case.
Dirty changes in your tree are ignored by the tag command. You would
have to commit them first, and attach the tag to this new commit.
zbyszek
^ permalink raw reply
* git and SSL certificates
From: Edward Ned Harvey @ 2012-02-24 19:11 UTC (permalink / raw)
To: git
I have a git server hosted on https (github enterprise virtual appliance),
using a valid signed cert from startcom, which passes all the SSL checks for
any browser I use on any OS (IE, Firefox, Safari, Chrome, on Ubuntu, Mac
OSX, MS Win7) but when I connect to it using git, git complains about the
cert, but it's platform dependent, and it doesn't seem to make any sense...
Does git have its own set of SSL trusted root CA's compiled in at build time
or something? It seems weird that it's apparently not using the trusted
root CA's from the OS...
I have not tried re-signing my cert using a different CA. I see github uses
DigiCert. My clients do not complain about SSL cert when cloning from
github.
The test command is, simply:
git clone https://user@server.com/user/project.git
(Obviously, using a real username, a real servername, and a real project
name instead of the line above.)
** On OSX, it works no problem. This is OSX 10.7 Lion, upgraded from 10.6
SL, with 4.1 upgraded from XCode 3.2.6. Git version 1.7.4.4
** On ubuntu, oneiric x86_64, git version 1.7.5.4, it says:
error: server certificate verification failed. CAfile:
/etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing
https://user@server.com/user/project.git/info/refs
fatal: HTTP request failed
This is annoying, because ... It names the location where it's searching for
the root certificates, so I thought maybe the startcom root CA wasn't in
there, so I went and looked, and confirmed it's there. Compared the actual
pem encoded root ca cert string to the one that signed my server's cert, and
it's definitely there.
On linux, users are able to workaround using GIT_SSL_NO_VERIFY=1, but that
kind of defeats the purpose. I don't want them doing this.
** On Win 7 64bit, tortoisegit 1.6.5.0 based on git 1.7.3.1, it says:
error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed while accessing https://user@server.com/user/project.git/info/refs
fatal: HTTP request failed
Cloning into C:\workdir
I don't see any way to workaround, but haven't looked very hard for a
windows equivalent of GIT_SSL_NO_VERIFY
** On Win 7 64bit, cygwin git version 1.7.9, it says:
error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed while accessing https://user@server.com/user/project.git/info/refs
fatal: HTTP request failed
Also, it ignores the presence of GIT_SSL_NO_VERIFY. So there isn't any
known workaround for cygwin.
^ permalink raw reply
* Re: [BUG?] bulk checkin does not respect filters
From: Junio C Hamano @ 2012-02-24 18:48 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20120224075425.GA18688@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Isn't write_entry the _other_ side of things. I.e., checking out, not
> checking in?
Ah, of course.
^ permalink raw reply
* Re: measuring the % change between two commits
From: Sitaram Chamarty @ 2012-02-24 17:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vpqd52tqr.fsf@alter.siamese.dyndns.org>
On Fri, Feb 24, 2012 at 1:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> I could do a --numstat and then do a 'wc -l' on each file I guess, but
>> I was hoping to avoid that.
>>
>> --dirstat gives you a percentage but does not count the top level directory.
>
> Note that dirstat is not about "how much damage was caused to the entire
> codebase". It only measures "How is the damage this patch causes
> distributed across directories it touches". It was unclear from your "a %
> measure for the changes between two commits" which one you meant, but I am
> guessing from your "--numstat and wc -l" reference that you are asking for
> the former, e.g. we have 300,000 lines of code and between these two
> commits 10,000 lines changed, hence we updated 3% of the codebase during
> that period".
yes; I wanted an overall figure. Clearly I misunderstood dirstat
then. (Should have guessed from the "...may not total to 100%..."
comment somewhere.
Thanks
--
Sitaram
^ permalink raw reply
* Re: git gui: how to fetch a single branch
From: Neal Kreitzinger @ 2012-02-24 16:57 UTC (permalink / raw)
To: Matt Seitz (matseitz); +Cc: git
In-Reply-To: <70952A932255A2489522275A628B97C31294E91C@xmb-sjc-233.amer.cisco.com>
On 2/23/2012 5:58 PM, Matt Seitz (matseitz) wrote:
> How can I use "git gui" to fetch a single branch from a remote
> repository?
>
> If I select Remote->Fetch From, and then a remote repository, it appears
> to always fetch all the branches from the remote repository with no
> option to select which branch I want to fetch.
>
One way you can do it is to create a remote to that branch (see -t
option of git remote manpage). Then fetching that remote only fetches
that branch. Of course, this is practical if you are interested in
fetching certain branches consistently, but not as practical for
fetching random single branches frequently.
v/r,
neal
^ permalink raw reply
* Re: [PATCH 2/2] index-pack: reduce memory usage when the pack has large blobs
From: Ian Kumlien @ 2012-02-24 16:16 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1330086201-13916-2-git-send-email-pclouds@gmail.com>
On Fri, Feb 24, 2012 at 07:23:21PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This command unpacks every non-delta objects in order to:
>
> 1. calculate sha-1
> 2. do byte-to-byte sha-1 collision test if we happen to have objects
> with the same sha-1
> 3. validate object content in strict mode
>
> All this requires the entire object to stay in memory, a bad news for
> giant blobs. This patch lowers memory consumption by not saving the
> object in memory whenever possible, calculating SHA-1 while unpacking
> the object.
>
> This patch assumes that the collision test is rarely needed. The
> collision test will be done later in second pass if necessary, which
> puts the entire object back to memory again (We could even do the
> collision test without putting the entire object back in memory, by
> comparing as we unpack it).
>
> In strict mode, it always keeps non-blob objects in memory for
> validation (blobs do not need data validation). "--strict --verify"
> also keeps blobs in memory.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Writing objects: 100% (1425/1425), 56.06 MiB | 4.62 MiB/s, done.
Total 1425 (delta 790), reused 1425 (delta 790)
fatal: Out of memory, malloc failed (tried to allocate 3310214315 bytes)
fatal: Out of memory, malloc failed (tried to allocate 3310214315 bytes)
fatal: Out of memory, malloc failed (tried to allocate 3310214315 bytes)
fatal: Out of memory, malloc failed (tried to allocate 3310214315 bytes)
To ../test_data/
! [remote rejected] master -> master (missing necessary objects)
! [remote rejected] origin/HEAD -> origin/HEAD (missing necessary objects)
! [remote rejected] origin/master -> origin/master (missing necessary objects)
error: failed to push some refs to '../test_data/'
So there are additional code paths to look at... =(
^ 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