* What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-11-27 0:28 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* cr/remote-update-v (Tue Nov 18 19:04:02 2008 +0800) 1 commit
+ git-remote: add verbose mode to git remote update
Should be in 1.6.1-rc1.
* rs/strbuf-expand (Sun Nov 23 00:16:59 2008 +0100) 6 commits
+ remove the unused files interpolate.c and interpolate.h
+ daemon: deglobalize variable 'directory'
+ daemon: inline fill_in_extra_table_entries()
+ daemon: use strbuf_expand() instead of interpolate()
+ merge-recursive: use strbuf_expand() instead of interpolate()
+ add strbuf_expand_dict_cb(), a helper for simple cases
Should be in 1.6.1-rc1.
* mv/fast-export (Sun Nov 23 12:55:54 2008 +0100) 2 commits
+ fast-export: use an unsorted string list for extra_refs
+ Add new testcase to show fast-export does not always exports all
tags
Should be in 1.6.1-rc1 and backmerged to 'maint'.
* st/levenshtein (Thu Nov 20 14:27:27 2008 +0100) 2 commits
+ Document levenshtein.c
+ Fix deletion of last character in levenshtein distance
Should be in 1.6.1-rc1.
* js/mingw-rename-fix (Wed Nov 19 17:25:27 2008 +0100) 1 commit
+ compat/mingw.c: Teach mingw_rename() to replace read-only files
Should be in 1.6.1-rc1 and backmerged to 'maint'.
* mv/clone-strbuf (Fri Nov 21 01:45:01 2008 +0100) 3 commits
+ builtin_clone: use strbuf in cmd_clone()
+ builtin-clone: use strbuf in clone_local() and
copy_or_link_directory()
+ builtin-clone: use strbuf in guess_dir_name()
Should be in 1.6.1-rc1.
* pw/maint-p4 (Wed Nov 26 13:52:15 2008 -0500) 1 commit
- git-p4: fix keyword-expansion regex
Waiting for Ack from git-p4 folks.
* cc/bisect-skip (Sun Nov 23 22:02:49 2008 +0100) 1 commit
- bisect: teach "skip" to accept special arguments like "A..B"
Should be in 1.6.1-rc1.
* cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
- bisect: add "--no-replace" option to bisect without using replace
refs
- rev-list: make it possible to disable replacing using "--no-
bisect-replace"
- bisect: use "--bisect-replace" options when checking merge bases
- merge-base: add "--bisect-replace" option to use fixed up revs
- commit: add "bisect_replace_all" prototype to "commit.h"
- rev-list: add "--bisect-replace" to list revisions with fixed up
history
- Documentation: add "git bisect replace" documentation
- bisect: add test cases for "git bisect replace"
- bisect: add "git bisect replace" subcommand
I really hate the idea of introducing a potentially much more useful
replacement of the existing graft mechanism and tie it very tightly to
bisect, making it unusable from outside.
(1) I do not think "bisect replace" workflow is a practical and usable
one;
(2) The underlying mechanism to express "this object replaces that other
object" is much easier to work with than what the graft does which is
"the parents of this commit are these", and idea to use the normal
ref to point at them means this can potentially be used for
transferring the graft information across repositories, which the
current graft mechanism cannot do.
(3) Because I like the aspect (2) of this series so much, it deeply
disappoints and troubles me that this is implemented minimally near
the surface, and that it is controlled by the "bisect" Porcelain
alone, by explicitly passing command line arguments.
I think a mechanism like this should be added to replace grafts, but it
should always be enabled for normal revision traversal operation, while
always disabled for object enumeration and transfer operation (iow, fsck,
fetch and push should use the real ancestry information recorded in the
underlying objects, while rev-list, log, etc. should always use the
replaced objects). I have a suspicion that even cat-file could honor it.
----------------------------------------------------------------
[Graduated to "master"]
* bc/maint-keep-pack (Thu Nov 13 14:11:46 2008 -0600) 1 commit
+ repack: only unpack-unreachable if we are deleting redundant packs
This makes "repack -A -d" without -d do the same thing as "repack -a -d",
which makes sense. This does not have to go to 'maint', though.
* jk/commit-v-strip (Wed Nov 12 03:23:37 2008 -0500) 4 commits
+ status: show "-v" diff even for initial commit
+ Merge branch 'jk/maint-commit-v-strip' into jk/commit-v-strip
+ wt-status: refactor initial commit printing
+ define empty tree sha1 as a macro
----------------------------------------------------------------
[Will merge to "master" soon]
* lt/preload-lstat (Mon Nov 17 09:01:20 2008 -0800) 2 commits
+ Fix index preloading for racy dirty case
+ Add cache preload facility
* ta/quiet-pull (Mon Nov 17 23:09:30 2008 +0100) 2 commits
+ Retain multiple -q/-v occurrences in git pull
+ Teach/Fix pull/fetch -q/-v options
* nd/narrow (Tue Nov 18 06:33:16 2008 -0500) 10 commits
+ t2104: touch portability fix
+ grep: skip files outside sparse checkout area
+ checkout_entry(): CE_NO_CHECKOUT on checked out entries.
+ Prevent diff machinery from examining worktree outside sparse
checkout
+ ls-files: Add tests for --sparse and friends
+ update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
+ update-index: refactor mark_valid() in preparation for new options
+ ls-files: add options to support sparse checkout
+ Introduce CE_NO_CHECKOUT bit
+ Extend index to save more flags
* ph/send-email (Tue Nov 11 00:54:02 2008 +0100) 4 commits
+ git send-email: ask less questions when --compose is used.
+ git send-email: add --annotate option
+ git send-email: interpret unknown files as revision lists
+ git send-email: make the message file name more specific.
----------------------------------------------------------------
[Actively Cooking]
* cb/mergetool (Thu Nov 13 12:41:15 2008 +0000) 3 commits
- [DONTMERGE] Add -k/--keep-going option to mergetool
- Add -y/--no-prompt option to mergetool
- Fix some tab/space inconsistencies in git-mergetool.sh
Jeff had good comments on the last one; the discussion needs concluded,
and also waiting for comments from the original author (Ted).
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
- autoconf: Enable threaded delta search when pthreads are supported
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
----------------------------------------------------------------
[On Hold]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
^ permalink raw reply
* What's in git.git (Nov 2008, #04; Wed, 26)
From: Junio C Hamano @ 2008-11-27 0:28 UTC (permalink / raw)
To: git
I suspect many people especially the ones in the US will be in vacation
mode and not near their keyboards til next week, but here is an update.
There are a few 'maint' material cooking in 'next' and v1.6.0.5 should be
tagged at the end of the month.
At around the same time I am hoping majority of topics cooking in 'next'
tonight can be in 'master' and we can tagl v1.6.1-rc1.
* The 'maint' branch has these fixes since the last announcement.
Bryan Drewery (1):
Fix misleading wording for git-cherry-pick
Junio C Hamano (3):
builtin-ls-files.c: coding style fix.
Teach ls-files --with-tree=<tree> to work with options other than -c
Teach "git diff" to honour --[no-]ext-diff
Matt McCutchen (1):
config.txt: alphabetize configuration sections
Stefan Naewe (1):
request-pull: make usage string match manpage
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (2):
Fix handle leak in sha1_file/unpack_objects if there were damaged object
data
Fix t4030-diff-textconv.sh
Alexander Gavrilov (6):
git-gui: Implement system-wide configuration handling.
git-gui: Fix the after callback execution in rescan.
git-gui: Add a Tools menu for arbitrary commands.
git-gui: Allow Tools request arguments from the user.
git-gui: Implement automatic rescan after Tool execution.
git-gui: Fix the search bar destruction handler.
Alexandre Julliard (9):
git.el: Improve error handling for commits.
git.el: Remove the env parameter in git-call-process and
git-call-process-string.
git.el: Simplify handling of merge heads in the commit log-edit buffer.
git.el: Properly handle merge commits in git-amend-commit.
git.el: Fix git-amend-commit to support amending an initial commit.
git.el: Never clear the status buffer, only update the files.
git.el: Add an insert file command.
git.el: Add possibility to mark files directly in
git-update-status-files.
git.el: Allow to commit even if there are no marked files.
Brandon Casey (1):
repack: only unpack-unreachable if we are deleting redundant packs
Cheng Renquan (1):
git-remote: match usage string with the manual pages
Christian Couder (2):
Documentation: user-manual: add information about "git help" at the
beginning
Documentation: tutorial: add information about "git help" at the
beginning
Giuseppe Bilotta (1):
git-gui: try to provide a window icon under X
Jeff King (3):
define empty tree sha1 as a macro
wt-status: refactor initial commit printing
status: show "-v" diff even for initial commit
Jim Meyering (1):
xdiff-interface.c: remove 10 duplicated lines
Joey Hess (1):
sha1_file: avoid bogus "file exists" error message
Junio C Hamano (1):
builtin-remote.c: plug a small memory leak in
get_one_remote_for_updates()
Linus Torvalds (1):
Fix machine-parseability of 'git log --source'
Marcel Koeppen (1):
t9129-git-svn-i18n-commitencoding: Make compare_svn_head_with()
compatible with OSX sed
Mark Burton (2):
Documentation: rev-list-options.txt: added --branches, --tags &
--remotes.
git-commit.txt - mention that files listed on the command line must be
known to git.
Miklos Vajna (3):
builtin-branch: use strbuf in delete_branches()
builtin-branch: use strbuf in fill_tracking_info()
builtin-branch: use strbuf in rename_branch()
Shawn O. Pearce (1):
Update the po template
Trent Piepho (1):
send-email: Fix Pine address book parsing
^ permalink raw reply
* Re: [PATCH 1/2] Add / command in add --patch (feature request)
From: Junio C Hamano @ 2008-11-26 22:54 UTC (permalink / raw)
To: Jeff King; +Cc: William Pursell, git
In-Reply-To: <20081126223858.GB10786@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 26, 2008 at 08:51:20PM +0000, William Pursell wrote:
>
>> This is naive, and it is easy for an invalid
>> search string to cause a perl error.
>> [...]
>> + if( $text !~ $search_s ) {
>
> Yeah, a bad regex will cause the whole program to barf. Maybe wrap it in
> an eval, like this?
>
> my $r = eval { $text !~ $search_s };
> if ($@) {
> print STDERR "error in search string: $@\n";
> next;
> }
> if ($r) {
> ...
>
> Or similar (I didn't look at the code closely enough to know if "next"
> is the right thing there).
Use of eval is a good way to protect against this kind of breakage, but it
should be done close to where the string is given by the user, perhaps in
here:
+ elsif ($line =~ m|^/(.*)|) {
+ $search_s = $1;
+ }
Something like...
elsif ($line =~ m|^/(.*)|) {
$search_string = $1;
eval {
$search_string =~ /$search_string/;
};
if ($@) {
print STDERR "Regexp error in $search_string: $@";
next;
}
...
^ permalink raw reply
* Re: [PATCH 1/2] Add / command in add --patch (feature request)
From: Jeff King @ 2008-11-26 22:38 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <492DB6C8.7010205@gmail.com>
On Wed, Nov 26, 2008 at 08:51:20PM +0000, William Pursell wrote:
> This is naive, and it is easy for an invalid
> search string to cause a perl error.
> [...]
> + if( $text !~ $search_s ) {
Yeah, a bad regex will cause the whole program to barf. Maybe wrap it in
an eval, like this?
my $r = eval { $text !~ $search_s };
if ($@) {
print STDERR "error in search string: $@\n";
next;
}
if ($r) {
...
Or similar (I didn't look at the code closely enough to know if "next"
is the right thing there).
-Peff
^ permalink raw reply
* 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
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