* git vs hg commit counts?
From: Joe Perches @ 2009-10-27 0:08 UTC (permalink / raw)
To: LKML; +Cc: git, mercurial, Marti Raudsepp
I'm comparing linux-kernel git vs hg repositories.
While testing some changes to scripts/get_maintainer.pl,
I noticed that git and hg have different commit counts
for the same files.
For instance:
$ git log --since=1-year-ago -- MAINTAINERS | \
grep -P "^commit [0-9a-f]{40,40}$" | wc -l
514
$ hg log --template="commit {node}\n" --date -365 -- MAINTAINERS | \
grep -P "^commit [0-9a-f]{40,40}$" | wc -l
601
Anyone have any understanding why?
^ permalink raw reply
* Re: git vs hg commit counts?
From: Junio C Hamano @ 2009-10-27 0:18 UTC (permalink / raw)
To: Joe Perches; +Cc: LKML, git, mercurial, Marti Raudsepp
In-Reply-To: <1256602127.29938.8.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> I'm comparing linux-kernel git vs hg repositories.
>
> While testing some changes to scripts/get_maintainer.pl,
> I noticed that git and hg have different commit counts
> for the same files.
>
> For instance:
>
> $ git log --since=1-year-ago -- MAINTAINERS | \
> grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> 514
>
> $ hg log --template="commit {node}\n" --date -365 -- MAINTAINERS | \
> grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> 601
>
> Anyone have any understanding why?
We simplify a merge history by discarding one branch when the merge result
matches one of the parents. Does "hg" know how to do that as well?
^ permalink raw reply
* Problems with git am
From: Alan @ 2009-10-27 0:12 UTC (permalink / raw)
To: git
I am encountering an interesting issue. I am not certain if I am doing
something wrong or I am encountering a bug or what.
I am using Git version 1.6.0.6 from Fedora 9. I am not using the current
version because it has changed how it errors out. (If git does not
understand the patch, instead of exiting with an error code that xargs
will fail on it exits with something non-fatal.)
I have a number of patches that I have been handed to apply to a git tree.
The patches have been generated by git, but have not been e-mailed. (They
may have been extracted from gitweb or some other source.)
The header of the patch looks like:
commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
Author: Joe Example <joe@example.com>
Date: Wed Sep 19 10:03:47 2009 -0600
There is no e-mail line, but it has the information for e-mail address.
If I apply this patch it will error out with:
"Patch does not have a valid e-mail address."
If I use a current version of Git it errors out with a message "Cannot
determine patch format", but does not issue a fatal error code.
If I use git-apply on this patch, it applies it to the tree, but does not
commit it. (I need the comments and signoffs to remain intact.) I have to
cut-and-paste the commit information to keep it. (I am working on an
automated process to handle these patches and don' want to have to
reinvent git-am.)
Am i doing something wrong here?
My goal is to be able to take whatever patch I am handed and apply it to
the current tree. If it is a raw diff, I can handle that. What concerns
me are these patches that look like they are generated by git, but which
do not apply cleanly with git-am.
Is there some sort of instructions for applying patches that are dumped
out using "git-show" or some other mechanism?
I am not finding this process documented anywhere. (If it is, it is
pretty well hidden.)
Thanks!
^ permalink raw reply
* Re: git vs hg commit counts?
From: Joe Perches @ 2009-10-27 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: LKML, git, mercurial, Marti Raudsepp
In-Reply-To: <7v8wexd6zq.fsf@alter.siamese.dyndns.org>
On Mon, 2009-10-26 at 17:18 -0700, Junio C Hamano wrote:
> > $ git log --since=1-year-ago -- MAINTAINERS | \
> > grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> > 514
> > $ hg log --template="commit {node}\n" --date -365 -- MAINTAINERS | \
> > grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> > 601
> > Anyone have any understanding why?
> We simplify a merge history by discarding one branch when the merge result
> matches one of the parents.
Thanks Junio.
> Does "hg" know how to do that as well?
I don't know.
I was hoping to get equivalent results though.
Anyone know how?
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: eschvoca @ 2009-10-27 0:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: kusmabite, git
In-Reply-To: <alpine.DEB.1.00.0910262210480.4985@pacific.mpi-cbg.de>
Hi,
On Mon, Oct 26, 2009 at 5:11 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 26 Oct 2009, eschvoca wrote:
>
>> On Mon, Oct 26, 2009 at 1:25 PM, Erik Faye-Lund
>> <kusmabite@googlemail.com> wrote:
>> > On Mon, Oct 26, 2009 at 6:14 PM, eschvoca <eschvoca@gmail.com> wrote:
>> >> Hi,
>> >>
>> >> Is there a way to rewrite history, including the first commit. It
>> >> seems that the first commit can not be modified with a rebase.
>> >
>> > This question is answered in the FAQ:
>> > http://git.or.cz/gitwiki/GitFaq#HowdoIedittherootcommit.3F
>>
>> Thanks Eric. Hopefully someone will enhance rebase to handle the root
>> commit.
>
> If you cannot do it yourself, you can always offer to bribe^Wpay somebody
> to do it for you.
>
> Ciao,
> Dscho
>
I can do the workaround myself but not the production ready patch.
Right now the only bribe I can offer is that it might be less work
writing the patch than supporting this corner case with answering
questions and writing a FAQ entry about it. It also would make the
awesome rebase -i even awesomer :) I know, a disappointing bribe but
from a thankful user.
Thanks
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Clemens Buchacher @ 2009-10-27 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, Shawn O. Pearce, git, Sverre Rabbelier
In-Reply-To: <7vocntd7vt.fsf@alter.siamese.dyndns.org>
On Mon, Oct 26, 2009 at 04:59:18PM -0700, Junio C Hamano wrote:
> Stephen Boyd <bebarino@gmail.com> writes:
>
> > This duplicates code, but I don't know of a way to re-use the dynamic
> > code without sourcing a bash script and possibly breaking someone's build.
>
> (1) If the script notices that there is a file that contains the command
> list, it sources it; otherwise,
Or we substitute the command list in-place, so that we still have the entire
completion script in one file.
Clemens
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Junio C Hamano @ 2009-10-27 0:38 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, Stephen Boyd, Shawn O. Pearce, git,
Sverre Rabbelier
In-Reply-To: <20091027003353.GA29205@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Mon, Oct 26, 2009 at 04:59:18PM -0700, Junio C Hamano wrote:
>
>> Stephen Boyd <bebarino@gmail.com> writes:
>>
>> > This duplicates code, but I don't know of a way to re-use the dynamic
>> > code without sourcing a bash script and possibly breaking someone's build.
>>
>> (1) If the script notices that there is a file that contains the command
>> list, it sources it; otherwise,
>
> Or we substitute the command list in-place, so that we still have the entire
> completion script in one file.
That defeats the whole point of my suggestion, as you would be overwriting
the tracked file.
^ permalink raw reply
* Re: Problems with git am
From: Junio C Hamano @ 2009-10-27 0:52 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <59976.134.134.139.70.1256602329.squirrel@clueserver.org>
"Alan" <alan@clueserver.org> writes:
> The header of the patch looks like:
>
> commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
> Author: Joe Example <joe@example.com>
> Date: Wed Sep 19 10:03:47 2009 -0600
It shouldn't.
The format "git am" understands is a mbox file and format-patch is the
command to write commits out in that form. It should begin with lines
that look like:
From 610f99ec7d22b5750f12350f67c1341d6be8030f Mon Sep 17 00:00:00 2001
From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 25 Oct 2009 18:41:09 -0700
Subject: [PATCH] Update draft release notes to 1.6.6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
.... patch follows here ...
I do not think it is particularly hard to add a new case arm in "am" to
support "git log" output. It is different from a mbox format in that it
* begins each commit with "commit " marker;
* has Author: and Date: header that is different from a mailbox;
* lacks Subject: but makes it part of the message body; and
* indents the message by 4 places.
Nobody has bothered to do so, probably because nobody needed it.
The easiest, safest and quickest for you right now (meaning, before
waiting for anybody to help you by adding a new feature to "am") would be
to see if it is possible for you to get the commits re-exported in an
appropriate format.
I say the "safest" in the above because you _could_ massage what you have
into a format that looks like a mbox with some Perl script, but it risks
mismassaging.
^ permalink raw reply
* Re: [PATCH] gitk: Add Japanese translation
From: Mizar @ 2009-10-27 1:03 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vtyxld7vy.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
Junio C Hamano writes:
> Wow, thanks.
>
> Having an empty msgstr "" for yet-to-be-translated entries is slightly
> misleading. People who work on PO files can spot them, but those who try
> your wip translation files cannot spot them in the UI.
>
> I am not sure if I am happy with the word used as the translation of
> "reference".
>
> Comments on just a few items I noticed (I didn't read everything that
> deeply, though).
Thanks for response.
Fixed translation as follows.
> git-gui seems to say "大文字小文字を区別" for this.
| #: gitk:2099 gitk:2101
| msgid "Exact"
|-msgstr "A-Z/a-zを区別"
|+msgstr "英字の大小を区別する"
|
| #: gitk:2101 gitk:4447 gitk:6248
| msgid "IgnCase"
|-msgstr "A-Z/a-zを区別しない"
|+msgstr "英字の大小を区別しない"
> Perhaps 「親コミットから blame をかける」
> Perhaps「この行の出自を表示する」
> Perhaps「この行に git gui で blame をかける」
| #: gitk:2397
| msgid "Blame parent commit"
|-msgstr ""
|+msgstr "親コミットから blame をかける"
|
| #: gitk:2404
| msgid "Show origin of this line"
|-msgstr ""
|+msgstr "この行の出自を表示する"
|
| #: gitk:2405
| msgid "Run git gui blame on this line"
|-msgstr ""
|+msgstr "この行に git gui で blame をかける"
> 「ここにはリポジトリがありません」。
| #: gitk:11137
| msgid "Cannot find a git repository here."
|-msgstr "ここでgitリポジトリを見つけられません。"
|+msgstr "ここにはgitリポジトリがありません。"
> 「コマンド行」would be equally common and shorter.
| #: gitk:11285
| msgid "Command line"
|-msgstr "コマンドライン"
|+msgstr "コマンド行"
[-- Attachment #2: ja.po --]
[-- Type: application/octet-stream, Size: 25784 bytes --]
# Japanese translations for gitk package.
# Copyright (C) 2005-2009 Paul Mackerras
# This file is distributed under the same license as the gitk package.
#
# Mizar <mizar.jp@gmail.com>, 2009.
# Junio C Hamano <gitster@pobox.com>, 2009.
msgid ""
msgstr ""
"Project-Id-Version: gitk\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2009-10-19 02:45+0900\n"
"PO-Revision-Date: 2009-10-19 17:03+0900\n"
"Last-Translator: Mizar <mizar.jp@gmail.com>\n"
"Language-Team: Japanese\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0;\n"
#: gitk:113
msgid "Couldn't get list of unmerged files:"
msgstr "マージされていないファイルの一覧を取得できません:"
#: gitk:269
msgid "Error parsing revisions:"
msgstr "リビジョン解析エラー:"
#: gitk:324
msgid "Error executing --argscmd command:"
msgstr "--argscmd コマンド実行エラー:"
#: gitk:337
msgid "No files selected: --merge specified but no files are unmerged."
msgstr "ファイル未選択: --merge が指定されましたが、マージされていないファイルはありません。"
#: gitk:340
msgid ""
"No files selected: --merge specified but no unmerged files are within file "
"limit."
msgstr "ファイル未選択: --merge が指定されましたが、"
"ファイル制限内にマージされていないファイルはありません。"
#: gitk:362 gitk:509
msgid "Error executing git log:"
msgstr "git log 実行エラー:"
#: gitk:380 gitk:525
msgid "Reading"
msgstr "読み込み中"
#: gitk:440 gitk:4131
msgid "Reading commits..."
msgstr "コミット読み込み中..."
#: gitk:443 gitk:1561 gitk:4134
msgid "No commits selected"
msgstr "コミットが選択されていません"
#: gitk:1437
msgid "Can't parse git log output:"
msgstr "git log の出力を解析できません:"
#: gitk:1657
msgid "No commit information available"
msgstr "有効なコミットの情報がありません"
#: gitk:1793 gitk:1817 gitk:3924 gitk:8822 gitk:10358 gitk:10534
msgid "OK"
msgstr "OK"
#: gitk:1819 gitk:3926 gitk:8419 gitk:8493 gitk:8603 gitk:8652 gitk:8824
#: gitk:10359 gitk:10535
msgid "Cancel"
msgstr "キャンセル"
#: gitk:1919
msgid "Update"
msgstr "更新"
#: gitk:1920
msgid "Reload"
msgstr "リロード"
#: gitk:1921
msgid "Reread references"
msgstr "参照を再読み込み"
#: gitk:1922
msgid "List references"
msgstr "参照リストを表示"
#: gitk:1924
msgid "Start git gui"
msgstr "git gui の開始"
#: gitk:1926
msgid "Quit"
msgstr "終了"
#: gitk:1918
msgid "File"
msgstr "ファイル"
#: gitk:1930
msgid "Preferences"
msgstr "設定"
#: gitk:1929
msgid "Edit"
msgstr "編集"
#: gitk:1934
msgid "New view..."
msgstr "新規ビュー..."
#: gitk:1935
msgid "Edit view..."
msgstr "ビュー編集..."
#: gitk:1936
msgid "Delete view"
msgstr "ビュー削除"
#: gitk:1938
msgid "All files"
msgstr "全てのファイル"
#: gitk:1933 gitk:3678
msgid "View"
msgstr "ビュー"
#: gitk:1943 gitk:1953 gitk:2655
msgid "About gitk"
msgstr "gitk について"
#: gitk:1944 gitk:1958
msgid "Key bindings"
msgstr "キーバインディング"
#: gitk:1942 gitk:1957
msgid "Help"
msgstr "ヘルプ"
#: gitk:2018
msgid "SHA1 ID: "
msgstr "SHA1 ID: "
#: gitk:2049
msgid "Row"
msgstr "行"
#: gitk:2080
msgid "Find"
msgstr "検索"
#: gitk:2081
msgid "next"
msgstr "次"
#: gitk:2082
msgid "prev"
msgstr "前"
#: gitk:2083
msgid "commit"
msgstr "コミット"
#: gitk:2086 gitk:2088 gitk:4292 gitk:4315 gitk:4339 gitk:6280 gitk:6352
#: gitk:6436
msgid "containing:"
msgstr "含む:"
#: gitk:2089 gitk:3163 gitk:3168 gitk:4367
msgid "touching paths:"
msgstr "パスの一部:"
#: gitk:2090 gitk:4372
msgid "adding/removing string:"
msgstr "追加/除去する文字列:"
#: gitk:2099 gitk:2101
msgid "Exact"
msgstr "英字の大小を区別する"
#: gitk:2101 gitk:4447 gitk:6248
msgid "IgnCase"
msgstr "英字の大小を区別しない"
#: gitk:2101 gitk:4341 gitk:4445 gitk:6244
msgid "Regexp"
msgstr "正規表現"
#: gitk:2103 gitk:2104 gitk:4466 gitk:4496 gitk:4503 gitk:6372 gitk:6440
msgid "All fields"
msgstr "全ての項目"
#: gitk:2104 gitk:4464 gitk:4496 gitk:6311
msgid "Headline"
msgstr "ヘッドライン"
#: gitk:2105 gitk:4464 gitk:6311 gitk:6440 gitk:6874
msgid "Comments"
msgstr "コメント"
#: gitk:2105 gitk:4464 gitk:4468 gitk:4503 gitk:6311 gitk:6809 gitk:8071
#: gitk:8086
msgid "Author"
msgstr "作成者"
#: gitk:2105 gitk:4464 gitk:6311 gitk:6811
msgid "Committer"
msgstr "コミットした人"
#: gitk:2134
msgid "Search"
msgstr "検索"
#: gitk:2141
msgid "Diff"
msgstr "Diff"
#: gitk:2143
msgid "Old version"
msgstr "旧バージョン"
#: gitk:2145
msgid "New version"
msgstr "新バージョン"
#: gitk:2147
msgid "Lines of context"
msgstr "文脈行数"
#: gitk:2157
msgid "Ignore space change"
msgstr "空白の違いを無視"
#: gitk:2215
msgid "Patch"
msgstr "パッチ"
#: gitk:2217
msgid "Tree"
msgstr "ツリー"
#: gitk:2361 gitk:2378
msgid "Diff this -> selected"
msgstr "diff これ -> 選択"
#: gitk:2362 gitk:2379
msgid "Diff selected -> this"
msgstr "diff 選択 -> これ"
#: gitk:2363 gitk:2380
msgid "Make patch"
msgstr "パッチ作成"
#: gitk:2364 gitk:8477
msgid "Create tag"
msgstr "タグ生成"
#: gitk:2365 gitk:8583
msgid "Write commit to file"
msgstr "コミットをファイルに書き込む"
#: gitk:2366 gitk:8640
msgid "Create new branch"
msgstr "新規ブランチ生成"
#: gitk:2367
msgid "Cherry-pick this commit"
msgstr "このコミットをチェリーピックする"
#: gitk:2368
msgid "Reset HEAD branch to here"
msgstr "ブランチのHEADをここにリセットする"
#: gitk:2369
msgid "Mark this commit"
msgstr "このコミットにマークをつける"
#: gitk:2370
msgid "Return to mark"
msgstr "マークを付けた所に戻る"
#: gitk:2371
msgid "Find descendant of this and mark"
msgstr "この子孫を見つけてマークする"
#: gitk:2372
msgid "Compare with marked commit"
msgstr "マークを付けたコミットと比較する"
#: gitk:2386
msgid "Check out this branch"
msgstr "このブランチをチェックアウトする"
#: gitk:2387
msgid "Remove this branch"
msgstr "このブランチを除去する"
#: gitk:2394
msgid "Highlight this too"
msgstr "これもハイライトさせる"
#: gitk:2395
msgid "Highlight this only"
msgstr "これだけをハイライトさせる"
#: gitk:2396
msgid "External diff"
msgstr "外部diffツール"
#: gitk:2397
msgid "Blame parent commit"
msgstr "親コミットから blame をかける"
#: gitk:2404
msgid "Show origin of this line"
msgstr "この行の出自を表示する"
#: gitk:2405
msgid "Run git gui blame on this line"
msgstr "この行に git gui で blame をかける"
#: gitk:2657
msgid ""
"\n"
"Gitk - a commit viewer for git\n"
"\n"
"Copyright © 2005-2008 Paul Mackerras\n"
"\n"
"Use and redistribute under the terms of the GNU General Public License"
msgstr ""
"\n"
"Gitk - gitコミットビューア\n"
"\n"
"Copyright (c) 2005-2008 Paul Mackerras\n"
"\n"
"使用および再配布はGNU General Public License に従ってください"
#: gitk:2665 gitk:2727 gitk:9005
msgid "Close"
msgstr "閉じる"
#: gitk:2684
msgid "Gitk key bindings"
msgstr "Gitk キーバインディング"
#: gitk:2687
msgid "Gitk key bindings:"
msgstr "Gitk キーバインディング:"
#: gitk:2689
#, tcl-format
msgid "<%s-Q>\t\tQuit"
msgstr "<%s-Q>\t\t終了"
#: gitk:2690
msgid "<Home>\t\tMove to first commit"
msgstr "<Home>\t\t最初のコミットに移動"
#: gitk:2691
msgid "<End>\t\tMove to last commit"
msgstr "<End>\t\t最後のコミットに移動"
#: gitk:2692
msgid "<Up>, p, i\tMove up one commit"
msgstr "<Up>, p, i\t一つ上のコミットに移動"
#: gitk:2693
msgid "<Down>, n, k\tMove down one commit"
msgstr "<Down>, n, k\t一つ下のコミットに移動"
#: gitk:2694
msgid "<Left>, z, j\tGo back in history list"
msgstr "<Left>, z, j\t履歴の前に戻る"
#: gitk:2695
msgid "<Right>, x, l\tGo forward in history list"
msgstr "<Right>, x, l\t履歴の次へ進む"
#: gitk:2696
msgid "<PageUp>\tMove up one page in commit list"
msgstr "<PageUp>\tコミットリストの一つ上のページに移動"
#: gitk:2697
msgid "<PageDown>\tMove down one page in commit list"
msgstr "<PageDown>\tコミットリストの一つ下のページに移動"
#: gitk:2698
#, tcl-format
msgid "<%s-Home>\tScroll to top of commit list"
msgstr "<%s-Home>\tコミットリストの一番上にスクロールする"
#: gitk:2699
#, tcl-format
msgid "<%s-End>\tScroll to bottom of commit list"
msgstr "<%s-End>\tコミットリストの一番下にスクロールする"
#: gitk:2700
#, tcl-format
msgid "<%s-Up>\tScroll commit list up one line"
msgstr "<%s-Up>\tコミットリストの一つ下の行にスクロールする"
#: gitk:2701
#, tcl-format
msgid "<%s-Down>\tScroll commit list down one line"
msgstr "<%s-Down>\tコミットリストの一つ下の行にスクロールする"
#: gitk:2702
#, tcl-format
msgid "<%s-PageUp>\tScroll commit list up one page"
msgstr "<%s-PageUp>\tコミットリストの上のページにスクロールする"
#: gitk:2703
#, tcl-format
msgid "<%s-PageDown>\tScroll commit list down one page"
msgstr "<%s-PageDown>\tコミットリストの下のページにスクロールする"
#: gitk:2704
msgid "<Shift-Up>\tFind backwards (upwards, later commits)"
msgstr "<Shift-Up>\t後ろを検索 (上方・後のコミット)"
#: gitk:2705
msgid "<Shift-Down>\tFind forwards (downwards, earlier commits)"
msgstr "<Shift-Down>\t前を検索（下方・前のコミット）"
#: gitk:2706
msgid "<Delete>, b\tScroll diff view up one page"
msgstr "<Delete>, b\tdiff画面を上のページにスクロールする"
#: gitk:2707
msgid "<Backspace>\tScroll diff view up one page"
msgstr "<Backspace>\tdiff画面を上のページにスクロールする"
#: gitk:2708
msgid "<Space>\t\tScroll diff view down one page"
msgstr "<Space>\t\tdiff画面を下のページにスクロールする"
#: gitk:2709
msgid "u\t\tScroll diff view up 18 lines"
msgstr "u\t\tdiff画面を上に18行スクロールする"
#: gitk:2710
msgid "d\t\tScroll diff view down 18 lines"
msgstr "d\t\tdiff画面を下に18行スクロールする"
#: gitk:2711
#, tcl-format
msgid "<%s-F>\t\tFind"
msgstr "<%s-F>\t\t検索"
#: gitk:2712
#, tcl-format
msgid "<%s-G>\t\tMove to next find hit"
msgstr "<%s-G>\t\t次を検索して移動"
#: gitk:2713
msgid "<Return>\tMove to next find hit"
msgstr "<Return>\t次を検索して移動"
#: gitk:2714
msgid "/\t\tFocus the search box"
msgstr "/\t\t検索ボックスにフォーカス"
#: gitk:2715
msgid "?\t\tMove to previous find hit"
msgstr "?\t\t前を検索して移動"
#: gitk:2716
msgid "f\t\tScroll diff view to next file"
msgstr "f\t\t次のファイルにdiff画面をスクロールする"
#: gitk:2717
#, tcl-format
msgid "<%s-S>\t\tSearch for next hit in diff view"
msgstr "<%s-S>\t\tdiff画面の次を検索"
#: gitk:2718
#, tcl-format
msgid "<%s-R>\t\tSearch for previous hit in diff view"
msgstr "<%s-R>\t\tdiff画面の前を検索"
#: gitk:2719
#, tcl-format
msgid "<%s-KP+>\tIncrease font size"
msgstr "<%s-KP+>\t文字サイズを拡大"
#: gitk:2720
#, tcl-format
msgid "<%s-plus>\tIncrease font size"
msgstr "<%s-plus>\t文字サイズを拡大"
#: gitk:2721
#, tcl-format
msgid "<%s-KP->\tDecrease font size"
msgstr "<%s-KP->\t文字サイズを縮小"
#: gitk:2722
#, tcl-format
msgid "<%s-minus>\tDecrease font size"
msgstr "<%s-minus>\t文字サイズを縮小"
#: gitk:2723
msgid "<F5>\t\tUpdate"
msgstr "<F5>\t\t更新"
#: gitk:3178 gitk:3187
#, tcl-format
msgid "Error creating temporary directory %s:"
msgstr "一時ディレクトリ %s 生成時エラー:"
#: gitk:3200
#, tcl-format
msgid "Error getting \"%s\" from %s:"
msgstr ""
#: gitk:3263
msgid "command failed:"
msgstr "コマンド失敗:"
#: gitk:3409
msgid "No such commit"
msgstr "そのようなコミットはありません"
#: gitk:3423
msgid "git gui blame: command failed:"
msgstr "git gui blame: コマンド失敗:"
#: gitk:3454
#, tcl-format
msgid "Couldn't read merge head: %s"
msgstr ""
#: gitk:3462
#, tcl-format
msgid "Error reading index: %s"
msgstr "インデックス読み込みエラー: %s"
#: gitk:3487
#, tcl-format
msgid "Couldn't start git blame: %s"
msgstr "git blame を始められません: %s"
#: gitk:3490 gitk:6279
msgid "Searching"
msgstr "検索中"
#: gitk:3522
#, tcl-format
msgid "Error running git blame: %s"
msgstr "git blame 実行エラー: %s"
#: gitk:3550
#, tcl-format
msgid "That line comes from commit %s, which is not in this view"
msgstr ""
#: gitk:3564
msgid "External diff viewer failed:"
msgstr "外部diffビューアが失敗:"
#: gitk:3682
msgid "Gitk view definition"
msgstr "Gitk ビュー定義"
#: gitk:3686
msgid "Remember this view"
msgstr "このビューを記憶する"
#: gitk:3687
msgid "References (space separated list):"
msgstr "参照（スペース区切りのリスト）:"
#: gitk:3688
msgid "Branches & tags:"
msgstr "ブランチ＆タグ:"
#: gitk:3689
msgid "All refs"
msgstr "全ての参照"
#: gitk:3690
msgid "All (local) branches"
msgstr "全ての（ローカルな）ブランチ"
#: gitk:3691
msgid "All tags"
msgstr "全てのタグ"
#: gitk:3692
msgid "All remote-tracking branches"
msgstr "全てのリモート追跡ブランチ"
#: gitk:3693
msgid "Commit Info (regular expressions):"
msgstr "コミット情報（正規表現）:"
#: gitk:3694
msgid "Author:"
msgstr "作成者:"
#: gitk:3695
msgid "Committer:"
msgstr "コミットした人:"
#: gitk:3696
msgid "Commit Message:"
msgstr "コミットメッセージ:"
#: gitk:3697
msgid "Matches all Commit Info criteria"
msgstr "コミット情報の全ての条件に一致"
#: gitk:3698
msgid "Changes to Files:"
msgstr "変更したファイル:"
#: gitk:3699
msgid "Fixed String"
msgstr "固定文字列"
#: gitk:3700
msgid "Regular Expression"
msgstr "正規表現"
#: gitk:3701
msgid "Search string:"
msgstr "検索文字列:"
#: gitk:3702
msgid ""
"Commit Dates (\"2 weeks ago\", \"2009-03-17 15:27:38\", \"March 17, 2009 "
"15:27:38\"):"
msgstr "コミット日時 (\"2 weeks ago\", \"2009-03-17 15:27:38\", \"March 17, 2009 "
"15:27:38\"):"
#: gitk:3703
msgid "Since:"
msgstr "期間の始め:"
#: gitk:3704
msgid "Until:"
msgstr "期間の終わり:"
#: gitk:3705
msgid "Limit and/or skip a number of revisions (positive integer):"
msgstr ""
#: gitk:3706
msgid "Number to show:"
msgstr ""
#: gitk:3707
msgid "Number to skip:"
msgstr ""
#: gitk:3708
msgid "Miscellaneous options:"
msgstr "その他のオプション:"
#: gitk:3709
msgid "Strictly sort by date"
msgstr "厳密に日付順で並び替え"
#: gitk:3710
msgid "Mark branch sides"
msgstr ""
#: gitk:3711
msgid "Limit to first parent"
msgstr ""
#: gitk:3712
msgid "Simple history"
msgstr "簡易な履歴"
#: gitk:3713
msgid "Additional arguments to git log:"
msgstr "git log への追加の引数:"
#: gitk:3714
msgid "Enter files and directories to include, one per line:"
msgstr "含まれるファイル・ディレクトリを一行ごとに入力:"
#: gitk:3715
msgid "Command to generate more commits to include:"
msgstr ""
#: gitk:3837
msgid "Gitk: edit view"
msgstr "Gitk: ビュー編集"
#: gitk:3845
msgid "-- criteria for selecting revisions"
msgstr "― リビジョンの選択条件"
#: gitk:3850
msgid "View Name:"
msgstr "ビュー名:"
#: gitk:3925
msgid "Apply (F5)"
msgstr "適用 (F5)"
#: gitk:3963
msgid "Error in commit selection arguments:"
msgstr "コミット選択引数のエラー:"
#: gitk:4016 gitk:4068 gitk:4516 gitk:4530 gitk:5791 gitk:11232 gitk:11233
msgid "None"
msgstr "無し"
#: gitk:4464 gitk:6311 gitk:8073 gitk:8088
msgid "Date"
msgstr ""
#: gitk:4464 gitk:6311
msgid "CDate"
msgstr ""
#: gitk:4613 gitk:4618
msgid "Descendant"
msgstr "子孫"
#: gitk:4614
msgid "Not descendant"
msgstr "非子孫"
#: gitk:4621 gitk:4626
msgid "Ancestor"
msgstr "祖先"
#: gitk:4622
msgid "Not ancestor"
msgstr "非祖先"
#: gitk:4912
msgid "Local changes checked in to index but not committed"
msgstr ""
#: gitk:4948
msgid "Local uncommitted changes, not checked in to index"
msgstr ""
#: gitk:6629
msgid "many"
msgstr "多数"
#: gitk:6813
msgid "Tags:"
msgstr "タグ:"
#: gitk:6830 gitk:6836 gitk:8066
msgid "Parent"
msgstr "親"
#: gitk:6841
msgid "Child"
msgstr "子"
#: gitk:6850
msgid "Branch"
msgstr "ブランチ"
#: gitk:6853
msgid "Follows"
msgstr "下位"
#: gitk:6856
msgid "Precedes"
msgstr "上位"
#: gitk:7354
#, tcl-format
msgid "Error getting diffs: %s"
msgstr ""
#: gitk:7894
msgid "Goto:"
msgstr ""
#: gitk:7896
msgid "SHA1 ID:"
msgstr "SHA1 ID:"
#: gitk:7915
#, tcl-format
msgid "Short SHA1 id %s is ambiguous"
msgstr "短縮 SHA1 ID %s は曖昧です"
#: gitk:7922
#, tcl-format
msgid "Revision %s is not known"
msgstr "リビジョン %s は不明です"
#: gitk:7932
#, tcl-format
msgid "SHA1 id %s is not known"
msgstr "SHA1 id %s は不明です"
#: gitk:7934
#, tcl-format
msgid "Revision %s is not in the current view"
msgstr "リビジョン %s は現在のビューにはありません"
#: gitk:8076
msgid "Children"
msgstr "子供達"
#: gitk:8133
#, tcl-format
msgid "Reset %s branch to here"
msgstr "%s ブランチをここにリセットする"
#: gitk:8135
msgid "Detached head: can't reset"
msgstr ""
#: gitk:8244 gitk:8250
msgid "Skipping merge commit "
msgstr ""
#: gitk:8259 gitk:8264
msgid "Error getting patch ID for "
msgstr ""
#: gitk:8260 gitk:8265
msgid " - stopping\n"
msgstr " - 停止\n"
#: gitk:8270 gitk:8273 gitk:8281 gitk:8294 gitk:8303
msgid "Commit "
msgstr "コミット "
#: gitk:8274
msgid ""
" is the same patch as\n"
" "
msgstr ""
#: gitk:8282
msgid ""
" differs from\n"
" "
msgstr ""
#: gitk:8284
msgid ""
"Diff of commits:\n"
"\n"
msgstr ""
#: gitk:8295 gitk:8304
#, tcl-format
msgid " has %s children - stopping\n"
msgstr ""
#: gitk:8324
#, tcl-format
msgid "Error writing commit to file: %s"
msgstr ""
#: gitk:8330
#, tcl-format
msgid "Error diffing commits: %s"
msgstr ""
#: gitk:8360
msgid "Top"
msgstr ""
#: gitk:8361
msgid "From"
msgstr "From"
#: gitk:8366
msgid "To"
msgstr "To"
#: gitk:8390
msgid "Generate patch"
msgstr "パッチ生成"
#: gitk:8392
msgid "From:"
msgstr "From:"
#: gitk:8401
msgid "To:"
msgstr "To:"
#: gitk:8410
msgid "Reverse"
msgstr "逆"
#: gitk:8412 gitk:8597
msgid "Output file:"
msgstr "出力ファイル:"
#: gitk:8418
msgid "Generate"
msgstr "生成"
#: gitk:8456
msgid "Error creating patch:"
msgstr "パッチ生成エラー:"
#: gitk:8479 gitk:8585 gitk:8642
msgid "ID:"
msgstr "ID:"
#: gitk:8488
msgid "Tag name:"
msgstr "タグ名:"
#: gitk:8492 gitk:8651
msgid "Create"
msgstr "生成"
#: gitk:8509
msgid "No tag name specified"
msgstr "タグの名称が指定されていません"
#: gitk:8513
#, tcl-format
msgid "Tag \"%s\" already exists"
msgstr "タグ \"%s\" は既に存在します"
#: gitk:8519
msgid "Error creating tag:"
msgstr "タグ生成エラー:"
#: gitk:8594
msgid "Command:"
msgstr "コマンド:"
#: gitk:8602
msgid "Write"
msgstr "書き込み"
#: gitk:8620
msgid "Error writing commit:"
msgstr ""
#: gitk:8647
msgid "Name:"
msgstr "名前:"
#: gitk:8670
msgid "Please specify a name for the new branch"
msgstr "新しいブランチの名前を指定してください"
#: gitk:8675
#, tcl-format
msgid "Branch '%s' already exists. Overwrite?"
msgstr "ブランチ '%s' は既に存在します。上書きしますか？"
#: gitk:8741
#, tcl-format
msgid "Commit %s is already included in branch %s -- really re-apply it?"
msgstr "コミット %s は既にブランチ %s に含まれています ― 本当にこれを再適用しますか？"
#: gitk:8746
msgid "Cherry-picking"
msgstr "チェリーピック中"
#: gitk:8755
#, tcl-format
msgid ""
"Cherry-pick failed because of local changes to file '%s'.\n"
"Please commit, reset or stash your changes and try again."
msgstr ""
"ファイル '%s' のローカルな変更のためにチェリーピックは失敗しました。\n"
"あなたの変更に commit, reset, stash のいずれかを行ってからやり直してください。"
#: gitk:8761
msgid ""
"Cherry-pick failed because of merge conflict.\n"
"Do you wish to run git citool to resolve it?"
msgstr ""
"マージの衝突によってチェリーピックは失敗しました。\n"
"この解決のために git citool を実行したいですか？"
#: gitk:8777
msgid "No changes committed"
msgstr ""
#: gitk:8803
msgid "Confirm reset"
msgstr ""
#: gitk:8805
#, tcl-format
msgid "Reset branch %s to %s?"
msgstr "ブランチ %s を %s にリセットしますか？"
#: gitk:8809
msgid "Reset type:"
msgstr "Reset タイプ:"
#: gitk:8813
msgid "Soft: Leave working tree and index untouched"
msgstr "Soft: 作業ツリーもインデックスもそのままにする"
#: gitk:8816
msgid "Mixed: Leave working tree untouched, reset index"
msgstr "Mixed: 作業ツリーをそのままにして、インデックスをリセット"
#: gitk:8819
msgid ""
"Hard: Reset working tree and index\n"
"(discard ALL local changes)"
msgstr ""
"Hard: 作業ツリーやインデックスをリセット\n"
"（「全ての」ローカルな変更を破棄）"
#: gitk:8836
msgid "Resetting"
msgstr "リセット中"
#: gitk:8893
msgid "Checking out"
msgstr "チェックアウト"
#: gitk:8946
msgid "Cannot delete the currently checked-out branch"
msgstr ""
#: gitk:8952
#, tcl-format
msgid ""
"The commits on branch %s aren't on any other branch.\n"
"Really delete branch %s?"
msgstr ""
"ブランチ %s 上のコミットは他のブランチに存在しません。\n"
"本当にブランチ %s を削除しますか？"
#: gitk:8983
#, tcl-format
msgid "Tags and heads: %s"
msgstr "タグとHEAD: %s"
#: gitk:8998
msgid "Filter"
msgstr "フィルター"
#: gitk:9293
msgid ""
"Error reading commit topology information; branch and preceding/following "
"tag information will be incomplete."
msgstr ""
#: gitk:10279
msgid "Tag"
msgstr "タグ"
#: gitk:10279
msgid "Id"
msgstr "ID"
#: gitk:10327
msgid "Gitk font chooser"
msgstr "Gitk フォント選択"
#: gitk:10344
msgid "B"
msgstr "B"
#: gitk:10347
msgid "I"
msgstr "I"
#: gitk:10443
msgid "Gitk preferences"
msgstr "Gitk 設定"
#: gitk:10445
msgid "Commit list display options"
msgstr "コミットリスト表示オプション"
#: gitk:10448
msgid "Maximum graph width (lines)"
msgstr "最大グラフ幅（線の本数）"
#: gitk:10452
#, tcl-format
msgid "Maximum graph width (% of pane)"
msgstr "最大グラフ幅（ペインに対する％）"
#: gitk:10456
msgid "Show local changes"
msgstr "ローカルな変更を表示"
#: gitk:10459
msgid "Auto-select SHA1"
msgstr "SHA1 の自動選択"
#: gitk:10463
msgid "Diff display options"
msgstr "diff表示オプション"
#: gitk:10465
msgid "Tab spacing"
msgstr "タブ空白幅"
#: gitk:10468
msgid "Display nearby tags"
msgstr "近くのタグを表示する"
#: gitk:10471
msgid "Hide remote refs"
msgstr "リモート参照を隠す"
#: gitk:10474
msgid "Limit diffs to listed paths"
msgstr ""
#: gitk:10477
msgid "Support per-file encodings"
msgstr "ファイルごとのエンコーディングのサポート"
#: gitk:10483 gitk:10548
msgid "External diff tool"
msgstr "外部diffツール"
#: gitk:10485
msgid "Choose..."
msgstr "選択..."
#: gitk:10490
msgid "Colors: press to choose"
msgstr "色: ボタンを押して選択"
#: gitk:10493
msgid "Background"
msgstr "背景"
#: gitk:10494 gitk:10524
msgid "background"
msgstr "背景"
#: gitk:10497
msgid "Foreground"
msgstr "前景"
#: gitk:10498
msgid "foreground"
msgstr "前景"
#: gitk:10501
msgid "Diff: old lines"
msgstr "Diff: 旧バージョン"
#: gitk:10502
msgid "diff old lines"
msgstr "diff 旧バージョン"
#: gitk:10506
msgid "Diff: new lines"
msgstr "Diff: 新バージョン"
#: gitk:10507
msgid "diff new lines"
msgstr "diff 新バージョン"
#: gitk:10511
msgid "Diff: hunk header"
msgstr "Diff: hunkヘッダ"
#: gitk:10513
msgid "diff hunk header"
msgstr "diff hunkヘッダ"
#: gitk:10517
msgid "Marked line bg"
msgstr "マーク行の背景"
#: gitk:10519
msgid "marked line background"
msgstr "マーク行の背景"
#: gitk:10523
msgid "Select bg"
msgstr "選択の背景"
#: gitk:10527
msgid "Fonts: press to choose"
msgstr "フォント: ボタンを押して選択"
#: gitk:10529
msgid "Main font"
msgstr "主フォント"
#: gitk:10530
msgid "Diff display font"
msgstr "Diff表示用フォント"
#: gitk:10531
msgid "User interface font"
msgstr "UI用フォント"
#: gitk:10558
#, tcl-format
msgid "Gitk: choose color for %s"
msgstr "Gitk: 「%s」 の色を選択"
#: gitk:11009
msgid ""
"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
" Gitk requires at least Tcl/Tk 8.4."
msgstr ""
"申し訳ありませんが、このバージョンの Tcl/Tk では gitk を実行できません。\n"
" Gitk は少なくとも Tcl/Tk 8.4 を必要とします。"
#: gitk:11137
msgid "Cannot find a git repository here."
msgstr "ここにはgitリポジトリがありません。"
#: gitk:11141
#, tcl-format
msgid "Cannot find the git directory \"%s\"."
msgstr "gitディレクトリ \"%s\" を見つけられません。"
#: gitk:11188
#, tcl-format
msgid "Ambiguous argument '%s': both revision and filename"
msgstr "あいまいな引数 '%s': リビジョンとファイル名の両方に解釈できます"
#: gitk:11200
msgid "Bad arguments to gitk:"
msgstr "gitkへの不正な引数:"
#: gitk:11285
msgid "Command line"
msgstr "コマンド行"
^ permalink raw reply
* [PATCH] gitignore: root most patterns at the top-level directory
From: Jeff King @ 2009-10-27 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Our gitignore doesn't use a preceding "/" to root its
patterns in the top of the repository. This means that if
you add a file or directory called "git" (for example)
inside a subdirectory, it will be erroneously ignored.
This patch was done mechanically with "s/^[^*]/\/&/" with
one exception: instead of ignoring gitk-wish, we should
gitk-git/gitk-wish (arguably, this should be done in
gitk-git/.gitignore, but because that is a subtree merge
from elsewhere, this is easier).
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
This bit Sverre while I was looking over his shoulder. I doubt it comes
up very often, but we should probably be modeling good gitignore
behavior. I have to admit it looks a lot uglier, though.
.gitignore | 354 ++++++++++++++++++++++++++++++------------------------------
1 files changed, 177 insertions(+), 177 deletions(-)
diff --git a/.gitignore b/.gitignore
index 51a37b1..289c3d0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,184 +1,184 @@
-GIT-BUILD-OPTIONS
-GIT-CFLAGS
-GIT-GUI-VARS
-GIT-VERSION-FILE
-git
-git-add
-git-add--interactive
-git-am
-git-annotate
-git-apply
-git-archimport
-git-archive
-git-bisect
-git-bisect--helper
-git-blame
-git-branch
-git-bundle
-git-cat-file
-git-check-attr
-git-check-ref-format
-git-checkout
-git-checkout-index
-git-cherry
-git-cherry-pick
-git-clean
-git-clone
-git-commit
-git-commit-tree
-git-config
-git-count-objects
-git-cvsexportcommit
-git-cvsimport
-git-cvsserver
-git-daemon
-git-diff
-git-diff-files
-git-diff-index
-git-diff-tree
-git-difftool
-git-difftool--helper
-git-describe
-git-fast-export
-git-fast-import
-git-fetch
-git-fetch--tool
-git-fetch-pack
-git-filter-branch
-git-fmt-merge-msg
-git-for-each-ref
-git-format-patch
-git-fsck
-git-fsck-objects
-git-gc
-git-get-tar-commit-id
-git-grep
-git-hash-object
-git-help
-git-http-fetch
-git-http-push
-git-imap-send
-git-index-pack
-git-init
-git-init-db
-git-instaweb
-git-log
-git-lost-found
-git-ls-files
-git-ls-remote
-git-ls-tree
-git-mailinfo
-git-mailsplit
-git-merge
-git-merge-base
-git-merge-index
-git-merge-file
-git-merge-tree
-git-merge-octopus
-git-merge-one-file
-git-merge-ours
-git-merge-recursive
-git-merge-resolve
-git-merge-subtree
-git-mergetool
-git-mergetool--lib
-git-mktag
-git-mktree
-git-name-rev
-git-mv
-git-pack-redundant
-git-pack-objects
-git-pack-refs
-git-parse-remote
-git-patch-id
-git-peek-remote
-git-prune
-git-prune-packed
-git-pull
-git-push
-git-quiltimport
-git-read-tree
-git-rebase
-git-rebase--interactive
-git-receive-pack
-git-reflog
-git-relink
-git-remote
-git-remote-curl
-git-repack
-git-replace
-git-repo-config
-git-request-pull
-git-rerere
-git-reset
-git-rev-list
-git-rev-parse
-git-revert
-git-rm
-git-send-email
-git-send-pack
-git-sh-setup
-git-shell
-git-shortlog
-git-show
-git-show-branch
-git-show-index
-git-show-ref
-git-stage
-git-stash
-git-status
-git-stripspace
-git-submodule
-git-svn
-git-symbolic-ref
-git-tag
-git-tar-tree
-git-unpack-file
-git-unpack-objects
-git-update-index
-git-update-ref
-git-update-server-info
-git-upload-archive
-git-upload-pack
-git-var
-git-verify-pack
-git-verify-tag
-git-web--browse
-git-whatchanged
-git-write-tree
-git-core-*/?*
-gitk-wish
-gitweb/gitweb.cgi
-test-chmtime
-test-ctype
-test-date
-test-delta
-test-dump-cache-tree
-test-genrandom
-test-match-trees
-test-parse-options
-test-path-utils
-test-sha1
-test-sigchain
-common-cmds.h
+/GIT-BUILD-OPTIONS
+/GIT-CFLAGS
+/GIT-GUI-VARS
+/GIT-VERSION-FILE
+/git
+/git-add
+/git-add--interactive
+/git-am
+/git-annotate
+/git-apply
+/git-archimport
+/git-archive
+/git-bisect
+/git-bisect--helper
+/git-blame
+/git-branch
+/git-bundle
+/git-cat-file
+/git-check-attr
+/git-check-ref-format
+/git-checkout
+/git-checkout-index
+/git-cherry
+/git-cherry-pick
+/git-clean
+/git-clone
+/git-commit
+/git-commit-tree
+/git-config
+/git-count-objects
+/git-cvsexportcommit
+/git-cvsimport
+/git-cvsserver
+/git-daemon
+/git-diff
+/git-diff-files
+/git-diff-index
+/git-diff-tree
+/git-difftool
+/git-difftool--helper
+/git-describe
+/git-fast-export
+/git-fast-import
+/git-fetch
+/git-fetch--tool
+/git-fetch-pack
+/git-filter-branch
+/git-fmt-merge-msg
+/git-for-each-ref
+/git-format-patch
+/git-fsck
+/git-fsck-objects
+/git-gc
+/git-get-tar-commit-id
+/git-grep
+/git-hash-object
+/git-help
+/git-http-fetch
+/git-http-push
+/git-imap-send
+/git-index-pack
+/git-init
+/git-init-db
+/git-instaweb
+/git-log
+/git-lost-found
+/git-ls-files
+/git-ls-remote
+/git-ls-tree
+/git-mailinfo
+/git-mailsplit
+/git-merge
+/git-merge-base
+/git-merge-index
+/git-merge-file
+/git-merge-tree
+/git-merge-octopus
+/git-merge-one-file
+/git-merge-ours
+/git-merge-recursive
+/git-merge-resolve
+/git-merge-subtree
+/git-mergetool
+/git-mergetool--lib
+/git-mktag
+/git-mktree
+/git-name-rev
+/git-mv
+/git-pack-redundant
+/git-pack-objects
+/git-pack-refs
+/git-parse-remote
+/git-patch-id
+/git-peek-remote
+/git-prune
+/git-prune-packed
+/git-pull
+/git-push
+/git-quiltimport
+/git-read-tree
+/git-rebase
+/git-rebase--interactive
+/git-receive-pack
+/git-reflog
+/git-relink
+/git-remote
+/git-remote-curl
+/git-repack
+/git-replace
+/git-repo-config
+/git-request-pull
+/git-rerere
+/git-reset
+/git-rev-list
+/git-rev-parse
+/git-revert
+/git-rm
+/git-send-email
+/git-send-pack
+/git-sh-setup
+/git-shell
+/git-shortlog
+/git-show
+/git-show-branch
+/git-show-index
+/git-show-ref
+/git-stage
+/git-stash
+/git-status
+/git-stripspace
+/git-submodule
+/git-svn
+/git-symbolic-ref
+/git-tag
+/git-tar-tree
+/git-unpack-file
+/git-unpack-objects
+/git-update-index
+/git-update-ref
+/git-update-server-info
+/git-upload-archive
+/git-upload-pack
+/git-var
+/git-verify-pack
+/git-verify-tag
+/git-web--browse
+/git-whatchanged
+/git-write-tree
+/git-core-*/?*
+/gitk-git/gitk-wish
+/gitweb/gitweb.cgi
+/test-chmtime
+/test-ctype
+/test-date
+/test-delta
+/test-dump-cache-tree
+/test-genrandom
+/test-match-trees
+/test-parse-options
+/test-path-utils
+/test-sha1
+/test-sigchain
+/common-cmds.h
*.tar.gz
*.dsc
*.deb
-git.spec
+/git.spec
*.exe
*.[aos]
*.py[co]
-config.mak
-autom4te.cache
-config.cache
-config.log
-config.status
-config.mak.autogen
-config.mak.append
-configure
-tags
-TAGS
-cscope*
+/config.mak
+/autom4te.cache
+/config.cache
+/config.log
+/config.status
+/config.mak.autogen
+/config.mak.append
+/configure
+/tags
+/TAGS
+/cscope*
*.obj
*.lib
*.sln
@@ -188,5 +188,5 @@ cscope*
*.user
*.idb
*.pdb
-Debug/
-Release/
+/Debug/
+/Release/
--
1.6.5.1.203.g342e8
^ permalink raw reply related
* Re: git vs hg commit counts?
From: Jakub Narebski @ 2009-10-27 1:14 UTC (permalink / raw)
To: Joe Perches; +Cc: LKML, git, mercurial, Marti Raudsepp
In-Reply-To: <1256602127.29938.8.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> I'm comparing linux-kernel git vs hg repositories.
>
> While testing some changes to scripts/get_maintainer.pl,
> I noticed that git and hg have different commit counts
> for the same files.
>
> For instance:
>
> $ git log --since=1-year-ago -- MAINTAINERS | \
> grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> 514
>
> $ hg log --template="commit {node}\n" --date -365 -- MAINTAINERS | \
> grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> 601
>
> Anyone have any understanding why?
It *might* be caused by the fact that in Mercurial commit can have
only up to two parents. This means that octopus merges (merge commits
with more than two parents: there are a few of them in linux-kernel
history) have to be represented as a set of two-parent merges.
--
Jakub Narebski
http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
^ permalink raw reply
* Re: git vs hg commit counts?
From: Marti Raudsepp @ 2009-10-27 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joe Perches, LKML, git, mercurial
In-Reply-To: <7v8wexd6zq.fsf@alter.siamese.dyndns.org>
On Tue, Oct 27, 2009 at 2:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> We simplify a merge history by discarding one branch when the merge result
> matches one of the parents. Does "hg" know how to do that as well?
57 of the differing changesets are normal merges (probably what Junio explained)
3 are duplicate changesets in hg, probably also related to that
27 changesets are octopus merge fixups
wrt octopus merges: in git, one merge commit can have an arbitrary
number of parents, but in hg a merge changeset always has 2 parents --
so a octopus merge is represented as multiple distinct changesets.
Marti
^ permalink raw reply
* Re: [PATCH] push: support remote branches in guess_ref DWIM
From: Jeff King @ 2009-10-27 1:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wexn34i.fsf@alter.siamese.dyndns.org>
On Mon, Oct 26, 2009 at 04:31:57PM -0700, Junio C Hamano wrote:
> As _our_ origin can never be _their_ origin if we are clone of them, I do
> not think anybody sane would expect it to push into refs/remotes/origin/
> to begin with.
OK, I agree.
> But "not in refs/remotes/" does not automatically mean "the only sensible
> place is refs/heads", does it? "We do not know what kind of mistake the
> user is trying to make" could be more plausible answer, and in that case,
> "complain and die" may be a more valid course of action.
The thing is that I can't think of another sensible place. And this
sensible place is useful for one particular action: renaming a remote
branch, like this:
$ git fetch ;# presumably gets origin/branch
$ git push origin/branch:renamed-branch
which is much nicer than exposing clueless users to
":refs/heads/renamed-branch".
> For example,
>
> git push origin origin/master:refs/heads/master
>
> is most likely to be a mistake. The only situation something similar to
> this makes sense is where you pushed out a bogus commit earlier and are
> trying to correct it perhaps with
I'm not sure why it's likely to be a mistake. I've given the one use
case I can think of where you _do_ want to do it. But I'm not sure why
you would accidentally provide something in refs/remotes, or not want to
be pushing to refs/heads. Where _else_ do you push, except for tags?
Am I missing some part of your argument?
> > A related issue (which exists even without this patch) is that doing
> > this:
> >
> > master:remotes/incoming/master
> >
> > will create "refs/heads/remotes/incoming/master". Perhaps we should DWYM
> > a little more and recognize "heads", "remotes", and "tags" as special.
>
> Yes, it is an independent issue; I think correcting this DWIM (or at least
> "warning" if not refusing to create remotes/ under refs/heads/) might be a
> good idea.
OK, I'll try to work up a patch.
-Peff
^ permalink raw reply
* Re: Problems with git am
From: alan @ 2009-10-27 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdi1bqv8.fsf@alter.siamese.dyndns.org>
On Mon, 26 Oct 2009, Junio C Hamano wrote:
> "Alan" <alan@clueserver.org> writes:
>
>> The header of the patch looks like:
>>
>> commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
>> Author: Joe Example <joe@example.com>
>> Date: Wed Sep 19 10:03:47 2009 -0600
>
> It shouldn't.
>
> The format "git am" understands is a mbox file and format-patch is the
> command to write commits out in that form. It should begin with lines
> that look like:
>
> From 610f99ec7d22b5750f12350f67c1341d6be8030f Mon Sep 17 00:00:00 2001
> From: Junio C Hamano <gitster@pobox.com>
> Date: Sun, 25 Oct 2009 18:41:09 -0700
> Subject: [PATCH] Update draft release notes to 1.6.6
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> .... patch follows here ...
>
> I do not think it is particularly hard to add a new case arm in "am" to
> support "git log" output. It is different from a mbox format in that it
>
> * begins each commit with "commit " marker;
> * has Author: and Date: header that is different from a mailbox;
> * lacks Subject: but makes it part of the message body; and
> * indents the message by 4 places.
>
> Nobody has bothered to do so, probably because nobody needed it.
[Insert long string of profanity cut and pasted from Linus' description of
CVS and Subversion.]
> The easiest, safest and quickest for you right now (meaning, before
> waiting for anybody to help you by adding a new feature to "am") would be
> to see if it is possible for you to get the commits re-exported in an
> appropriate format.
I can get them reexported. I may have problems getting them to do that
correctly on a regular basis...
I may have to write the am branch myself.
> I say the "safest" in the above because you _could_ massage what you have
> into a format that looks like a mbox with some Perl script, but it risks
> mismassaging.
Yeah.
The other question is what the proper behaviour when git-am in unable to
process a patch. Under git 1.6.0, it exits with a non-zero error code.
Under the current git in the git repo it issues and error and exits with a
non-error exit code.
What should the correct behaviour be in this case?
--
Truth is stranger than fiction because fiction has to make sense.
^ permalink raw reply
* [PATCH] Prevent git-remote-cvs from segfaulting
From: Sverre Rabbelier @ 2009-10-27 1:43 UTC (permalink / raw)
To: Git List, Junio C Hamano, Jeff King, Daniel Barkalow,
Shawn O. Pearce
Cc: Sverre Rabbelier
In [0] Shawn identified what caused git-remote-cvs from segfaulting,
which should be fixed as desribed in Daniel's reply to that [1].
In the meanwhile, the current patch fixes the issue until Daniel
submits a patch to fix it properly.
[0] http://thread.gmane.org/gmane.comp.version-control.git/130357/focus=130421
[1] http://thread.gmane.org/gmane.comp.version-control.git/130357/focus=131021
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Not-Signed-off-by: Jeff King <peff@peff.net>
---
Jeff wrote this total hack but wants no credit, responsibility or
anything else to do with it whatsoever.
I think it might be nice to have this on top of pu until Daniel
submits a proper patch, so that until that time the test suite
does not segfault.
transport-helper.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 410aa49..d867abb 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -68,6 +68,8 @@ static struct child_process *get_helper(struct transport *transport)
static int disconnect_helper(struct transport *transport)
{
struct helper_data *data = transport->data;
+ if(!data)
+ return 0;
if (data->helper) {
write_str_in_full(data->helper->in, "\n");
close(data->helper->in);
@@ -78,6 +80,7 @@ static int disconnect_helper(struct transport *transport)
free(data->helper);
data->helper = NULL;
}
+ transport->data = NULL;
free(data);
return 0;
}
--
1.6.5.1.125.g76b2.dirty
^ permalink raw reply related
* Re: Problems with git am
From: Junio C Hamano @ 2009-10-27 2:31 UTC (permalink / raw)
To: alan; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0910261836570.15106@blackbox.fnordora.org>
alan <alan@clueserver.org> writes:
> The other question is what the proper behaviour when git-am in unable
> to process a patch. Under git 1.6.0, it exits with a non-zero error
> code. Under the current git in the git repo it issues and error and
> exits with a non-error exit code.
Hmph, that sounds like a recent regression to me. I'll try to find time
to look into it myself sometime tonight but no promises.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Stephen Boyd @ 2009-10-27 2:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Clemens Buchacher, Sverre Rabbelier
In-Reply-To: <7vocntd7vt.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> If we are going to do this, wouldn't it make more sense to revert the
> rename of the script, so that people can keep relying on the name of the
> script being "git-completion.bash", _but_ make it produce a pre-compiled
> form to a separate file when invoked in some particular way?
Wouldn't relying on "git-completion.bash" to produce the pre-compiled
form cause problems if someone is running the build on a bash-less
system? I thought this issue was already raised by Shawn.
I guess we could ignore that issue now, and just say that you have to
build the pre-compiled form on systems with bash?
>
> Then at the runtime:
>
> (0) If the script notices that it has already learned the command list
> it uses it; otherwise,
>
> (1) If the script notices that there is a file that contains the command
> list, it sources it; otherwise,
>
> (2) The script lazily builds the command list for its own use.
>
> And at the buildtime, Makefile can run the script in "generation mode",
> and install the output to where (1) above expects to see.
I assume you're suggesting this to ease the upgrade path for users. It
works nicely, we could just install the generated lists in the same path
(contrib/completion/) and then users would be free to copy the two files
anywhere as long as they're in the same directory. The only downside I
see is there's now two files, but that's ok with me.
^ permalink raw reply
* Re: git-svn: add support for merges during 'git svn fetch'
From: Nanako Shiraishi @ 2009-10-27 3:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, Sam Vilain, git
In-Reply-To: <20091020211637.GA32474@dcvr.yhbt.net>
Quoting Eric Wong <normalperson@yhbt.net>
> Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
>> This series adds support for converting SVN merges - in the two
>> popular formats, SVK and SVN 1.5+, into git parents.
>
> Thanks Sam,
>
> There's a couple of whitespace issues with lines being too long (using 8
> character wide tabs). Otherwise I'm happy to Ack and get them out for
> more testing/exposure; especially since I'm unlikely to exercise the
> functionality myself[1] and doesn't appear to break anything.
>
> Thanks again.
What is the status of this series and what should happen now?
Will Eric add his Ack and send you a pull request, or will you fix
them up, forge Eric's Ack and start cooking in your 'next' branch?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nanako Shiraishi @ 2009-10-27 3:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sean Estabrooks, Nicolas Pitre, Jeff King, Junio C Hamano,
Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910262317430.4985@pacific.mpi-cbg.de>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>
> On Sat, 17 Oct 2009, Sean Estabrooks wrote:
>
>> On Fri, 16 Oct 2009 04:07:23 +0200 (CEST)
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>> > Just recently, I had a user request (a very valid one, mind you) where
>> > the user does not want to provide a commit message, and wants to just
>> > commit all the current changes. In that particular case, it is very
>> > sensible to ask for these things. It is something utterly simple to
>> > ask for. Yet, it is utterly hard with Git, especially if I have to
>> > explain it.
>>
>> Hey Johannes,
>>
>> It's actually easy, but maybe hard to find:
>>
>> $ git commit --cleanup=verbatim -m ""
>
> Of course that leaves out the main part. But it is simple once you
> know it (I did not): git add -A (we even went out of our way _not_ to name
> the long option --addremove, but --all -- it does not seem to be an
> expressive-enough option name to me, but what does my impression
> matter...)
>
> So I retract my claim that it is utterly hard to do with Git (but not the
> rest).
Last week, Junio gave this comment to your message.
> I suspect the above is another example of your needing to do
> a better job explaining yourself here, but from "just commit
> all the changes without saying message", my knee-jerk
> reaction is "git commit -a -m 'no message'".
> You would need to justify why -m 'no message' does not fit
> the bill better than just saying "is very sensible to ask for
> these things", as I highly suspect that I misunderstood what
> "these things" are in your five lines to come up with that
> "solution" that you are now going to explain why that is not
> what the end user wanted. And in this case, I do not think
> it is that me being disconnected from the real world, but
> that your explanation is insufficient.
I'm also curious about the situation when a commit with no message
is useful, but unfortunately I don't think I saw you explained
clearly enough what this user request wanted to achieve or what
"these things" in your message were for us to understand why it is
a sensible and valid thing to ask. Did I miss some messages in the
thread?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH] Fix resource leaks in wrapper.c
From: Laszlo Papp @ 2009-10-27 3:53 UTC (permalink / raw)
To: git; +Cc: Laszlo Papp
Fix the following issues with the desired close tags:
[wrapper.c:276]: (error) Resource leak: fd
[wrapper.c:291]: (error) Resource leak: fd
Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
---
wrapper.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/wrapper.c b/wrapper.c
index c9be140..76ecf0a 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -266,7 +266,7 @@ int odb_mkstemp(char *template, size_t limit, const char *pattern)
fd = mkstemp(template);
if (0 <= fd)
return fd;
-
+ close(fd);
/* slow path */
/* some mkstemp implementations erase template on failure */
snprintf(template, limit, "%s/%s",
@@ -284,7 +284,7 @@ int odb_pack_keep(char *name, size_t namesz, unsigned char *sha1)
fd = open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
if (0 <= fd)
return fd;
-
+ close(fd);
/* slow path */
safe_create_leading_directories(name);
return open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
--
1.6.5
^ permalink raw reply related
* Re: git vs hg commit counts?
From: Joe Perches @ 2009-10-27 4:14 UTC (permalink / raw)
To: Marti Raudsepp; +Cc: Junio C Hamano, LKML, git, mercurial
In-Reply-To: <54b33ccd0910261816x3c49d4ccr60a80a88dd4cfac9@mail.gmail.com>
On Tue, 2009-10-27 at 03:16 +0200, Marti Raudsepp wrote:
> On Tue, Oct 27, 2009 at 2:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > We simplify a merge history by discarding one branch when the merge result
> > matches one of the parents. Does "hg" know how to do that as well?
>
> 57 of the differing changesets are normal merges (probably what Junio explained)
> 3 are duplicate changesets in hg, probably also related to that
> 27 changesets are octopus merge fixups
>
> wrt octopus merges: in git, one merge commit can have an arbitrary
> number of parents, but in hg a merge changeset always has 2 parents --
> so a octopus merge is represented as multiple distinct changesets.
Thanks.
For hg support in get_maintainers, it's probably
simplest to ignore the delta in number of commits
as "close enough".
^ permalink raw reply
* Re: gti push interface inconsistency
From: Eugene Sajine @ 2009-10-27 4:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiopd7gs.fsf@alter.siamese.dyndns.org>
>
> Probably because git is not smart enough to understand the human language
> to notice 't' 'a' 'g' is a tag and cannot be a remote name spelled
> incorrectly, or git cannot read your mind and find out that you spelled
> a name of the remote correctly but forgot to add the remote first.
>
;)
did you mean It is not smart enough yet?
My question was caused only by the fact that in both situations same
object type is transmitted to the origin repo. As understand that it
was done this way in order to avoid specifying keys for remote...
I.e. "git push origin master" is kinda easier then something like "git
push -r origin master" (-r for remote).
But if for "git push --tags" the remote is not important (uses origin
by default) why it is important for "git push my_tag" or for "git push
origin master"?
Do you think
$ git push master
Which would default to origin have a chance to exist? (I would vote for this)
Or the correct aproach is to have
$ git push origin --tags
IMHO, In any case the push operation interface should be consistent.
Else it is a bit confusing (untill you didn't step on it and didn't
learn the difference).
Best regards,
Eugene
^ permalink raw reply
* [PATCH] Fix memory leak in transport-helper
From: Daniel Barkalow @ 2009-10-27 4:55 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Johan Herland, Nanako Shiraishi, Sverre Rabbelier,
git
In-Reply-To: <20091015204543.GP10505@spearce.org>
On Thu, 15 Oct 2009, Shawn O. Pearce wrote:
> The disconnect_helper function is not prepared to be called twice:
>
> static int disconnect_helper(struct transport *transport)
> {
> struct helper_data *data = transport->data;
> if (data->helper) {
> ...
> }
> free(data);
> return 0;
> }
Actually, my version just leaks transport->data; it looks like the
"free(data);" line comes from your patch "remote-helpers: Support custom
transport options". Here's a version (against origin/master) that neither
leaks memory nor frees too much for disconnecting temporarily.
commit 8731d804c20828d20130e286f088613b5d33d57a
Author: Daniel Barkalow <barkalow@iabervon.org>
Date: Tue Oct 27 00:42:16 2009 -0400
Fix memory leak in helper method for disconnect.
Since some cases may need to disconnect from the helper and reconnect,
wrap the function that just disconnects in a function that also frees
transport->data.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
diff --git a/transport-helper.c b/transport-helper.c
index f57e84c..479539d 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -67,6 +67,13 @@ static int disconnect_helper(struct transport *transport)
return 0;
}
+static int close_helper(struct transport *transport)
+{
+ disconnect_helper(transport);
+ free(transport->data);
+ return 0;
+}
+
static int fetch_with_fetch(struct transport *transport,
int nr_heads, const struct ref **to_fetch)
{
@@ -163,6 +170,6 @@ int transport_helper_init(struct transport *transport, const char *name)
transport->data = data;
transport->get_refs_list = get_refs_list;
transport->fetch = fetch;
- transport->disconnect = disconnect_helper;
+ transport->disconnect = close_helper;
return 0;
}
^ permalink raw reply related
* Re: [PATCH ef/msys-imap] mingw: use BLK_SHA1 again
From: Johannes Sixt @ 2009-10-27 6:56 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano
Cc: msysgit, git, Erik Faye-Lund, Junio C Hamano, Marius Storm-Olsen
In-Reply-To: <alpine.DEB.1.00.0910262324350.4985@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> For better visibility, I pushed it to the work/msys-imap branch in
> 4msysgit.git (but I could not even compile-test it today, due to lack of
> access to a Windows machine).
>
> If nobody complains by the end of the week, I will merge it into
> 4msysgit.git's 'devel' branch (I can only compile-test by then).
Ugh, I totally forgot: I have this branch ready for Junio to pull:
git://repo.or.cz/git/mingw/j6t.git ef/imap-send-windows
Only the top 3 commits are different from what is currently in pu: I added
my ACK, and reworded the commit message of my patch that is at the tip.
Content-wise it is identical to the series in pu.
I haven't seen an ACK from Marius regarding the changes that touch MSVC
parts, but there was plenty of time to test, and the changes look obvious
enough.
Junio, please pull.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fix resource leaks in wrapper.c
From: Johannes Sixt @ 2009-10-27 7:13 UTC (permalink / raw)
To: Laszlo Papp; +Cc: git, Laszlo Papp
In-Reply-To: <1256615635-4940-1-git-send-email-djszapi@archlinux.us>
Laszlo Papp schrieb:
> @@ -266,7 +266,7 @@ int odb_mkstemp(char *template, size_t limit, const char *pattern)
> fd = mkstemp(template);
> if (0 <= fd)
> return fd;
> -
> + close(fd);
Sorry, where is here a resource leak? You are "closing" something that was
never opened because fd is less than zero.
Ditto for the other case.
-- Hannes
^ 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