* Re: [PATCH] git-gui: update Japanese translation
From: Shawn O. Pearce @ 2008-11-26 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vy6z6cfgp.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Feel free to squash this in; I just removed the extra "\n" at the
> beginning of these messages.
Thanks.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: update Japanese translation
From: Nanako Shiraishi @ 2008-11-26 22:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vskpedumw.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> $ make V=1
>> msgfmt --statistics --tcl -l ja -d po/ po/ja.po
>> po/ja.po:1558: `msgid' and `msgstr' entries do not both begin with '\n'
>> po/ja.po:1567: `msgid' and `msgstr' entries do not both begin with '\n'
>> po/ja.po:1602: `msgid' and `msgstr' entries do not both begin with '\n'
>> po/ja.po:1883: `msgid' and `msgstr' entries do not both begin with '\n'
>> po/ja.po:1931: `msgid' and `msgstr' entries do not both begin with '\n'
>> po/ja.po:1941: `msgid' and `msgstr' entries do not both begin with '\n'
>> po/ja.po:2342: `msgid' and `msgstr' entries do not both begin with '\n'
>> po/ja.po:2455: `msgid' and `msgstr' entries do not both begin with '\n'
>> msgfmt: found 8 fatal errors
>> make: *** [po/ja.msg] Error 1
>
> Feel free to squash this in; I just removed the extra "\n" at the
> beginning of these messages.
Thank you for catching and fixing my mistakes.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] git-gui: update Japanese translation
From: Junio C Hamano @ 2008-11-26 22:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vskpedumw.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 96 bytes --]
Feel free to squash this in; I just removed the extra "\n" at the
beginning of these messages.
[-- Attachment #2: po/ja.po fixup --]
[-- Type: application/octet-stream, Size: 1412 bytes --]
po/ja.po | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git c/po/ja.po i/po/ja.po
index 0cd6740..8ba6417 100644
--- c/po/ja.po
+++ i/po/ja.po
@@ -1559,7 +1559,6 @@ msgid ""
"LOCAL: deleted\n"
"REMOTE:\n"
msgstr ""
-"\n"
"LOCAL: 削除\n"
"Remote:\n"
@@ -1568,7 +1567,6 @@ msgid ""
"REMOTE: deleted\n"
"LOCAL:\n"
msgstr ""
-"\n"
"REMOTE: 削除\n"
"LOCAL:\n"
@@ -1603,7 +1601,6 @@ msgid ""
"* Untracked file is %d bytes.\n"
"* Showing only first %d bytes.\n"
msgstr ""
-"\n"
"* 管理外のファイルの大きさは %d バイトです。\n"
"* 最初の %d バイトだけ表示しています。\n"
@@ -1887,7 +1884,6 @@ msgid ""
"\n"
"This operation can be undone only by restarting the merge."
msgstr ""
-"\n"
"競合する変更点だけが表示されていることに注意してください。\n"
"\n"
"%s は上書きされます。\n"
@@ -1932,7 +1928,6 @@ msgid ""
"Error retrieving versions:\n"
"%s"
msgstr ""
-"\n"
"版の取り出し時にエラーが出ました:\n"
"%s"
@@ -1943,7 +1938,6 @@ msgid ""
"\n"
"%s"
msgstr ""
-"\n"
"マージツールが起動できません:\n"
"\n"
"%s"
@@ -2344,7 +2338,6 @@ msgid ""
"\n"
"%s"
msgstr ""
-"\n"
"ssh-keygen を起動できません:\n"
"\n"
"%s"
@@ -2456,7 +2449,6 @@ msgid ""
"Could not add tool:\n"
"%s"
msgstr ""
-"\n"
"ツールを追加できません:\n"
"%s"
^ permalink raw reply related
* Re: [PATCH] git-gui: update Japanese translation
From: Junio C Hamano @ 2008-11-26 21:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vskpedumw.fsf@gitster.siamese.dyndns.org>
Gahh. Forget the one I just sent out. message-mode attachment handling
ate my encoding.
^ permalink raw reply
* Re: [PATCH 2/2] In add --patch, Handle K,k,J,j slightly more gracefully.
From: Junio C Hamano @ 2008-11-26 21:55 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <492DB6CE.3010409@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> Instead of printing the help menu, this will print
> "No next hunk" and then process the given hunk again.
> ---
Missing sign-off.
> - elsif ($other =~ /K/ && $line =~ /^K/) {
> - $ix--;
> + elsif ( $line =~ /^K/) {
> + $other =~ /K/ ? $ix-- : print STDERR "No previous hunk\n";
This may be cute but I think it is harder to read than necessary.
if ($other =~ /K/) {
$ix--;
} else {
print STDERR "No previous hunk\n";
}
> + elsif ($line =~ /^k/) {
> + if ($other =~ /k/) {
> + while (1) {
> + $ix--;
> + last if (!$ix ||
> + !defined $hunk[$ix]{USE});
> + }
> + next;
> + }
> + else {
> + print STDERR "No previous hunk\n";
> }
> - next;
> }
> + elsif ($line =~ /^j/) {
> + if ($other !~ /j/) {
> + print STDERR "No next hunk\n";
> + next;
> }
> }
Doesn't this behave differently against an unavailable 'k' and 'j'? When
the user says 'j' when no next hunk is available, it will ask again about
that hunk, but when the user says 'k' at the first hunk, because you
discarded 'next', it will ask about the next hunk, no? Shouldn't it ask
again about the same hunk, against which the user gave an erroneous input?
^ permalink raw reply
* Re: [PATCH 1/2] Add / command in add --patch (feature request)
From: Junio C Hamano @ 2008-11-26 21:55 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <492DB6C8.7010205@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index b0223c3..7ad4ee0 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -876,12 +876,14 @@ sub patch_update_file {
>
> $num = scalar @hunk;
> $ix = 0;
> + my $search_s; # User entered string to match a hunk.
>
> while (1) {
> my ($prev, $next, $other, $undecided, $i);
> $other = '';
>
> if ($num <= $ix) {
> + $search_s = 0;
People cannot look for string "0"?
Instead, set this to 'undef' and check with:
if (defined $search_string) {
...
in the later part of the code.
> @@ -916,11 +918,24 @@ sub patch_update_file {
> $other .= '/s';
> }
> $other .= '/e';
> - for (@{$hunk[$ix]{DISPLAY}}) {
> - print;
> +
> + my $line;
> + if( $search_s ) {
> + my $text = join( "", @{$hunk[$ix]{DISPLAY}} );
> + if( $text !~ $search_s ) {
Style.
(1) SP between language construct and open parenthesis, as opposed to
no extra SP between function name and open parenthesis;
(2) No extra SP around what is enclosed in parentheses.
No help text added to help people discover this new feature?
The interactive help prompt is hard to read because '/' is used to
separate choices. I'd suggest to make this into two patches:
Patch 1/2 would change use of '/' to ',' so that this:
Stage this hunk [y/n/a/d/j/J/e/?]?
becomes
Stage this hunk [y,n,a,d,j,J,e,?]?
Patch 2/2 would be a fix-up of the patch you sent.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-gui: update Japanese translation
From: Junio C Hamano @ 2008-11-26 21:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nanako Shiraishi, git
In-Reply-To: <20081126212828.GA20382@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
"Shawn O. Pearce" <spearce@spearce.org> writes:
> $ make V=1
> msgfmt --statistics --tcl -l ja -d po/ po/ja.po
> po/ja.po:1558: `msgid' and `msgstr' entries do not both begin with '\n'
> po/ja.po:1567: `msgid' and `msgstr' entries do not both begin with '\n'
> po/ja.po:1602: `msgid' and `msgstr' entries do not both begin with '\n'
> po/ja.po:1883: `msgid' and `msgstr' entries do not both begin with '\n'
> po/ja.po:1931: `msgid' and `msgstr' entries do not both begin with '\n'
> po/ja.po:1941: `msgid' and `msgstr' entries do not both begin with '\n'
> po/ja.po:2342: `msgid' and `msgstr' entries do not both begin with '\n'
> po/ja.po:2455: `msgid' and `msgstr' entries do not both begin with '\n'
> msgfmt: found 8 fatal errors
> make: *** [po/ja.msg] Error 1
Feel free to squash this in; I just removed the extra "\n" at the
beginning of these messages.
[-- Attachment #2: po/ja.po fixup --]
[-- Type: text/plain, Size: 1358 bytes --]
po/ja.po | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git c/po/ja.po i/po/ja.po
index 0cd6740..8ba6417 100644
--- c/po/ja.po
+++ i/po/ja.po
@@ -1559,7 +1559,6 @@ msgid ""
"LOCAL: deleted\n"
"REMOTE:\n"
msgstr ""
-"\n"
"LOCAL: 削除\n"
"Remote:\n"
@@ -1568,7 +1567,6 @@ msgid ""
"REMOTE: deleted\n"
"LOCAL:\n"
msgstr ""
-"\n"
"REMOTE: 削除\n"
"LOCAL:\n"
@@ -1603,7 +1601,6 @@ msgid ""
"* Untracked file is %d bytes.\n"
"* Showing only first %d bytes.\n"
msgstr ""
-"\n"
"* 管理外のファイルの大きさは %d バイトです。\n"
"* 最初の %d バイトだけ表示しています。\n"
@@ -1887,7 +1884,6 @@ msgid ""
"\n"
"This operation can be undone only by restarting the merge."
msgstr ""
-"\n"
"競合する変更点だけが表示されていることに注意してください。\n"
"\n"
"%s は上書きされます。\n"
@@ -1932,7 +1928,6 @@ msgid ""
"Error retrieving versions:\n"
"%s"
msgstr ""
-"\n"
"版の取り出し時にエラーが出ました:\n"
"%s"
@@ -1943,7 +1938,6 @@ msgid ""
"\n"
"%s"
msgstr ""
-"\n"
"マージツールが起動できません:\n"
"\n"
"%s"
@@ -2344,7 +2338,6 @@ msgid ""
"\n"
"%s"
msgstr ""
-"\n"
"ssh-keygen を起動できません:\n"
"\n"
"%s"
@@ -2456,7 +2449,6 @@ msgid ""
"Could not add tool:\n"
"%s"
msgstr ""
-"\n"
"ツールを追加できません:\n"
"%s"
^ permalink raw reply related
* Re: [PATCH] git-gui: update Japanese translation
From: Alexander Gavrilov @ 2008-11-26 21:27 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Shawn O. Pearce, git
In-Reply-To: <20081126192144.6117@nanako3.lavabit.com>
On Wednesday 26 November 2008 13:21:44 Nanako Shiraishi wrote:
> -#: lib/blame.tcl:388
> +#: lib/blame.tcl:288
> +msgid "Show History Context"
> +msgstr "文脈を見せる"
> -#: lib/option.tcl:128
> +#: lib/option.tcl:151
> +msgid "Blame History Context Radius (days)"
> +msgstr "註釈する履歴半径（日数）"
I obviosly should have chosen a less ambiguous name for this
option. Everybody seems to think that the key item here is Blame,
while actually it is "History Context", i.e. the option specifies the
Radius of the History Context that is shown by the corresponding
menu item in the Blame viewer. It was probably better to name it
simply "History Context Radius".
This menu item starts gitk, auto-selecting the commit that the clicked
line of the blame viewer is annotated with, and restricting view to
commits that are within the specified time radius of it. The feature is mainly
intended to aid analysis of repositories with poorly structured history,
where related changes are often scattered into multiple nearby commits.
It can easily happen as a consequence of importing history from
a file-centered VCS, like CVS or Visual SourceSafe. That's why no
limiting on file path is done.
Of course, it is also a handy way to view the commit diff...
Alexander
^ permalink raw reply
* Re: [PATCH] git-gui: update Japanese translation
From: Shawn O. Pearce @ 2008-11-26 21:28 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20081126192144.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> ---
> po/ja.po | 1127 ++++++++++++++++++++++++++++++++++++++++++++++----------------
> 1 files changed, 833 insertions(+), 294 deletions(-)
Hmm.
$ make V=1
msgfmt --statistics --tcl -l ja -d po/ po/ja.po
po/ja.po:1558: `msgid' and `msgstr' entries do not both begin with '\n'
po/ja.po:1567: `msgid' and `msgstr' entries do not both begin with '\n'
po/ja.po:1602: `msgid' and `msgstr' entries do not both begin with '\n'
po/ja.po:1883: `msgid' and `msgstr' entries do not both begin with '\n'
po/ja.po:1931: `msgid' and `msgstr' entries do not both begin with '\n'
po/ja.po:1941: `msgid' and `msgstr' entries do not both begin with '\n'
po/ja.po:2342: `msgid' and `msgstr' entries do not both begin with '\n'
po/ja.po:2455: `msgid' and `msgstr' entries do not both begin with '\n'
msgfmt: found 8 fatal errors
make: *** [po/ja.msg] Error 1
Can you fix up the .po and resend?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] tg export: implement skipping empty patches for quilt mode
From: Uwe Kleine-König @ 2008-11-26 21:19 UTC (permalink / raw)
To: martin f krafft; +Cc: Uwe Kleine-König, git
In-Reply-To: <20081126203959.GB31563@piper.oerlikon.madduck.net>
Hi,
On Wed, Nov 26, 2008 at 09:39:59PM +0100, martin f krafft wrote:
> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2008.11.26.1313 +0100]:
> > addionally fix the README item for skipping the export of empty patches
> > not to need an option (-n) as this should be the default.
> [...]
> > - TODO: -n option to prevent exporting of empty patches
> > + TODO: prevent exporting of empty patches
>
> Is it still a TODO? Looks like your patch fixes it, no?
No, it's still a TODO for the collapse driver.
Best regards
Uwe
^ permalink raw reply
* [PATCH] tg-export: add flag -n to get numbered patches
From: Uwe Kleine-König @ 2008-11-26 21:17 UTC (permalink / raw)
To: git; +Cc: martin f. krafft, Petr Baudis
This eases sending the patches out in the right order using git
send-email. Of course this only works nicely if all patches end in the
same directory (e.g. all dependant patches use the same prefix)
Note this patch depends a bit on my previous one that deprecates using
-n for not exporting empty patches.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: martin f. krafft <madduck@debian.org>
Cc: Petr Baudis <pasky@suse.cz>
---
tg-export.sh | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/tg-export.sh b/tg-export.sh
index f133fb8..b667b82 100644
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -7,6 +7,7 @@ name=
branches=
output=
driver=collapse
+numbered=false
## Parse options
@@ -20,6 +21,8 @@ while [ -n "$1" ]; do
driver=quilt;;
--collapse)
driver=collapse;;
+ -n)
+ numbered=true;;
-*)
echo "Usage: tg [...] export ([--collapse] NEWBRANCH | [-b BRANCH1,BRANCH2...] --quilt DIRECTORY)" >&2
exit 1;;
@@ -34,6 +37,9 @@ done
[ -z "$branches" -o "$driver" = "quilt" ] ||
die "-b works only with the quilt driver"
+[ "$driver" = "quilt" ] || ! "$numbered" ||
+ die "-n works only with the quilt driver"
+
if [ -z "$branches" ]; then
# this check is only needed when no branches have been passed
name="$(git symbolic-ref HEAD | sed 's#^refs/heads/##')"
@@ -134,19 +140,31 @@ quilt()
return
fi
- filename="$output/$_dep.diff"
- if [ -e "$filename" ]; then
+ if "$numbered"; then
+ number=$(printf "%04u" $((number + 1)))
+ bn="$(basename "$_dep.diff")";
+ dn="$(dirname "$_dep.diff")";
+ num_dep="$dn/$number-$bn"
+ else
+ num_dep="$_dep.diff";
+ fi
+ filename="$output/$num_dep"
+
+ if [ -e "$playground/$_dep" ]; then
# We've already seen this dep
return
fi
+ mkdir -p "$playground/$(dirname "$_dep")"
+ touch "$playground/$_dep"
+
if branch_empty "$_dep"; then
echo "Skip empty patch $_dep";
else
echo "Exporting $_dep"
mkdir -p "$(dirname "$filename")"
$tg patch "$_dep" >"$filename"
- echo "$_dep.diff -p1" >>"$output/series"
+ echo "$num_dep.diff -p1" >>"$output/series"
fi
}
@@ -166,6 +184,8 @@ elif [ "$driver" = "quilt" ]; then
die "target directory already exists: $output"
mkdir -p "$output"
+
+ number="0000";
fi
--
1.5.6.5
^ permalink raw reply related
* Re: git configure script
From: Matthieu Moy @ 2008-11-26 20:53 UTC (permalink / raw)
To: Neale T. Pickett; +Cc: git
In-Reply-To: <njx4p1ub7zz.fsf@cfl-sunray1.lanl.gov>
neale@lanl.gov (Neale T. Pickett) writes:
> But it installed everything in $HOME/bin and $HOME/libexec. Looking
> into it, it seems the shipped Makefile doesn't look to see what --prefix
> is, despite the configure script claiming that "make install" would
> honor this.
It does, since it includes config.mak.autogen which overrides prefix
defined in Makefile.
I'm 99% sure you did something wrong. You should investigate by
looking into config.mak.autogen after running configure.
--
Matthieu
^ permalink raw reply
* [PATCH 2/2] In add --patch, Handle K,k,J,j slightly more gracefully.
From: William Pursell @ 2008-11-26 20:51 UTC (permalink / raw)
To: git
Instead of printing the help menu, this will print
"No next hunk" and then process the given hunk again.
---
git-add--interactive.perl | 35 +++++++++++++++++++----------------
1 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 7ad4ee0..6321bd9 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -964,29 +964,32 @@ sub patch_update_file {
elsif ($line =~ m|^/(.*)|) {
$search_s = $1;
}
- elsif ($other =~ /K/ && $line =~ /^K/) {
- $ix--;
+ elsif ( $line =~ /^K/) {
+ $other =~ /K/ ? $ix-- : print STDERR "No previous hunk\n";
next;
}
- elsif ($other =~ /J/ && $line =~ /^J/) {
- $ix++;
+ elsif ($line =~ /^J/) {
+ $other =~ /J/ ? $ix++ : print STDERR "No next hunk\n";
next;
}
- elsif ($other =~ /k/ && $line =~ /^k/) {
- while (1) {
- $ix--;
- last if (!$ix ||
- !defined $hunk[$ix]{USE});
+ elsif ($line =~ /^k/) {
+ if ($other =~ /k/) {
+ while (1) {
+ $ix--;
+ last if (!$ix ||
+ !defined $hunk[$ix]{USE});
+ }
+ next;
+ }
+ else {
+ print STDERR "No previous hunk\n";
}
- next;
}
- elsif ($other =~ /j/ && $line =~ /^j/) {
- while (1) {
- $ix++;
- last if ($ix >= $num ||
- !defined $hunk[$ix]{USE});
+ elsif ($line =~ /^j/) {
+ if ($other !~ /j/) {
+ print STDERR "No next hunk\n";
+ next;
}
- next;
}
elsif ($other =~ /s/ && $line =~ /^s/) {
my @split = split_hunk($hunk[$ix]{TEXT}, $hunk[$ix]{DISPLAY});
--
1.6.0.4.781.gf2070.dirty
--
William Pursell
^ permalink raw reply related
* [PATCH 1/2] Add / command in add --patch (feature request)
From: William Pursell @ 2008-11-26 20:51 UTC (permalink / raw)
To: git
This sequence of 2 patches adds a '/' command to
add --patch that allows the user to search for
a hunk that matches a regex, and deals with j,k slightly
more gracefully. (Rather than printing the
help menu if k is invalid, it will print
a relevant error message.)
This is naive, and it is easy for an invalid
search string to cause a perl error.
I think it could be useful functionality to make
robust.
(Please CC me in any response)
---
git-add--interactive.perl | 26 ++++++++++++++++++++++----
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..7ad4ee0 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -876,12 +876,14 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ my $search_s; # User entered string to match a hunk.
while (1) {
my ($prev, $next, $other, $undecided, $i);
$other = '';
if ($num <= $ix) {
+ $search_s = 0;
$ix = 0;
}
for ($i = 0; $i < $ix; $i++) {
@@ -916,11 +918,24 @@ sub patch_update_file {
$other .= '/s';
}
$other .= '/e';
- for (@{$hunk[$ix]{DISPLAY}}) {
- print;
+
+ my $line;
+ if( $search_s ) {
+ my $text = join( "", @{$hunk[$ix]{DISPLAY}} );
+ if( $text !~ $search_s ) {
+ $line = "n\n";
+ } else {
+ print $text;
+ }
+ } else {
+ for (@{$hunk[$ix]{DISPLAY}}) {
+ print;
+ }
+ }
+ if (!$line) {
+ print colored $prompt_color, "Stage this hunk [y/n/a/d///$other/?]? ";
+ $line = <STDIN>;
}
- print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
- my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
@@ -946,6 +961,9 @@ sub patch_update_file {
}
next;
}
+ elsif ($line =~ m|^/(.*)|) {
+ $search_s = $1;
+ }
elsif ($other =~ /K/ && $line =~ /^K/) {
$ix--;
next;
--
1.6.0.4.781.gf2070.dirty
--
William Pursell
^ permalink raw reply related
* Re: [PATCH] tg export: implement skipping empty patches for quilt mode
From: martin f krafft @ 2008-11-26 20:39 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <1227701580-9762-1-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2008.11.26.1313 +0100]:
> addionally fix the README item for skipping the export of empty patches
> not to need an option (-n) as this should be the default.
[...]
> - TODO: -n option to prevent exporting of empty patches
> + TODO: prevent exporting of empty patches
Is it still a TODO? Looks like your patch fixes it, no?
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"the difference between genius and stupidity
is that genius has it's limits."
-- albert einstein
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-p4: fix keyword-expansion regex
From: Junio C Hamano @ 2008-11-26 20:33 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20081126185215.GA11037@osc.edu>
I will queue this to 'pu' and wait for an Ack from git-p4 folks. Thanks.
^ permalink raw reply
* git configure script
From: Neale T. Pickett @ 2008-11-26 19:30 UTC (permalink / raw)
To: git
I downloaded 1.6.0.4 from
http://kernel.org/pub/software/scm/git/git-1.6.0.4.tar.gz
and ran
./configure --prefix=$HOME/opt
But it installed everything in $HOME/bin and $HOME/libexec. Looking
into it, it seems the shipped Makefile doesn't look to see what --prefix
is, despite the configure script claiming that "make install" would
honor this.
I'm guessing it should have shipped with a Makefile.in or something, but
honestly Autoconf confuses the dickens out of me.
Neale
^ permalink raw reply
* Re: [PATCH] git checkout: don't warn about unborn branch if -f is already passed
From: Junio C Hamano @ 2008-11-26 19:46 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1227509722.32583.0.camel@mattlaptop2.local>
Matt McCutchen <matt@mattmccutchen.net> writes:
> I think it's unnecessary to warn that the checkout has been forced due to an
> unborn current branch if -f has been explicitly passed. For one project, I am
> using git-new-workdir to create workdirs from a bare repository whose HEAD is
> set to an unborn branch, and this warning started to irritate me.
I doubt anybody minds this particular change per-se, but I wonder what the
justification of keeping a dangling HEAD in a bare repository is.
After all, the primary intended purpose of a bare repository is to serve
as a distribution point (i.e. something you can clone from), and I think a
dangling HEAD interferes with the usual operation of clone (although I've
never tested this).
Care to explain why?
^ permalink raw reply
* Re: [PATCH] send-email: Fix Pine address book parsing
From: Junio C Hamano @ 2008-11-26 19:46 UTC (permalink / raw)
To: Trent Piepho; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0811260243440.5161@t2.domain.actdsltmp>
Trent Piepho <tpiepho@freescale.com> writes:
> ... There isn't any code that just does line wrapping.
> The code that prints out a address book entry will at various points check
> if it should output a newline. And it whatever it prints after those
> points isn't allowed to start with space. The code that reads the entries
> eats all the spaces before and after each field. If long comments are
> wrapped, it will change "a b" into "a\n : b\n" and effectively does
> s/^ +: / /; when reading it back. But email address don't get wrapped
> that way so we don't need to care about the ':'.
I never was worried about eating and losing the leading space that was
used only to signal the continuation line, but was wondering if we need to
insert an artificial space in place of the newline we are eating, but it
appears that we can say with confidence that worry is unfounded.
Will queue. Thanks.
^ permalink raw reply
* Re: git cat-file blob does not convert crlf
From: Junio C Hamano @ 2008-11-26 19:42 UTC (permalink / raw)
To: Quim K. Holland; +Cc: git
In-Reply-To: <20081127013456.6117@qkholland.gmail.com>
"Quim K. Holland" <qkholland@gmail.com> writes:
> I think git is buggy.
Thanks for pointing it out X-<.
> I wanted to discard the changes I made to my file by checking out a copy from the last commit, so I said
> % git cat-file blob HEAD:my-file >my-file
> But this does not respect core.autocrlf and the file becomes one long line.
That is pretty much intentional. cat-file is a low-level command that is
meant to inspect the raw object contents. The output from the command has
to be reproducible regardless of what customization you have in your
particular repository and omission of attributes support (including the
crlf conversion) is quite deliberate.
You said that you wanted to discard the changes by checking out a copy out
of the HEAD commit. This can literally be done by:
$ git checkout HEAD my-file
If you want to check out a copy out of the index (i.e, "the last staged
version"), you can say:
$ git checkout my-file
In other words, if you want to checkout, you can say checkout ;-)
^ permalink raw reply
* git cat-file blob does not convert crlf
From: Quim K. Holland @ 2008-11-26 19:34 UTC (permalink / raw)
To: git
I think git is buggy.
I wanted to discard the changes I made to my file by checking out a copy from the last commit, so I said
% git cat-file blob HEAD:my-file >my-file
But this does not respect core.autocrlf and the file becomes one long line.
Also it feels stupid that I have to say my-file twice at the command prompt.
^ permalink raw reply
* [PATCH] git-p4: fix keyword-expansion regex
From: Pete Wyckoff @ 2008-11-26 18:52 UTC (permalink / raw)
To: git
This text:
my $dir = $File::Find::dir;
return if ($dir !~ m,$options->{dirpat}$,);
was improperly converted to:
my $dir = $File$dir !~ m,$options->{dirpat}$,);
by the keyword identifier expansion code. Add a \n
to make sure the regex doesn't go across end-of-line
boundaries.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 9b04ca5..09317af 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1005,7 +1005,7 @@ class P4Sync(Command):
if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
- text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
+ text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$\n]*\$',r'$\1$', text)
contents[stat['depotFile']] = text
--
1.5.6.5
^ permalink raw reply related
* Re: format-patch problem when using relative
From: Nikola Knežević @ 2008-11-26 18:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081126180154.GA7584@coredump.intra.peff.net>
On 26 Nov 2008, at 19:01 , Jeff King wrote:
> So I think what you really want is:
>
> git format-patch --relative=click click/master myclick -- click
>
> to limit the path pruning to the 'click' directory.
Yes, that did the trick. Also, when I think about it, it makes sense -
do checks relative to a path, but prune using path.
Thanks,
Nikola
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Alex Riesen @ 2008-11-26 18:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811260931030.14328@xanadu.home>
Nicolas Pitre, Wed, Nov 26, 2008 15:33:51 +0100:
> On Wed, 26 Nov 2008, Alex Riesen wrote:
> > 2008/11/19 Nicolas Pitre <nico@cam.org>:
> > > I'm looking at it now. I'm therefore revoking my earlier ACK as well
> > > (better keep that test case alive).
> > >
> >
> > Any news here?
>
> Yes: my hard disk crashed a couple hours after I mentioned this, so most
> of my time has been spent on recovery since then. I'll come back to it
> eventually.
Heh... Good luck!
^ permalink raw reply
* Re: [PATCH] sha1_file: avoid bogus "file exists" error message
From: Joey Hess @ 2008-11-26 18:19 UTC (permalink / raw)
To: Git List
In-Reply-To: <20081120185628.GA25604@kodama.kitenet.net>
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
Joey Hess wrote:
> Note that in both occasions that I've seen this failure, it has not been
> due to a missing directory, or bad permissions
Actually, it was due to bad permissions. :-) Once git was fixed to
actually say that, I figured out where to look to fix them.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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