* [PATCH v5 01/16] Git.pm: add subroutines for commenting lines
From: Vasco Almeida @ 2016-11-08 12:08 UTC (permalink / raw)
To: git
Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA, Jakub Narębski, David Aguilar,
Junio C Hamano
In-Reply-To: <20161005172110.30801-1-vascomalmeida@sapo.pt>
Add subroutines prefix_lines and comment_lines.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
perl/Git.pm | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index b2732822a..17be59fb7 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1438,6 +1438,29 @@ sub END {
} # %TEMP_* Lexical Context
+=item prefix_lines ( PREFIX, STRING )
+
+Prefixes lines in C<STRING> with C<PREFIX>.
+
+=cut
+
+sub prefix_lines {
+ my ($prefix, $string) = @_;
+ $string =~ s/^/$prefix/mg;
+ return $string;
+}
+
+=item comment_lines ( STRING )
+
+Comments lines following core.commentchar configuration.
+
+=cut
+
+sub comment_lines {
+ my $comment_line_char = config("core.commentchar") || '#';
+ return prefix_lines("$comment_line_char ", @_);
+}
+
=back
=head1 ERROR HANDLING
--
2.11.0.rc0.23.g8236252
^ permalink raw reply related
* [PATCH v5 02/16] i18n: add--interactive: mark strings for translation
From: Vasco Almeida @ 2016-11-08 12:08 UTC (permalink / raw)
To: git
Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA, Jakub Narębski, David Aguilar,
Junio C Hamano
In-Reply-To: <20161005172110.30801-1-vascomalmeida@sapo.pt>
Mark simple strings (without interpolation) for translation.
Brackets around first parameter of ternary operator is necessary because
otherwise xgettext fails to extract strings marked for translation from
the rest of the file.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
git-add--interactive.perl | 76 ++++++++++++++++++++++++++---------------------
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index ee3d81269..cf216ecb6 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -4,6 +4,7 @@ use 5.008;
use strict;
use warnings;
use Git;
+use Git::I18N;
binmode(STDOUT, ":raw");
@@ -253,8 +254,9 @@ sub list_untracked {
run_cmd_pipe(qw(git ls-files --others --exclude-standard --), @ARGV);
}
-my $status_fmt = '%12s %12s %s';
-my $status_head = sprintf($status_fmt, 'staged', 'unstaged', 'path');
+# TRANSLATORS: you can adjust this to align "git add -i" status menu
+my $status_fmt = __('%12s %12s %s');
+my $status_head = sprintf($status_fmt, __('staged'), __('unstaged'), __('path'));
{
my $initial;
@@ -680,7 +682,7 @@ sub update_cmd {
my @mods = list_modified('file-only');
return if (!@mods);
- my @update = list_and_choose({ PROMPT => 'Update',
+ my @update = list_and_choose({ PROMPT => __('Update'),
HEADER => $status_head, },
@mods);
if (@update) {
@@ -692,7 +694,7 @@ sub update_cmd {
}
sub revert_cmd {
- my @update = list_and_choose({ PROMPT => 'Revert',
+ my @update = list_and_choose({ PROMPT => __('Revert'),
HEADER => $status_head, },
list_modified());
if (@update) {
@@ -726,13 +728,13 @@ sub revert_cmd {
}
sub add_untracked_cmd {
- my @add = list_and_choose({ PROMPT => 'Add untracked' },
+ my @add = list_and_choose({ PROMPT => __('Add untracked') },
list_untracked());
if (@add) {
system(qw(git update-index --add --), @add);
say_n_paths('added', @add);
} else {
- print "No untracked files.\n";
+ print __("No untracked files.\n");
}
print "\n";
}
@@ -1166,8 +1168,14 @@ sub edit_hunk_loop {
}
else {
prompt_yesno(
- 'Your edited hunk does not apply. Edit again '
- . '(saying "no" discards!) [y/n]? '
+ # TRANSLATORS: do not translate [y/n]
+ # The program will only accept that input
+ # at this point.
+ # Consider translating (saying "no" discards!) as
+ # (saying "n" for "no" discards!) if the translation
+ # of the word "no" does not start with n.
+ __('Your edited hunk does not apply. Edit again '
+ . '(saying "no" discards!) [y/n]? ')
) or return undef;
}
}
@@ -1213,11 +1221,11 @@ sub apply_patch_for_checkout_commit {
run_git_apply 'apply '.$reverse, @_;
return 1;
} elsif (!$applies_index) {
- print colored $error_color, "The selected hunks do not apply to the index!\n";
- if (prompt_yesno "Apply them to the worktree anyway? ") {
+ print colored $error_color, __("The selected hunks do not apply to the index!\n");
+ if (prompt_yesno __("Apply them to the worktree anyway? ")) {
return run_git_apply 'apply '.$reverse, @_;
} else {
- print colored $error_color, "Nothing was applied.\n";
+ print colored $error_color, __("Nothing was applied.\n");
return 0;
}
} else {
@@ -1237,9 +1245,9 @@ sub patch_update_cmd {
if (!@mods) {
if (@all_mods) {
- print STDERR "Only binary files changed.\n";
+ print STDERR __("Only binary files changed.\n");
} else {
- print STDERR "No changes.\n";
+ print STDERR __("No changes.\n");
}
return 0;
}
@@ -1247,7 +1255,7 @@ sub patch_update_cmd {
@them = @mods;
}
else {
- @them = list_and_choose({ PROMPT => 'Patch update',
+ @them = list_and_choose({ PROMPT => __('Patch update'),
HEADER => $status_head, },
@mods);
}
@@ -1397,12 +1405,12 @@ sub patch_update_file {
my $response = $1;
my $no = $ix > 10 ? $ix - 10 : 0;
while ($response eq '') {
- my $extra = "";
$no = display_hunks(\@hunk, $no);
if ($no < $num) {
- $extra = " (<ret> to see more)";
+ print __("go to which hunk (<ret> to see more)? ");
+ } else {
+ print __("go to which hunk? ");
}
- print "go to which hunk$extra? ";
$response = <STDIN>;
if (!defined $response) {
$response = '';
@@ -1439,7 +1447,7 @@ sub patch_update_file {
elsif ($line =~ m|^/(.*)|) {
my $regex = $1;
if ($1 eq "") {
- print colored $prompt_color, "search for regex? ";
+ print colored $prompt_color, __("search for regex? ");
$regex = <STDIN>;
if (defined $regex) {
chomp $regex;
@@ -1462,7 +1470,7 @@ sub patch_update_file {
$iy++;
$iy = 0 if ($iy >= $num);
if ($ix == $iy) {
- error_msg "No hunk matches the given pattern\n";
+ error_msg __("No hunk matches the given pattern\n");
last;
}
}
@@ -1474,7 +1482,7 @@ sub patch_update_file {
$ix--;
}
else {
- error_msg "No previous hunk\n";
+ error_msg __("No previous hunk\n");
}
next;
}
@@ -1483,7 +1491,7 @@ sub patch_update_file {
$ix++;
}
else {
- error_msg "No next hunk\n";
+ error_msg __("No next hunk\n");
}
next;
}
@@ -1496,13 +1504,13 @@ sub patch_update_file {
}
}
else {
- error_msg "No previous hunk\n";
+ error_msg __("No previous hunk\n");
}
next;
}
elsif ($line =~ /^j/) {
if ($other !~ /j/) {
- error_msg "No next hunk\n";
+ error_msg __("No next hunk\n");
next;
}
}
@@ -1560,18 +1568,18 @@ sub diff_cmd {
my @mods = list_modified('index-only');
@mods = grep { !($_->{BINARY}) } @mods;
return if (!@mods);
- my (@them) = list_and_choose({ PROMPT => 'Review diff',
+ my (@them) = list_and_choose({ PROMPT => __('Review diff'),
IMMEDIATE => 1,
HEADER => $status_head, },
@mods);
return if (!@them);
- my $reference = is_initial_commit() ? get_empty_tree() : 'HEAD';
+ my $reference = (is_initial_commit()) ? get_empty_tree() : 'HEAD';
system(qw(git diff -p --cached), $reference, '--',
map { $_->{VALUE} } @them);
}
sub quit_cmd {
- print "Bye.\n";
+ print __("Bye.\n");
exit(0);
}
@@ -1594,32 +1602,32 @@ sub process_args {
if ($1 eq 'reset') {
$patch_mode = 'reset_head';
$patch_mode_revision = 'HEAD';
- $arg = shift @ARGV or die "missing --";
+ $arg = shift @ARGV or die __("missing --");
if ($arg ne '--') {
$patch_mode_revision = $arg;
$patch_mode = ($arg eq 'HEAD' ?
'reset_head' : 'reset_nothead');
- $arg = shift @ARGV or die "missing --";
+ $arg = shift @ARGV or die __("missing --");
}
} elsif ($1 eq 'checkout') {
- $arg = shift @ARGV or die "missing --";
+ $arg = shift @ARGV or die __("missing --");
if ($arg eq '--') {
$patch_mode = 'checkout_index';
} else {
$patch_mode_revision = $arg;
$patch_mode = ($arg eq 'HEAD' ?
'checkout_head' : 'checkout_nothead');
- $arg = shift @ARGV or die "missing --";
+ $arg = shift @ARGV or die __("missing --");
}
} elsif ($1 eq 'stage' or $1 eq 'stash') {
$patch_mode = $1;
- $arg = shift @ARGV or die "missing --";
+ $arg = shift @ARGV or die __("missing --");
} else {
die "unknown --patch mode: $1";
}
} else {
$patch_mode = 'stage';
- $arg = shift @ARGV or die "missing --";
+ $arg = shift @ARGV or die __("missing --");
}
die "invalid argument $arg, expecting --"
unless $arg eq "--";
@@ -1641,10 +1649,10 @@ sub main_loop {
[ 'help', \&help_cmd, ],
);
while (1) {
- my ($it) = list_and_choose({ PROMPT => 'What now',
+ my ($it) = list_and_choose({ PROMPT => __('What now'),
SINGLETON => 1,
LIST_FLAT => 4,
- HEADER => '*** Commands ***',
+ HEADER => __('*** Commands ***'),
ON_EOF => \&quit_cmd,
IMMEDIATE => 1 }, @cmd);
if ($it) {
--
2.11.0.rc0.23.g8236252
^ permalink raw reply related
* [PATCH v5 00/16] Mark strings in Perl scripts for translation
From: Vasco Almeida @ 2016-11-08 12:08 UTC (permalink / raw)
To: git
Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA, Jakub Narębski, David Aguilar,
Junio C Hamano
In-Reply-To: <20161005172110.30801-1-vascomalmeida@sapo.pt>
Mark messages in some perl scripts for translation.
In these series v5:
- Add and use a subroutine to comment lines. This way we can mark strings
for translation without including the comment char within them.
- Mark for translation a message for the user when she is composing an
e-mail in git-send-email.perl.
Interdiff included below.
Vasco Almeida (16):
Git.pm: add subroutines for commenting lines
i18n: add--interactive: mark strings for translation
i18n: add--interactive: mark simple here-documents for translation
i18n: add--interactive: mark strings with interpolation for
translation
i18n: clean.c: match string with git-add--interactive.perl
i18n: add--interactive: mark plural strings
i18n: add--interactive: mark patch prompt for translation
i18n: add--interactive: i18n of help_patch_cmd
i18n: add--interactive: mark edit_hunk_manually message for
translation
i18n: add--interactive: remove %patch_modes entries
i18n: add--interactive: mark status words for translation
i18n: send-email: mark strings for translation
i18n: send-email: mark warnings and errors for translation
i18n: send-email: mark string with interpolation for translation
i18n: send-email: mark composing message for translation
i18n: difftool: mark warnings for translation
Makefile | 3 +-
builtin/clean.c | 10 +-
git-add--interactive.perl | 329 ++++++++++++++++++++++++++++++----------------
git-difftool.perl | 22 ++--
git-send-email.perl | 192 ++++++++++++++-------------
perl/Git.pm | 23 ++++
perl/Git/I18N.pm | 19 ++-
t/t0202/test.pl | 14 +-
8 files changed, 391 insertions(+), 221 deletions(-)
-- >8 --
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 4754104..56e6889 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1039,26 +1039,26 @@ sub color_diff {
my %edit_hunk_manually_modes = (
stage => N__(
-"# If the patch applies cleanly, the edited hunk will immediately be
-# marked for staging."),
+"If the patch applies cleanly, the edited hunk will immediately be
+marked for staging."),
stash => N__(
-"# If the patch applies cleanly, the edited hunk will immediately be
-# marked for stashing."),
+"If the patch applies cleanly, the edited hunk will immediately be
+marked for stashing."),
reset_head => N__(
-"# If the patch applies cleanly, the edited hunk will immediately be
-# marked for unstaging."),
+"If the patch applies cleanly, the edited hunk will immediately be
+marked for unstaging."),
reset_nothead => N__(
-"# If the patch applies cleanly, the edited hunk will immediately be
-# marked for applying."),
+"If the patch applies cleanly, the edited hunk will immediately be
+marked for applying."),
checkout_index => N__(
-"# If the patch applies cleanly, the edited hunk will immediately be
-# marked for discarding"),
+"If the patch applies cleanly, the edited hunk will immediately be
+marked for discarding"),
checkout_head => N__(
-"# If the patch applies cleanly, the edited hunk will immediately be
-# marked for discarding."),
+"If the patch applies cleanly, the edited hunk will immediately be
+marked for discarding."),
checkout_nothead => N__(
-"# If the patch applies cleanly, the edited hunk will immediately be
-# marked for applying."),
+"If the patch applies cleanly, the edited hunk will immediately be
+marked for applying."),
);
sub edit_hunk_manually {
@@ -1068,21 +1068,22 @@ sub edit_hunk_manually {
my $fh;
open $fh, '>', $hunkfile
or die sprintf(__("failed to open hunk edit file for writing: %s"), $!);
- print $fh __("# Manual hunk edit mode -- see bottom for a quick guide\n");
+ print $fh Git::comment_lines __("Manual hunk edit mode -- see bottom for a quick guide\n");
print $fh @$oldtext;
my $is_reverse = $patch_mode_flavour{IS_REVERSE};
my ($remove_plus, $remove_minus) = $is_reverse ? ('-', '+') : ('+', '-');
- print $fh sprintf(__(
-"# ---
-# To remove '%s' lines, make them ' ' lines (context).
-# To remove '%s' lines, delete them.
-# Lines starting with # will be removed.
-#\n"), $remove_minus, $remove_plus),
-__($edit_hunk_manually_modes{$patch_mode}), __(
+ my $comment_line_char = Git::config("core.commentchar") || '#';
+ print $fh Git::comment_lines sprintf(__(
+"---
+To remove '%s' lines, make them ' ' lines (context).
+To remove '%s' lines, delete them.
+Lines starting with %s will be removed.
+\n"), $remove_minus, $remove_plus, $comment_line_char) .
+__($edit_hunk_manually_modes{$patch_mode}) ."\n". __(
# TRANSLATORS: 'it' refers to the patch mentioned in the previous messages.
-" If it does not apply cleanly, you will be given
-# an opportunity to edit again. If all lines of the hunk are removed,
-# then the edit is aborted and the hunk is left unchanged.\n");
+"If it does not apply cleanly, you will be given an opportunity to
+edit again. If all lines of the hunk are removed, then the edit is
+aborted and the hunk is left unchanged.\n");
close $fh;
chomp(my $editor = run_cmd_pipe(qw(git var GIT_EDITOR)));
@@ -1094,7 +1095,7 @@ __($edit_hunk_manually_modes{$patch_mode}), __(
open $fh, '<', $hunkfile
or die sprintf(__("failed to open hunk edit file for reading: %s"), $!);
- my @newtext = grep { !/^#/ } <$fh>;
+ my @newtext = grep { !/^$comment_line_char/ } <$fh>;
close $fh;
unlink $hunkfile;
diff --git a/git-send-email.perl b/git-send-email.perl
index 5c01425..bbeb9fb 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -671,18 +671,20 @@ if ($compose) {
my $tpl_subject = $initial_subject || '';
my $tpl_reply_to = $initial_reply_to || '';
- print $c <<EOT;
+ print $c <<EOT1, Git::prefix_lines("GIT: ", __ <<EOT2), <<EOT3;
From $tpl_sender # This line is ignored.
-GIT: Lines beginning in "GIT:" will be removed.
-GIT: Consider including an overall diffstat or table of contents
-GIT: for the patch you are writing.
-GIT:
-GIT: Clear the body content if you don't wish to send a summary.
+EOT1
+Lines beginning in "GIT:" will be removed.
+Consider including an overall diffstat or table of contents
+for the patch you are writing.
+
+Clear the body content if you don't wish to send a summary.
+EOT2
From: $tpl_sender
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
-EOT
+EOT3
for my $f (@files) {
print $c get_patch_subject($f);
}
diff --git a/perl/Git.pm b/perl/Git.pm
index b273282..17be59f 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1438,6 +1438,29 @@ sub END {
} # %TEMP_* Lexical Context
+=item prefix_lines ( PREFIX, STRING )
+
+Prefixes lines in C<STRING> with C<PREFIX>.
+
+=cut
+
+sub prefix_lines {
+ my ($prefix, $string) = @_;
+ $string =~ s/^/$prefix/mg;
+ return $string;
+}
+
+=item comment_lines ( STRING )
+
+Comments lines following core.commentchar configuration.
+
+=cut
+
+sub comment_lines {
+ my $comment_line_char = config("core.commentchar") || '#';
+ return prefix_lines("$comment_line_char ", @_);
+}
+
=back
=head1 ERROR HANDLING
diff --git a/perl/Git/I18N.pm b/perl/Git/I18N.pm
index 32c4568..c41425c 100644
--- a/perl/Git/I18N.pm
+++ b/perl/Git/I18N.pm
@@ -74,7 +74,7 @@ Git::I18N - Perl interface to Git's Gettext localizations
printf __("The following error occurred: %s\n"), $error;
- printf __n("commited %d file", "commited %d files", $files), $files;
+ printf __n("commited %d file\n", "commited %d files\n", $files), $files;
=head1 DESCRIPTION
@@ -95,12 +95,14 @@ L<Locale::Messages>'s gettext function if all goes well, otherwise our
passthrough fallback function.
=head2 __n($$$)
+
L<Locale::Messages>'s ngettext function or passthrough fallback function.
=head2 N__($)
-No-op that only returns its argument. Use this if you want xgettext to
-extract the text to the pot template but do not want to trigger retrival of
-the translation at run time.
+
+No-operation that only returns its argument. Use this if you want xgettext to
+extract the text to the pot template but do not want to trigger retrival of the
+translation at run time.
=head1 AUTHOR
-- >8 --
--
2.11.0.rc0.23.g8236252
^ permalink raw reply related
* Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate
From: Ian Jackson @ 2016-11-08 10:51 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list, Junio C Hamano
In-Reply-To: <CA+P7+xoQFsN1tPvKCA6+aRMChFwpMs73D=2kwvVRcxALWK0mZQ@mail.gmail.com>
Jacob Keller writes ("Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate"):
> On Mon, Nov 7, 2016 at 4:52 PM, Ian Jackson
> <ijackson@chiark.greenend.org.uk> wrote:
> > +log.noAbbrevTags::
> > + Each value is a glob pattern, specifying tag nammes which
> > + should always be displayed in full, even when other tags may
> > + be omitted or abbreviated (for example, by linkgit:gitk[1]).
> > + Values starting with `^` specify tags which should be
> > + abbreviated. The order is important: the last match, in the
> > + most-local configuration, wins.
> > +
>
> It seems weird that this description implies some sort of behavior
> change in core git itself, but in fact is only used as a reference for
> other tools that may or may not honor it. I guess the reasoning here
> is to try to get other external tools that abbreviate tags to also
> honor this? But it still seems pretty weird to have a documented
> config that has no code in core git to honor it...
Thanks for your attention.
Yes, I agree that it does seem weird. But the alternatives seem
worse. I think it's probably best if options like this (currently
only honoured by out-of-core tools but of general usefulness) are
collected together here.
There is a precedent: `git config gui.encoding' is, according to the
documentation, honoured only by git-gui and gitk.
Calling the config option `gitk.noAbbrevTags' would be possible but
that would invite everyone else to invent their own, which would be
quite annoying. (Also, gitk does not have any gitk-specific git
config options right now, AIUI. It does honour `git config
gui.encoding'.)
Would it help to add a sentence to the documentation saying that this
is currently only honoured by gitk ? (The paragraph for gui.encoding
says something similar.) Of course I don't know who else abbreviates
tags, but as they gain support they could be added to the docs.
Thanks,
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
^ permalink raw reply
* Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate
From: Markus Hitter @ 2016-11-08 9:19 UTC (permalink / raw)
To: Ian Jackson; +Cc: git, Junio C Hamano, Paul Mackerras
In-Reply-To: <22561.8757.914542.10409@chiark.greenend.org.uk>
Am 08.11.2016 um 01:54 schrieb Ian Jackson:
> Please find in the following mails patches which provide a way to make
> gitk display certain tags in full, even if they would normally be
> abbreviated.
TBH, I see a violation of tool independence with the choice of preference storage. Abbreviation of tags isn't a property of the repository, but a pure visual thing (screen real estate, whatever), so it should be handled by the tool doing the visuals, only.
Your use case looks like a nice opportunity for
- adding a Gitk user preference on how long displayed tags are allowed to be (instead of distinguishing between abbreviated and unabbreviated ones; set it to 999 for your use case) and/or
- even better, abbreviate them depending on the size of the visible area, like a web browser would do, and/or
- considering whether tags should be abbreviated on the left instead of on the right and/or
- finding a mechanism to show them in full length even on small visible areas.
The latter could be done by a tooltip appearing when hovering with the mouse over an abbreviated tag or by allowing multiple lines for a single commit in the list of commits.
Trying to enforce long names just means they're not cut off by the abbreviation algorithm, but by the right boundary of the visible area.
My $0.02,
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)
From: Karthik Nayak @ 2016-11-08 9:03 UTC (permalink / raw)
To: Jacob Keller; +Cc: Junio C Hamano, Git mailing list
In-Reply-To: <CA+P7+xo+CJU_ng5OWX1y26+=QPCg6Zxpv_0opTAzsNqeFXAwng@mail.gmail.com>
Helo,
On Tue, Nov 8, 2016 at 1:58 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Nov 8, 2016 12:24 AM, "Karthik Nayak" <karthik.188@gmail.com> wrote:
>> Anything I could do to push this forward? It's been a while now.
>
> Hi,
>
> If this just needs more reviewers I can take a look. Do you possibly have a
> link to the series so I can find it more easily on the mailing list?
>
Since It's been so long I feel it's better I rerolled it, rebasing on
'master'. So I'll
do that soon.
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)
From: Karthik Nayak @ 2016-11-08 8:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <xmqqwpgoqjct.fsf@gitster.mtv.corp.google.com>
Hello,
>
> * kn/ref-filter-branch-list (2016-05-17) 17 commits
> - branch: implement '--format' option
> - branch: use ref-filter printing APIs
> - branch, tag: use porcelain output
> - ref-filter: allow porcelain to translate messages in the output
> - ref-filter: add `:dir` and `:base` options for ref printing atoms
> - ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
> - ref-filter: introduce symref_atom_parser() and refname_atom_parser()
> - ref-filter: introduce refname_atom_parser_internal()
> - ref-filter: make "%(symref)" atom work with the ':short' modifier
> - ref-filter: add support for %(upstream:track,nobracket)
> - ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
> - ref-filter: introduce format_ref_array_item()
> - ref-filter: move get_head_description() from branch.c
> - ref-filter: modify "%(objectname:short)" to take length
> - ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
> - ref-filter: include reference to 'used_atom' within 'atom_value'
> - ref-filter: implement %(if), %(then), and %(else) atoms
>
> The code to list branches in "git branch" has been consolidated
> with the more generic ref-filter API.
>
> Rerolled.
> Needs review.
Anything I could do to push this forward? It's been a while now.
^ permalink raw reply
* Re: 2.11.0-rc1 will not be tagged for a few days
From: Johannes Sixt @ 2016-11-08 6:25 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: git, Johannes Schindelin, Lars Schneider
In-Reply-To: <20161108004038.a7gyoe6wpucxjmvz@sigill.intra.peff.net>
Am 08.11.2016 um 01:40 schrieb Jeff King:
> In addition to J6t's fix in t0021, ...
Just to get things straight: Of my two patches, this one ("uniq -c
variations")
https://public-inbox.org/git/c842e0a7-b032-e0c4-0995-f11d93c17c0a@kdbg.org/
is a bug fix in my environment, and I have a suspicion that it is also
required in other less frequently tested environments (Solaris? BSD
variants?)
The other one, which you most likely remember as dealing with "leading
whitespace in wc -c"
https://public-inbox.org/git/b87ddffd-3de1-4481-b484-9f03a73b6ad1@kdbg.org/
is "only" an optimization. The link points at the final version.
-- Hannes
^ permalink raw reply
* Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors
From: Jeff King @ 2016-11-08 5:33 UTC (permalink / raw)
To: Bryan Turner; +Cc: Git Users, René Scharfe
In-Reply-To: <CAGyf7-FYvUgvOZm0xvFAJx=8hSc4ji=YQ5dUm3B1unU_WOcjeQ@mail.gmail.com>
On Mon, Nov 07, 2016 at 05:12:43PM -0800, Bryan Turner wrote:
> > The obvious solution is one of:
> >
> > 1. Stop calling normalize() at all when we do not have a relative base
> > and the path is not absolute. This restores the original quirky
> > behavior (plus makes the "foo/../../bar" case work).
Actually, I think we want to keep normalizing, as it is possible for
relative paths to normalize correctly (e.g., "foo/../bar"). We just need
to ignore the error, which is easy.
The patch is below, and is the absolute minimum I think we'd need for
v2.11.
Beyond that, we could go further:
a. Actually make a real absolute path based on getcwd(), which would
protect against later chdir() calls, and possibly help with
duplicate suppression. I'm not sure there are actually any
triggerable bugs here, so I went for the minimal fix.
b. Pick a more sane base for the absolute path, like $GIT_DIR. If we
did so, then people using relative paths in
GIT_ALTERNATE_OBJECT_DIRECTORIES from a bare repo would continue to
work, and people in non-bare repositories would have to add an
extra ".." to most of their paths. So a slight regression, but
saner overall semantics.
Making it relative to the object directory ($GIT_DIR/objects, or
even whatever is in $GIT_OBJECT_DIRECTORY) makes even more sense
to me, but would regress even the bare case (and would probably be
"interesting" along with the tmp-objdir stuff, which sets
$GIT_OBJECT_DIRECTORY on the fly, as that would invalidate
$GIT_ALTERNATE_OBJECT_DIRECTORIES).
I'm inclined to leave those to anybody interested post-v2.11 (or never,
if nobody cares). But it would be pretty trivial to do (a) as part of
this initial fix if anybody feels strongly.
> Is there anything I can do to help? I'm happy to test out changes.
The patch at the end of his mail obviously passes the newly-added tests
for me, but please confirm that it fixes your test suite.
I gather your suite is about noticing behavior changes between different
versions. For cases where we know there is an obvious right behavior, it
would be nice if you could contribute them as patches to git's test
suite. This case was overlooked because there was no test coverage at
all.
Barring that, running your suite and giving easily-reproducible problem
reports is valuable. The earlier the better. So I am happy to see this
on -rc0, and not on the final release. Periodically running it on
"master" during the development cycle would have caught it even sooner.
> At the moment I have limited ability to actually try to submit patches
> myself. I really need to sit down and setup a working development
> environment for Git. (My current dream, if I could get such an
> environment running, is to follow up on your git blame-tree work.
I would be happy for somebody to pick that up, too. It has been powering
GitHub's tree-view for several years now, but I know there are some
rough edges as well as opportunities to optimize it.
-- >8 --
Subject: [PATCH] alternates: re-allow relative paths from environment
Commit 670c359da (link_alt_odb_entry: handle normalize_path
errors, 2016-10-03) regressed the handling of relative paths
in the GIT_ALTERNATE_OBJECT_DIRECTORIES variable. It's not
entirely clear this was ever meant to work, but it _has_
worked for several years, so this commit restores the
original behavior.
When we get a path in GIT_ALTERNATE_OBJECT_DIRECTORIES, we
add it the path to the list of alternate object directories
as if it were found in objects/info/alternates, but with one
difference: we do not provide the link_alt_odb_entry()
function with a base for relative paths. That function
doesn't turn it into an absolute path, and we end up feeding
the relative path to the strbuf_normalize_path() function.
Most relative paths break out of the top-level directory
(e.g., "../foo.git/objects"), and thus normalizing fails.
Prior to 670c359da, we simply ignored the error, and due to
the way normalize_path_copy() was implemented it happened to
return the original path in this case. We then accessed the
alternate objects using this relative path.
By storing the relative path in the alt_odb list, the path
is relative to wherever we happen to be at the time we do an
object lookup. That means we look from $GIT_DIR in a bare
repository, and from the top of the worktree in a non-bare
repository.
If this were being designed from scratch, it would make
sense to pick a stable location (probably $GIT_DIR, or even
the object directory) and use that as the relative base,
turning the result into an absolute path. However, given
the history, at this point the minimal fix is to match the
pre-670c359da behavior.
We can do this simply by ignoring the error when we have no
relative base and using the original value (which we now
reliably have, thanks to strbuf_normalize_path()).
That still leaves us with a relative path that foils our
duplicate detection, and may act strangely if we ever
chdir() later in the process. We could solve that by storing
an absolute path based on getcwd(). That may be a good
future direction; for now we'll do just the minimum to fix
the regression.
The new t5615 script demonstrates the fix in its final three
tests. Since we didn't have any tests of the alternates
environment variable at all, it also adds some tests of
absolute paths.
Signed-off-by: Jeff King <peff@peff.net>
---
sha1_file.c | 2 +-
t/t5615-alternate-env.sh | 71 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 1 deletion(-)
create mode 100755 t/t5615-alternate-env.sh
diff --git a/sha1_file.c b/sha1_file.c
index 5457314e6..9c86d1924 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -296,7 +296,7 @@ static int link_alt_odb_entry(const char *entry, const char *relative_base,
}
strbuf_addstr(&pathbuf, entry);
- if (strbuf_normalize_path(&pathbuf) < 0) {
+ if (strbuf_normalize_path(&pathbuf) < 0 && relative_base) {
error("unable to normalize alternate object path: %s",
pathbuf.buf);
strbuf_release(&pathbuf);
diff --git a/t/t5615-alternate-env.sh b/t/t5615-alternate-env.sh
new file mode 100755
index 000000000..22d9d8178
--- /dev/null
+++ b/t/t5615-alternate-env.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+
+test_description='handling of alternates in environment variables'
+. ./test-lib.sh
+
+check_obj () {
+ alt=$1; shift
+ while read obj expect
+ do
+ echo "$obj" >&3 &&
+ echo "$obj $expect" >&4
+ done 3>input 4>expect &&
+ GIT_ALTERNATE_OBJECT_DIRECTORIES=$alt \
+ git "$@" cat-file --batch-check='%(objectname) %(objecttype)' \
+ <input >actual &&
+ test_cmp expect actual
+}
+
+test_expect_success 'create alternate repositories' '
+ git init --bare one.git &&
+ one=$(echo one | git -C one.git hash-object -w --stdin) &&
+ git init --bare two.git &&
+ two=$(echo two | git -C two.git hash-object -w --stdin)
+'
+
+test_expect_success 'objects inaccessible without alternates' '
+ check_obj "" <<-EOF
+ $one missing
+ $two missing
+ EOF
+'
+
+test_expect_success 'access alternate via absolute path' '
+ check_obj "$(pwd)/one.git/objects" <<-EOF
+ $one blob
+ $two missing
+ EOF
+'
+
+test_expect_success 'access multiple alternates' '
+ check_obj "$(pwd)/one.git/objects:$(pwd)/two.git/objects" <<-EOF
+ $one blob
+ $two blob
+ EOF
+'
+
+# bare paths are relative from $GIT_DIR
+test_expect_success 'access alternate via relative path (bare)' '
+ git init --bare bare.git &&
+ check_obj "../one.git/objects" -C bare.git <<-EOF
+ $one blob
+ EOF
+'
+
+# non-bare paths are relative to top of worktree
+test_expect_success 'access alternate via relative path (worktree)' '
+ git init worktree &&
+ check_obj "../one.git/objects" -C worktree <<-EOF
+ $one blob
+ EOF
+'
+
+# path is computed after moving to top-level of worktree
+test_expect_success 'access alternate via relative path (subdir)' '
+ mkdir subdir &&
+ check_obj "one.git/objects" -C subdir <<-EOF
+ $one blob
+ EOF
+'
+
+test_done
--
2.11.0.rc0.263.g6f44bc3
^ permalink raw reply related
* Re: [PATCH v4 1/2] lib-proto-disable: variable name fix
From: Jacob Keller @ 2016-11-08 3:32 UTC (permalink / raw)
To: Jeff King
Cc: Brandon Williams, Git mailing list, Stefan Beller, bburky,
Jonathan Nieder
In-Reply-To: <20161107204838.xm463zdimiw7fx77@sigill.intra.peff.net>
On Mon, Nov 7, 2016 at 12:48 PM, Jeff King <peff@peff.net> wrote:
> It's possible that I'm overly picky about my commit messages, but that
> does not stop me from trying to train an army of picky-commit-message
> clones. :)
>
> -Peff
You're not the only one ;)
Regards,
Jake
^ permalink raw reply
* [PATCH v5 1/2] lib-proto-disable: variable name fix
From: Brandon Williams @ 2016-11-07 21:51 UTC (permalink / raw)
To: git; +Cc: Brandon Williams, sbeller, bburky, peff, jrnieder
In-Reply-To: <1478547323-47332-1-git-send-email-bmwill@google.com>
The test_proto function assigns the positional parameters to named
variables, but then still refers to "$desc" as "$1". Using $desc is
more readable and less error-prone.
Signed-off-by: Brandon Williams <bmwill@google.com>
---
t/lib-proto-disable.sh | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/lib-proto-disable.sh b/t/lib-proto-disable.sh
index b0917d9..be88e9a 100644
--- a/t/lib-proto-disable.sh
+++ b/t/lib-proto-disable.sh
@@ -9,7 +9,7 @@ test_proto () {
proto=$2
url=$3
- test_expect_success "clone $1 (enabled)" '
+ test_expect_success "clone $desc (enabled)" '
rm -rf tmp.git &&
(
GIT_ALLOW_PROTOCOL=$proto &&
@@ -18,7 +18,7 @@ test_proto () {
)
'
- test_expect_success "fetch $1 (enabled)" '
+ test_expect_success "fetch $desc (enabled)" '
(
cd tmp.git &&
GIT_ALLOW_PROTOCOL=$proto &&
@@ -27,7 +27,7 @@ test_proto () {
)
'
- test_expect_success "push $1 (enabled)" '
+ test_expect_success "push $desc (enabled)" '
(
cd tmp.git &&
GIT_ALLOW_PROTOCOL=$proto &&
@@ -36,7 +36,7 @@ test_proto () {
)
'
- test_expect_success "push $1 (disabled)" '
+ test_expect_success "push $desc (disabled)" '
(
cd tmp.git &&
GIT_ALLOW_PROTOCOL=none &&
@@ -45,7 +45,7 @@ test_proto () {
)
'
- test_expect_success "fetch $1 (disabled)" '
+ test_expect_success "fetch $desc (disabled)" '
(
cd tmp.git &&
GIT_ALLOW_PROTOCOL=none &&
@@ -54,7 +54,7 @@ test_proto () {
)
'
- test_expect_success "clone $1 (disabled)" '
+ test_expect_success "clone $desc (disabled)" '
rm -rf tmp.git &&
(
GIT_ALLOW_PROTOCOL=none &&
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate
From: Jacob Keller @ 2016-11-08 2:28 UTC (permalink / raw)
To: Ian Jackson; +Cc: Git mailing list, Junio C Hamano
In-Reply-To: <20161108005241.19888-6-ijackson@chiark.greenend.org.uk>
On Mon, Nov 7, 2016 at 4:52 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> +log.noAbbrevTags::
> + Each value is a glob pattern, specifying tag nammes which
> + should always be displayed in full, even when other tags may
> + be omitted or abbreviated (for example, by linkgit:gitk[1]).
> + Values starting with `^` specify tags which should be
> + abbreviated. The order is important: the last match, in the
> + most-local configuration, wins.
> +
It seems weird that this description implies some sort of behavior
change in core git itself, but in fact is only used as a reference for
other tools that may or may not honor it. I guess the reasoning here
is to try to get other external tools that abbreviate tags to also
honor this? But it still seems pretty weird to have a documented
config that has no code in core git to honor it...
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes
From: Duy Nguyen @ 2016-11-08 1:38 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20161107211522.vzl4zpsu5cpembgc@sigill.intra.peff.net>
On Tue, Nov 8, 2016 at 4:15 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 07, 2016 at 04:10:10PM -0500, Jeff King wrote:
>
>> And I'll admit my main motivation is not that index/filesystem parity,
>> but rather just that:
>>
>> git clone git://host.com/malicious-repo.git
>> git log
>>
>> might create and read symlinks to arbitrary files on the cloner's box.
>> I'm not sure to what degree to be worried about that. It's not like you
>> can't make other arbitrary symlinks which are likely to be read if the
>> user actually starts looking at checked-out files. It's just that we
>> usually try to make a clone+log of a malicious repository safe.
This I can buy.
> Another approach is to have a config option to disallow symlinks to
> destinations outside of the repository tree (I'm not sure if it should
> be on or off by default, though).
Let's err on the safe side and disable symlinks to outside repo by
default (or even all symlinks on .gitattributes and .gitignore as the
first step)
What I learned from my changes in .gitignore is, if we have not
forbidden something, people likely find some creative use for it. As
long as it's can be turned on or off, i guess those minority will stay
happy.
> Again, I don't know that there is a specific security issue, but it
> makes things easier for services which might clone untrusted
> repositories (e.g., things like CI). They'd obviously have to be careful
> with the contents of the repositories anyway, but it's one less thing to
> have to worry about.
>
> -Peff
--
Duy
^ permalink raw reply
* Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors
From: Bryan Turner @ 2016-11-08 1:12 UTC (permalink / raw)
To: Jeff King; +Cc: Git Users, René Scharfe
In-Reply-To: <20161108003034.apydvv3bav3s7ehq@sigill.intra.peff.net>
On Mon, Nov 7, 2016 at 4:30 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 07, 2016 at 03:42:35PM -0800, Bryan Turner wrote:
>
>> > @@ -335,7 +340,9 @@ static void link_alt_odb_entries(const char *alt, int len, int sep,
>> > }
>> >
>> > strbuf_add_absolute_path(&objdirbuf, get_object_directory());
>> > - normalize_path_copy(objdirbuf.buf, objdirbuf.buf);
>> > + if (strbuf_normalize_path(&objdirbuf) < 0)
>> > + die("unable to normalize object directory: %s",
>> > + objdirbuf.buf);
>>
>> This appears to break the ability to use a relative alternate via an
>> environment variable, since normalize_path_copy_len is explicitly
>> documented "Returns failure (non-zero) if a ".." component appears as
>> first path"
>
> That shouldn't happen, though, because the path we are normalizing has
> been converted to an absolute path via strbuf_add_absolute_path. IOW, if
> your relative path is "../../../foo", we should be feeding something
> like "/path/to/repo/.git/objects/../../../foo" and normalizing that to
> "/path/to/foo".
>
> But in your example, you see:
>
> error: unable to normalize alternate object path: ../0/objects
>
> which cannot come from the code above, which calls die(). It should be
> coming from the call in link_alt_odb_entry().
Ah, of course. I should have looked more closely at the call.
<snip>
> No, I had no intention of disallowing relative alternates (and as you
> noticed, a commit from the same series actually expands the use of
> relative alternates). My use has been entirely within info/alternates
> files, though, not via the environment.
>
> As I said, I'm not sure this was ever meant to work, but as far as I can
> tell it mostly _has_ worked, modulo some quirks. So I think we should
> consider it a regression for it to stop working in v2.11.
>
> The obvious solution is one of:
>
> 1. Stop calling normalize() at all when we do not have a relative base
> and the path is not absolute. This restores the original quirky
> behavior (plus makes the "foo/../../bar" case work).
>
> If we want to do the minimum before releasing v2.11, it would be
> that. I'm not sure it leaves things in a very sane state, but at
> least v2.11 does no harm, and anybody who cares can build saner
> semantics for v2.12.
>
> 2. Fix it for real. Pass a real relative_base when linking from the
> environment. The question is: what is the correct relative base? I
> suppose "getcwd() at the time we prepare the alt odb" is
> reasonable, and would behave similarly to older versions ($GIT_DIR
> for bare repos, top of the working tree otherwise).
>
> If we were designing from scratch, I think saner semantics would
> probably be always relative from $GIT_DIR, or even always relative
> from the object directory (i.e., behave as if the paths were given
> in objects/info/alternates). But that breaks compatibility with
> older versions. If we are treating this as a regression, it is not
> very friendly to say "you are still broken, but you might just need
> to add an extra '..' to your path".
>
> So I dunno. I guess that inclines me towards (1), as it lets us punt on
> the harder question.
Is there anything I can do to help? I'm happy to test out changes.
I've got a set of ~1,040 tests that verify all sorts of different Git
behaviors (those tests flagged this change, for example, and found a
regression in git diff-tree in 2.0.2/2.0.3, among other things). I run
them on the "newest" patch release for every feature-bearing line of
Git from 1.8.x up to 2.10 (currently 1.8.0.3, 1.8.1.5, 1.8.2.3,
1.8.3.4, 1.8.4.5, 1.8.5.6, 1.9.5, 2.0.5, 2.1.4, 2.2.3, 2.3.10, 2.4.11,
2.5.5, 2.6.6, 2.7.4, 2.8.4, 2.9.3 and 2.10.2), and I add in RCs of new
as soon as they become available. (I also test Git for Windows; at the
moment I've got 1.8.0, 1.8.1.2, 1.8.3, 1.8.4, 1.8.5.2 and 1.9.5.1 from
msysgit and 2.3.7.1, 2.4.6, 2.5.3, 2.6.4, 2.7.4, 2.8.4, 2.9.3 and
2.10.2 from Git for Windows. 2.11.0-rc0 on Windows passes my test
suite; it looks like it's not tagging the same git/git commit as
v2.11.0-rc0 is.) I wish there was an easy way for me to open this up.
At the moment, it's something I can really only run in-house, as it
were.
At the moment I have limited ability to actually try to submit patches
myself. I really need to sit down and setup a working development
environment for Git. (My current dream, if I could get such an
environment running, is to follow up on your git blame-tree work.
>
> -Peff
^ permalink raw reply
* Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate
From: Ian Jackson @ 2016-11-08 0:54 UTC (permalink / raw)
To: Ian Jackson; +Cc: git, Junio C Hamano, Paul Mackerras
In-Reply-To: <20161108005241.19888-1-ijackson@chiark.greenend.org.uk>
Ian Jackson writes ("[PATCH 0/6] Provide for config to specify tags not to abbreviate"):
> Please find in the following mails patches which provide a way to make
> gitk display certain tags in full, even if they would normally be
> abbreviated.
>
> There are four patches to gitk, three to prepare the ground, and one
> to introduce the new feature.
>
> There is one patch for git, to just document the new config variable.
The eagle-eyed reader will spot that that makes 5 patches, not 6.
There are indeed only 5. The subject mentioning 6 is a mistake -
sorry.
Thanks,
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
^ permalink raw reply
* [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate
From: Ian Jackson @ 2016-11-08 0:52 UTC (permalink / raw)
To: git; +Cc: Ian Jackson, Junio C Hamano
In-Reply-To: <20161108005241.19888-1-ijackson@chiark.greenend.org.uk>
Tags matching a new multi-valued config option log.noAbbrevTags
should not be abbreviated. Currently this config option is
used only by gitk (and the patch to gitk will come via the
gitk maintainer tree).
The config setting is in git config logs.* rather than gitk's
own configuration, because:
- Tools which manage git trees may want to set this, depending
on their knowledge of the nature of the tags likely to be
present;
- Whether this property ought to be set is mostly a property of the
contents of the tag namespaces in the tree, not a user preference.
(Although of course user preferences are supported.)
- Other git utilities (or out of tree utilities) may want to
reference this setting for their own display purposes.
Background motivation:
Debian's dgit archive gateway tool generates and uses tags called
archive/debian/VERSION. If such a tag refers to a Debian source tree,
it is probably very interesting because it refers to a version
actually uploaded to Debian by the Debian package maintainer.
We would therefore like a way to specify that such tags should be
displayed in full. dgit will be able to set an appropriate config
setting in the trees it deals with.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
Documentation/config.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a0ab66a..6aade4f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2002,6 +2002,14 @@ log.abbrevCommit::
linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may
override this option with `--no-abbrev-commit`.
+log.noAbbrevTags::
+ Each value is a glob pattern, specifying tag nammes which
+ should always be displayed in full, even when other tags may
+ be omitted or abbreviated (for example, by linkgit:gitk[1]).
+ Values starting with `^` specify tags which should be
+ abbreviated. The order is important: the last match, in the
+ most-local configuration, wins.
+
log.date::
Set the default date-time mode for the 'log' command.
Setting a value for log.date is similar to using 'git log''s
--
2.10.1
^ permalink raw reply related
* [PATCH GITK 4/6] gitk: Provide for config to specify tags not to abbreviate
From: Ian Jackson @ 2016-11-08 0:52 UTC (permalink / raw)
To: git; +Cc: Ian Jackson, Paul Mackerras
In-Reply-To: <20161108005241.19888-1-ijackson@chiark.greenend.org.uk>
Tags matching a new multi-valued config option log.noAbbrevTags
are not abbreviated.
The config setting is in git config logs.* rather than gitk's
own configuration, because:
- Tools which manage git trees may want to set this, depending
on their knowledge of the nature of the tags likely to be
present;
- Whether this property ought to be set is mostly a property of the
contents of the tag namespaces in the tree, not a user preference.
(Although of course user preferences are supported.)
- Other git utilities (or out of tree utilities) may want to
reference this setting for their own display purposes.
There will be another, separate, patch to the `git' tree to document
this config option.
Background motivation:
Debian's dgit archive gateway tool generates and uses tags called
archive/debian/VERSION. If such a tag refers to a Debian source tree,
it is probably very interesting because it refers to a version
actually uploaded to Debian by the Debian package maintainer.
We would therefore like a way to specify that such tags should be
displayed in full. dgit will be able to set an appropriate config
setting in the trees it deals with.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
gitk | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/gitk b/gitk
index d76f1e3..515d7b0 100755
--- a/gitk
+++ b/gitk
@@ -6547,6 +6547,14 @@ proc totalwidth {l font extra} {
}
proc tag_want_unabbrev {tag} {
+ global noabbrevtags
+ # noabbrevtags was reversed when we read config, so take first match
+ foreach pat $noabbrevtags {
+ set inverted [regsub {^\^} $pat {} pat]
+ if {[string match $pat $tag]} {
+ return [expr {!$inverted}]
+ }
+ }
return 0
}
@@ -12138,6 +12146,11 @@ set tclencoding [tcl_encoding $gitencoding]
if {$tclencoding == {}} {
puts stderr "Warning: encoding $gitencoding is not supported by Tcl/Tk"
}
+set noabbrevtags {}
+catch {
+ set noabbrevtags [exec git config --get-all log.noAbbrevTags]
+}
+set noabbrevtags [lreverse [split $noabbrevtags "\n"]]
set gui_encoding [encoding system]
catch {
--
2.10.1
^ permalink raw reply related
* [PATCH GITK 1/6] gitk: Internal: drawtags: Abolish "singletag" variable
From: Ian Jackson @ 2016-11-08 0:52 UTC (permalink / raw)
To: git; +Cc: Ian Jackson, Paul Mackerras
In-Reply-To: <20161108005241.19888-1-ijackson@chiark.greenend.org.uk>
We are going to want to make the contents of `marks' somewhat more
complicated in a moment, so it won't be possible to use what is
effectively a single variable to represent the status of the whole of
the non-heads part of the marks list.
Luckily the strings that replace actual tag names, in the `singletag'
case, are not themselves valid tag names. So they can be detected
directly.
(Also, `singletag' was not quite right anyway: really it meant that
the tag name(s) had been abbreviated.)
No functional change.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
gitk | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 805a1c7..42fa41a 100755
--- a/gitk
+++ b/gitk
@@ -6570,7 +6570,6 @@ proc drawtags {id x xt y1} {
if {$ntags > $maxtags ||
[totalwidth $marks mainfont $extra] > $maxwidth} {
# show just a single "n tags..." tag
- set singletag 1
if {$ntags == 1} {
set marks [list "tag..."]
} else {
@@ -6620,7 +6619,7 @@ proc drawtags {id x xt y1} {
$xr $yt $xr $yb $xl $yb $x [expr {$yb - $delta}] \
-width 1 -outline $tagoutlinecolor -fill $tagbgcolor \
-tags tag.$id]
- if {$singletag} {
+ if {[regexp {^tag\.\.\.|^\d+ } $tag]} {
set tagclick [list showtags $id 1]
} else {
set tagclick [list showtag $tag_quoted 1]
--
2.10.1
^ permalink raw reply related
* [PATCH GITK 2/6] gitk: Internal: drawtags: Idempotently reset "ntags"
From: Ian Jackson @ 2016-11-08 0:52 UTC (permalink / raw)
To: git; +Cc: Ian Jackson, Paul Mackerras
In-Reply-To: <20161108005241.19888-1-ijackson@chiark.greenend.org.uk>
The previous code tracked its change to the length of `marks' by
updateing the variable `ntags'. This is a bit fragile and cumbersome,
and we are going to want to modify `marks' some more in a moment.
Instead, simply reset ntags to the length of marks, after we have
possibly done any needed abbreviation.
No functional change.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
gitk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 42fa41a..31aecda 100755
--- a/gitk
+++ b/gitk
@@ -6575,9 +6575,10 @@ proc drawtags {id x xt y1} {
} else {
set marks [list [format "%d tags..." $ntags]]
}
- set ntags 1
}
}
+ set ntags [llength $marks]
+
if {[info exists idheads($id)]} {
set marks [concat $marks $idheads($id)]
set nheads [llength $idheads($id)]
--
2.10.1
^ permalink raw reply related
* [PATCH GITK 3/6] gitk: drawtags: Introduce concept of unabbreviated marks
From: Ian Jackson @ 2016-11-08 0:52 UTC (permalink / raw)
To: git; +Cc: Ian Jackson, Paul Mackerras
In-Reply-To: <20161108005241.19888-1-ijackson@chiark.greenend.org.uk>
We are going to want to show some tags in full, even if they are long
or there are other tags. Do this by filtering the tags into
`marks_unabbrev' and `marks'. `marks_unabbrev' bypasses the tag
abbreviation, and is put on the front of the marks array after any
abbreviation has been done.
No functional change right now because no tags are considered
`unabbrev'.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
gitk | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 31aecda..d76f1e3 100755
--- a/gitk
+++ b/gitk
@@ -6546,6 +6546,10 @@ proc totalwidth {l font extra} {
return $tot
}
+proc tag_want_unabbrev {tag} {
+ return 0
+}
+
proc drawtags {id x xt y1} {
global idtags idheads idotherrefs mainhead
global linespc lthickness
@@ -6564,8 +6568,16 @@ proc drawtags {id x xt y1} {
set delta [expr {int(0.5 * ($linespc - $lthickness))}]
set extra [expr {$delta + $lthickness + $linespc}]
+ set marks_unabbrev {}
if {[info exists idtags($id)]} {
- set marks $idtags($id)
+ set marks {}
+ foreach tag $idtags($id) {
+ if {[tag_want_unabbrev $tag]} {
+ lappend marks_unabbrev $tag
+ } else {
+ lappend marks $tag
+ }
+ }
set ntags [llength $marks]
if {$ntags > $maxtags ||
[totalwidth $marks mainfont $extra] > $maxwidth} {
@@ -6577,6 +6589,7 @@ proc drawtags {id x xt y1} {
}
}
}
+ set marks [concat $marks_unabbrev $marks]
set ntags [llength $marks]
if {[info exists idheads($id)]} {
--
2.10.1
^ permalink raw reply related
* [PATCH 0/6] Provide for config to specify tags not to abbreviate
From: Ian Jackson @ 2016-11-08 0:52 UTC (permalink / raw)
To: git; +Cc: Ian Jackson, Junio C Hamano, Paul Mackerras
Hi.
Please find in the following mails patches which provide a way to make
gitk display certain tags in full, even if they would normally be
abbreviated.
There are four patches to gitk, three to prepare the ground, and one
to introduce the new feature.
There is one patch for git, to just document the new config variable.
I hope this is the right way to submit this series. Thanks for your
attention.
As I say in the patch "gitk: Provide for config to specify tags not to
abbreviate":
The config setting is in git config logs.* rather than gitk's
own configuration, because:
- Tools which manage git trees may want to set this, depending
on their knowledge of the nature of the tags likely to be
present;
- Whether this property ought to be set is mostly a property of the
contents of the tag namespaces in the tree, not a user preference.
(Although of course user preferences are supported.)
- Other git utilities (or out of tree utilities) may want to
reference this setting for their own display purposes.
There will be another, separate, patch to the `git' tree to document
this config option.
Background motivation:
Debian's dgit archive gateway tool generates and uses tags called
archive/debian/VERSION. If such a tag refers to a Debian source tree,
it is probably very interesting because it refers to a version
actually uploaded to Debian by the Debian package maintainer.
We would therefore like a way to specify that such tags should be
displayed in full. dgit will be able to set an appropriate config
setting in the trees it deals with.
Ian Jackson (4):
gitk: Internal: drawtags: Abolish "singletag" variable
gitk: Internal: drawtags: Idempotently reset "ntags"
gitk: drawtags: Introduce concept of unabbreviated marks
gitk: Provide for config to specify tags not to abbreviate
gitk | 34 ++++++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)
Ian Jackson (1):
config docs: Provide for config to specify tags not to abbreviate
Documentation/config.txt | 8 ++++++++
1 file changed, 8 insertions(+)
--
2.10.1
^ permalink raw reply
* Re: 2.11.0-rc1 will not be tagged for a few days
From: Jeff King @ 2016-11-08 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Lars Schneider
In-Reply-To: <xmqqk2cgc95m.fsf@gitster.mtv.corp.google.com>
On Sun, Nov 06, 2016 at 06:32:05PM -0800, Junio C Hamano wrote:
> I regret to report that I won't be able to tag 2.11-rc1 as scheduled
> in tinyurl.com/gitCal (I am feverish and my brain is not keeping
> track of things correctly) any time soon. I'll report back an
> updated schedule when able.
Take your time. Even if we end up bumping the release by a whole week, I
don't think it's a big deal (which seems likely given the holiday in the
middle, unless you really want to release on Thanksgiving).
> found on the list. I am aware of only two right now ("cast enum to
> int to work around compiler warning", in Dscho's prepare sequencer
> series, and "wc -l may give leading whitespace" fix J6t pointed out
> in Lars's filter process series), but it is more than likely that I
> am missing a few more.
In addition to J6t's fix in t0021, we need mine that you queued in
jk/filter-process-fix.
I think we also need to make a final decision on the indent/compaction
heuristic naming. After reading Michael's [0], and the claim by you and
Stefan that the "compaction" name was declared sufficiently experimental
that we could later take it away, I'm inclined to follow this plan:
1. Ship v2.11 with what is in master; i.e., both compaction and indent
heuristics, triggerable by config or command line.
2. Post-v2.11, retire the compaction heuristic as a failed experiment.
Keeping it in v2.11 doesn't hurt anything (it was already
released), and lets us take our time coming up with and cooking the
patch.
3. Post-v2.11, flip the default for diff.indentHeuristic to "true".
Keep at least the command line option around indefinitely for
experimenting (i.e., "this diff looks funny; I wonder if
--no-indent-heuristic makes it look better").
Config option can either stay or go at that point. I have no
preference.
The nice thing about that plan is it punts on merging any new code to
post-v2.11. :)
Another possible regression came up today in [1]. I haven't worked up a
patch yet, but I'll do so in the next day or so.
I think that's where we're at now. I'll keep collecting and can give you
the full list when you're back in action.
Get well.
[0] http://public-inbox.org/git/8dbbd28b-af60-5e66-ae27-d7cddca233dc@alum.mit.edu/
[1] http://public-inbox.org/git/20161108003034.apydvv3bav3s7ehq@sigill.intra.peff.net/
^ permalink raw reply
* Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors
From: Jeff King @ 2016-11-08 0:30 UTC (permalink / raw)
To: Bryan Turner; +Cc: Git Users, René Scharfe
In-Reply-To: <CAGyf7-HWAMF8S+Bw3wcwJCS1Subc28KHjpSCc1__0qn-GSMyvA@mail.gmail.com>
On Mon, Nov 07, 2016 at 03:42:35PM -0800, Bryan Turner wrote:
> > @@ -335,7 +340,9 @@ static void link_alt_odb_entries(const char *alt, int len, int sep,
> > }
> >
> > strbuf_add_absolute_path(&objdirbuf, get_object_directory());
> > - normalize_path_copy(objdirbuf.buf, objdirbuf.buf);
> > + if (strbuf_normalize_path(&objdirbuf) < 0)
> > + die("unable to normalize object directory: %s",
> > + objdirbuf.buf);
>
> This appears to break the ability to use a relative alternate via an
> environment variable, since normalize_path_copy_len is explicitly
> documented "Returns failure (non-zero) if a ".." component appears as
> first path"
That shouldn't happen, though, because the path we are normalizing has
been converted to an absolute path via strbuf_add_absolute_path. IOW, if
your relative path is "../../../foo", we should be feeding something
like "/path/to/repo/.git/objects/../../../foo" and normalizing that to
"/path/to/foo".
But in your example, you see:
error: unable to normalize alternate object path: ../0/objects
which cannot come from the code above, which calls die(). It should be
coming from the call in link_alt_odb_entry().
I think what is happening is that relative paths via environment
variables have always been slightly broken, but happened to mostly work.
In prepare_alt_odb(), we call link_alt_odb_entries() with a NULL
relative_base. That function does two things with it:
- it may unconditionally dereference it for an error message, which
would cause a segfault. This is impossible to trigger in practice,
though, because the error message is related to the depth, which we
know will always be 0 here.
- we pass the NULL along to the singular link_alt_odb_entry().
That function only creates an absolute path if given a non-NULL
relative_base; otherwise we have always fed the path to
normalize_path_copy, which is nonsense for a relative path.
So normalize_path_copy() was _always_ returning an error there, but
we ignored it and used whatever happened to be left in the buffer
anyway. And because of the way normalize_path_copy() is implemented,
that happened to be the untouched original string in most cases. But
that's mostly an accident. I think it would not be for something
like "foo/../../bar", which is technically valid (if done from a
relative base that has at least one path component).
Moreover, it means we don't have an absolute path to our alternate
odb. So the path is taken as relative whenever we do an object
lookup, meaning it will behave differently between a bare repository
(where we chdir to $GIT_DIR) and one with a working tree (where we
are generally in the root of the working tree). It can even behave
differently in the same process if we chdir between object lookups.
So it did happen to work, but I'm not sure it was planned (and obviously
we have no test coverage for it). More on that below.
> Other commits, like [1], suggest the ability to use relative paths in
> alternates is something still actively developed and enhanced. Is it
> intentional that this breaks the ability to use relative alternates?
> If this is to be the "new normal", is there any other option when
> using environment variables besides using absolute paths?
No, I had no intention of disallowing relative alternates (and as you
noticed, a commit from the same series actually expands the use of
relative alternates). My use has been entirely within info/alternates
files, though, not via the environment.
As I said, I'm not sure this was ever meant to work, but as far as I can
tell it mostly _has_ worked, modulo some quirks. So I think we should
consider it a regression for it to stop working in v2.11.
The obvious solution is one of:
1. Stop calling normalize() at all when we do not have a relative base
and the path is not absolute. This restores the original quirky
behavior (plus makes the "foo/../../bar" case work).
If we want to do the minimum before releasing v2.11, it would be
that. I'm not sure it leaves things in a very sane state, but at
least v2.11 does no harm, and anybody who cares can build saner
semantics for v2.12.
2. Fix it for real. Pass a real relative_base when linking from the
environment. The question is: what is the correct relative base? I
suppose "getcwd() at the time we prepare the alt odb" is
reasonable, and would behave similarly to older versions ($GIT_DIR
for bare repos, top of the working tree otherwise).
If we were designing from scratch, I think saner semantics would
probably be always relative from $GIT_DIR, or even always relative
from the object directory (i.e., behave as if the paths were given
in objects/info/alternates). But that breaks compatibility with
older versions. If we are treating this as a regression, it is not
very friendly to say "you are still broken, but you might just need
to add an extra '..' to your path".
So I dunno. I guess that inclines me towards (1), as it lets us punt on
the harder question.
-Peff
^ permalink raw reply
* Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors
From: Bryan Turner @ 2016-11-07 23:42 UTC (permalink / raw)
To: Jeff King; +Cc: Git Users, René Scharfe
In-Reply-To: <20161003203417.izcgwt4yz3yspdnm@sigill.intra.peff.net>
On Mon, Oct 3, 2016 at 1:34 PM, Jeff King <peff@peff.net> wrote:
> When we add a new alternate to the list, we try to normalize
> out any redundant "..", etc. However, we do not look at the
> return value of normalize_path_copy(), and will happily
> continue with a path that could not be normalized. Worse,
> the normalizing process is done in-place, so we are left
> with whatever half-finished working state the normalizing
> function was in.
>
<snip>
> @@ -335,7 +340,9 @@ static void link_alt_odb_entries(const char *alt, int len, int sep,
> }
>
> strbuf_add_absolute_path(&objdirbuf, get_object_directory());
> - normalize_path_copy(objdirbuf.buf, objdirbuf.buf);
> + if (strbuf_normalize_path(&objdirbuf) < 0)
> + die("unable to normalize object directory: %s",
> + objdirbuf.buf);
This appears to break the ability to use a relative alternate via an
environment variable, since normalize_path_copy_len is explicitly
documented "Returns failure (non-zero) if a ".." component appears as
first path"
For example, when trying to run a rev-list over commits in two
repositories using GIT_ALTERNATE_OBJECT_DIRECTORIES, in 2.10.x and
prior the following command works. I know the alternate worked
previously because I'm passing a commit that does not exist in the
repository I'm running the command in; it only exists in a repository
linked by alternate, as shown by the "fatal: bad object" when the
alternates are rejected.
Before, using Git 2.7.4 (but I've verified this behavior through to
and including 2.10.2):
bturner@elysoun /tmp/1478561282706-0/shared/data/repositories/3 $
GIT_ALTERNATE_OBJECT_DIRECTORIES=../0/objects:../1/objects git
rev-list --format="%H" 2d8897c9ac29ce42c3442cf80ac977057045e7f6
74de5497dfca9731e455d60552f9a8906e5dc1ac
^6053a1eaa1c009dd11092d09a72f3c41af1b59ad
^017caf31eca7c46eb3d1800fcac431cfa7147a01 --
commit 74de5497dfca9731e455d60552f9a8906e5dc1ac
74de5497dfca9731e455d60552f9a8906e5dc1ac
commit 3528cf690cb37f6adb85b7bd40cc7a6118d4b598
3528cf690cb37f6adb85b7bd40cc7a6118d4b598
commit 2d8897c9ac29ce42c3442cf80ac977057045e7f6
2d8897c9ac29ce42c3442cf80ac977057045e7f6
commit 9c05f43f859375e392d90d23a13717c16d0fdcda
9c05f43f859375e392d90d23a13717c16d0fdcda
Now, using Git 2.11.0-rc0
bturner@elysoun /tmp/1478561282706-0/shared/data/repositories/3 $
GIT_ALTERNATE_OBJECT_DIRECTORIES=../0/objects:../1/objects
/opt/git/2.11.0-rc0/bin/git rev-list --format="%H"
2d8897c9ac29ce42c3442cf80ac977057045e7f6
74de5497dfca9731e455d60552f9a8906e5dc1ac
^6053a1eaa1c009dd11092d09a72f3c41af1b59ad
^017caf31eca7c46eb3d1800fcac431cfa7147a01 --
error: unable to normalize alternate object path: ../0/objects
error: unable to normalize alternate object path: ../1/objects
fatal: bad object 74de5497dfca9731e455d60552f9a8906e5dc1ac
Other commits, like [1], suggest the ability to use relative paths in
alternates is something still actively developed and enhanced. Is it
intentional that this breaks the ability to use relative alternates?
If this is to be the "new normal", is there any other option when
using environment variables besides using absolute paths?
Best regards,
Bryan Turner
[1]: https://github.com/git/git/commit/087b6d584062f5b704356286d6445bcc84d686fb
-- Also newly tagged in 2.11.0-rc0
^ permalink raw reply
* Re: Git issue - ignoring changes to tracked file with assume-unchanged
From: Jakub Narębski @ 2016-11-07 22:34 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Halde, Faiz, git@vger.kernel.org
In-Reply-To: <xmqqy413oysp.fsf@gitster.mtv.corp.google.com>
W dniu 01.11.2016 o 19:11, Junio C Hamano pisze:
> Jeff King <peff@peff.net> writes:
>> On Tue, Nov 01, 2016 at 10:28:57AM +0000, Halde, Faiz wrote:
>>
>>> I frequently use the following command to ignore changes done in a file
>>>
>>> git update-index --assume-unchanged somefile
>>>
>>> Now when I do a pull from my remote branch and say the file 'somefile'
>>> was changed locally and in remote, git will abort the merge saying I
>>> need to commit my changes of 'somefile'.
>>>
>>> But isn't the whole point of the above command to ignore the changes
>>> within the file?
>>
>> No. The purpose of --assume-unchanged is to promise git that you will
>> not change the file, so that it may skip checking the file contents in
>> some cases as an optimization.
>
> That's correct.
>
> The next anticipated question is "then how would I tell Git to
> ignore changes done to a file locally by me?", whose short answer is
> "You don't", of course.
Well, you can always use --skip-worktree. It is a better fit than using
--assume-unchanged, because at least you wouldn't loose your precious
local changes (which happened to me).
OTOH it doesn't solve your issue of --skip-worktree / --assume-unchanged
blocking operation (pull in your case, stash is what I noticed problem
with when using --skip-worktree).
But --skip-worktree is still workaround...
--
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