Git development
 help / color / mirror / Atom feed
* 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

* Re: git-svn: add support for merges during 'git svn fetch'
From: Eric Wong @ 2009-10-27  7:14 UTC (permalink / raw)
  To: Nanako Shiraishi; +Cc: Junio C Hamano, Sam Vilain, git
In-Reply-To: <20091027124056.6117@nanako3.lavabit.com>

Nanako Shiraishi <nanako3@lavabit.com> wrote:
> 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?

Thanks for the ping, I got sidetracked and forgot about this.  I've
fixed up minor formatting details, acked and pushed out Sam's changes to
git://git.bogomips.org/git-svn along with one I small fix I originally
sent out a bad patch for.

Eric Wong (1):
      git svn: fix fetch where glob is on the top-level URL

Sam Vilain (5):
      git-svn: add test data for SVK merge, with script.
      git-svn: allow test setup script to support PERL env. var
      git-svn: convert SVK merge tickets to extra parents
      git-svn: add test data for SVN 1.5+ merge, with script.
      git-svn: convert SVN 1.5+ / svnmerge.py svn:mergeinfo props to parents

(tests pass on the same box where I have my latest code this time :)

-- 
Eric Wong

^ permalink raw reply

* Re: [PATCH] Fix resource leaks in wrapper.c
From: Michael J Gruber @ 2009-10-27  8:26 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: Laszlo Papp, git, Laszlo Papp
In-Reply-To: <4AE69DA7.6030704@viscovery.net>

Johannes Sixt venit, vidit, dixit 27.10.2009 08:13:
> 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.

I guess it's about silencing some challenged code analysis tool. I
recall that last time we had something like this we decided that coders
are smarter than tools... and also that clean up like this (for real
leaks) would be something for libgit.

Michael

^ permalink raw reply

* Re: git update --prune issue
From: Michael J Gruber @ 2009-10-27  8:42 UTC (permalink / raw)
  To: Jeffrey Middleton; +Cc: git
In-Reply-To: <4389ce950910261508p7eca354el77bad07305a80952@mail.gmail.com>

Jeffrey Middleton venit, vidit, dixit 26.10.2009 23:08:
> I have an unreliable problem when using "git remote update --prune".
> git claims that many refs from a particular remote do not point to a
> valid object, but only after finishing another update.  I've included
> a shortened version of the output from one particular instance of the
> issue.  Note that the errors are printed for every subsequent remote
> as well.  However, after the update is completed, everything is fine.
> 
> It seems to only happen when there are non-fast-forward changes (new
> branch, forced update, pruned branch).  The issue only happens with
> this particular remote, which I've tried removing and recreating, and
> is the same type of remote as all my others (another user's
> NFS-mounted home directory).  However, my remotes are all individual
> developers, and this developer is the only one who ever rebases her
> working branches.  (recloning the repo from origin and setting up my
> config and remotes all over again has also had no effect)
> 
> Unfortunately, I have been unable to reproduce the problem in any test
> repos - for example, though a forced update and a pruned branch in the
> problematic remote along with an update in another remote seems to
> fairly reliably produce the problem in this repo, recreating that
> situation in another repo doesn't cause any problems.  Sorry for the
> incomplete bug report, but perhaps this will be enough to go on!
> 
> Thanks,
> Jeffrey
> 
> 
> I've seen the issue in previous versions built from git.git master, as
> well as v1.6.3.3, but for this particular one:
> 
> $ git --version
> git version 1.6.5.1.61.ge79999
> 
> $ git remote update --prune
> Updating origin
> remote: Counting objects: 42, done.
> remote: Compressing objects: 100% (9/9), done.
> remote: Total 15 (delta 9), reused 12 (delta 6)
> Unpacking objects: 100% (15/15), done.
> From /users/cxtfcm/CxTF_DB
>    88b8613..d40f26d  2009.Q4    -> origin/2009.Q4
>    d40f26d..56305b8  dev        -> origin/dev
> Updating steph
> remote: Counting objects: 299, done.
> remote: Compressing objects: 100% (241/241), done.
> remote: Total 276 (delta 186), reused 19 (delta 6)
> Receiving objects: 100% (276/276), 41.09 KiB | 10 KiB/s, done.
> Resolving deltas: 100% (186/186), completed with 17 local objects.
> From /users/sdewet/CxTF_DEV/CxTF_DB
>  + c2439dd...69cb5c3 beta_gc_dev -> steph/beta_gc_dev  (forced update)
>  + fb25173...f0e4963 beta_veh_dev -> steph/beta_veh_dev  (forced update)
>  * [new branch]      beta_veh_dev_old -> steph/beta_veh_dev_old
> Pruning steph
> URL: /users/sdewet/CxTF_DEV/CxTF_DB/
>  * [pruned] steph/beta_gc_dev_old
> Updating kevin
> error: refs/remotes/steph/beta_gc_dev does not point to a valid object!
> error: refs/remotes/steph/beta_veh_dev does not point to a valid object!
> Updating jose
> error: refs/remotes/steph/beta_gc_dev does not point to a valid object!
> error: refs/remotes/steph/beta_veh_dev does not point to a valid object!
> ### many more remotes with the same errors ###

Do you get the same problem if you do the steps individually, i.e.:

git remote update steph
git remote prune steph
git remote update kevin

Does it depend on the order, i.e.:

git remote update steph
git remote update kevin
git remote prune steph

Does "git fsck --full" say anything special?

Michael

^ permalink raw reply

* more fancy ignoring of files ('if' in .gitignore?)
From: Sebastian Schubert @ 2009-10-27  9:30 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

Hi,

I would like to ignore files if certain other files are present. In my 
special case, I want to ignore foo.pdf and foo.eps if foo.fig is 
present (both pdf and eps are generated on the fly but don't belong 
into repository). In general, I do NOT want to ignore pdf or eps. There 
are a lot of foos so I would like to have a general solution.

Is this possible?

Cheers
Sebastian

PS: Please CC my personal email address.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: date change of commit?
From: Alex K @ 2009-10-27  9:41 UTC (permalink / raw)
  To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq1vkrqttt.fsf@bauges.imag.fr>

Thank you. And how would you use git-filter-branch to create another
branch with a different time stamp? Is it possible to commit under a
different time stamp than the one provided by your default local time?

2009/10/25 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Alex K <spaceoutlet@gmail.com> writes:
>
>> Hello,
>>
>> Is it possible to change the date of a commit?
>
> See git-filter-branch. This won't change the date of the existing
> commit (which is impossible in Git), but will create another commit
> where only the date has been changed.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox