* Re: [PATCH] Documentation: git-format-patch.txt rewordings and cleanups
From: Stephen Boyd @ 2009-03-24 23:36 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20090324220913.GN19389@fieldses.org>
On Tue, Mar 24, 2009 at 3:09 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Mon, Mar 23, 2009 at 03:21:23AM -0700, Stephen Boyd wrote:
>> +
>> -Note that you would need to include the leading dot `.` if you
>> -want a filename like `0001-description-of-my-change.patch`, and
>> -the first letter does not have to be a dot. Leaving it empty would
>> -not add any suffix.
>> +Note the first letter is not required to be a dot, you will need to
>> +include the leading dot `.` if you want a filename like
>> +`0001-description-of-my-change.patch`.
>
> That's a comma-splice, trivially fixed by changing "dot, you" to "dot;
> you".
>
> Better?: "Note that the leading dot isn't actually required if you don't
> want a dot between the patch name and the suffix."
>
> (Though personally I'd strike the whole sentence, since a) probably
> nobody cares, and b) the 1 in a million person that does actually want
> to do this can figure it out easily enough on their own with a quick
> test.)
>
> --b.
>
I don't think documentation is meant to point the user to trial and
error. Even if the error is fairly harmless. Although you could be
right that nobody cares.
How about a sentence with no negation?
"Note that the leading dot is required if you want a dot between the
patch name and the suffix."
^ permalink raw reply
* [PATCH] Don't permit ref/branch names to end with ".lock"
From: Shawn O. Pearce @ 2009-03-24 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
We already skip over loose refs under $GIT_DIR/refs if the name
ends with ".lock", so creating a branch named "foo.lock" will not
appear in the output of "git branch", "git for-each-ref", nor will
its commit be considered reachable by "git rev-list --all".
In the latter case this is especially evil, as it may cause
repository corruption when objects reachable only through such a
ref are deleted by "git prune".
It should be reasonably safe to deny use of ".lock" as a ref suffix.
In prior versions of Git such branches would be "phantom branches";
you can create it, but you can't see it in "git branch" output.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This goes on top of your jc/name-branch-iffy currently in pu.
Documentation/git-check-ref-format.txt | 2 ++
refs.c | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index d23fd21..9b707a7 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -34,6 +34,8 @@ imposes the following rules on how refs are named:
. They cannot end with a slash `/` nor a dot `.`.
+. They cannot end with the sequence `.lock`.
+
. They cannot contain a sequence `@{`.
These rules makes it easy for shell script based tools to parse
diff --git a/refs.c b/refs.c
index e355489..f3fdcbd 100644
--- a/refs.c
+++ b/refs.c
@@ -676,6 +676,7 @@ int for_each_rawref(each_ref_fn fn, void *cb_data)
* - it has double dots "..", or
* - it has ASCII control character, "~", "^", ":" or SP, anywhere, or
* - it ends with a "/".
+ * - it ends with ".lock"
*/
static inline int bad_ref_char(int ch)
@@ -737,6 +738,8 @@ int check_ref_format(const char *ref)
return CHECK_REF_FORMAT_ERROR;
if (level < 2)
return CHECK_REF_FORMAT_ONELEVEL;
+ if (has_extension(ref, ".lock"))
+ return CHECK_REF_FORMAT_ERROR;
return ret;
}
}
--
1.6.2.1.471.g682837
^ permalink raw reply related
* Re: [PATCH v4 1/2] git-gui: various French translation fixes
From: Shawn O. Pearce @ 2009-03-24 23:19 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git, Christian Couder, Nicolas Sebrecht
In-Reply-To: <20090324231538.GA14967@zoy.org>
Sam Hocevar <sam@zoy.org> wrote:
> Mostly grammar, spelling and typography fixes, but also a few wording
> enhancements here and there.
>
> Signed-off-by: Sam Hocevar <sam@zoy.org>
> ---
> Re-sending using one UTF-8 character (???) so that Mutt does not
> try to use iso8859-1.
Thanks, that worked. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH v3 2/2] git-gui: minor spelling fix and string factorisation.
From: Shawn O. Pearce @ 2009-03-24 23:19 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Git List
In-Reply-To: <20090323234224.GA29986@zoy.org>
Sam Hocevar <sam@zoy.org> wrote:
> Properly spell "successful" and slightly rewrite a couple of strings
> that actually say the same thing in order to reduce translation work.
>
> Update .pot and .po files accordingly since no new translation is
> required.
> ---
> This patch is unchanged since the last version.
Thanks, applied.
--
Shawn.
^ permalink raw reply
* [PATCH v4 2/2] git-gui: minor spelling fix and string factorisation.
From: Sam Hocevar @ 2009-03-24 23:19 UTC (permalink / raw)
To: Git List; +Cc: spearce
In-Reply-To: <20090324230238.GQ23521@spearce.org>
Properly spell "successful" and slightly rewrite a couple of strings
that actually say the same thing in order to reduce translation work.
Update .pot and .po files accordingly since no new translation is
required.
Signed-off-by: Sam Hocevar <sam@zoy.org>
---
▁▂▃▄▅▆▇█
lib/branch_delete.tcl | 4 ++--
lib/remote_branch_delete.tcl | 4 +---
lib/tools.tcl | 2 +-
po/de.po | 12 +-----------
po/fr.po | 12 +-----------
po/git-gui.pot | 9 +--------
po/hu.po | 12 +-----------
po/it.po | 12 +-----------
po/ja.po | 12 +-----------
po/nb.po | 12 +-----------
po/ru.po | 10 ----------
po/sv.po | 12 +-----------
po/zh_cn.po | 10 ----------
13 files changed, 12 insertions(+), 111 deletions(-)
diff --git a/lib/branch_delete.tcl b/lib/branch_delete.tcl
index ef1930b..20d5e42 100644
--- a/lib/branch_delete.tcl
+++ b/lib/branch_delete.tcl
@@ -51,7 +51,7 @@ constructor dialog {} {
$w.check \
[mc "Delete Only If Merged Into"] \
]
- $w_check none [mc "Always (Do not perform merge test.)"]
+ $w_check none [mc "Always (Do not perform merge checks)"]
pack $w.check -anchor nw -fill x -pady 5 -padx 5
foreach h [load_all_heads] {
@@ -112,7 +112,7 @@ method _delete {} {
}
if {$to_delete eq {}} return
if {$check_cmt eq {}} {
- set msg [mc "Recovering deleted branches is difficult. \n\n Delete the selected branches?"]
+ set msg [mc "Recovering deleted branches is difficult.\n\nDelete the selected branches?"]
if {[tk_messageBox \
-icon warning \
-type yesno \
diff --git a/lib/remote_branch_delete.tcl b/lib/remote_branch_delete.tcl
index 89eb0f7..4e02fc0 100644
--- a/lib/remote_branch_delete.tcl
+++ b/lib/remote_branch_delete.tcl
@@ -213,9 +213,7 @@ method _delete {} {
-type yesno \
-title [wm title $w] \
-parent $w \
- -message [mc "Recovering deleted branches is difficult.
-
-Delete the selected branches?"]] ne yes} {
+ -message [mc "Recovering deleted branches is difficult.\n\nDelete the selected branches?"]] ne yes} {
return
}
diff --git a/lib/tools.tcl b/lib/tools.tcl
index 6ae63b6..95e6e55 100644
--- a/lib/tools.tcl
+++ b/lib/tools.tcl
@@ -146,7 +146,7 @@ proc tools_complete {fullname w {ok 1}} {
}
if {$ok} {
- set msg [mc "Tool completed succesfully: %s" $fullname]
+ set msg [mc "Tool completed successfully: %s" $fullname]
} else {
set msg [mc "Tool failed: %s" $fullname]
}
diff --git a/po/de.po b/po/de.po
index a6f730b..51abb50 100644
--- a/po/de.po
+++ b/po/de.po
@@ -773,16 +773,6 @@ msgstr "Immer (ohne Zusammenführungstest)"
msgid "The following branches are not completely merged into %s:"
msgstr "Folgende Zweige sind noch nicht mit »%s« zusammengeführt:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Gelöschte Zweige können nur mit größerem Aufwand wiederhergestellt werden.\n"
-"\n"
-"Gewählte Zweige jetzt löschen?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2506,7 +2496,7 @@ msgstr "Starten: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Werkzeug erfolgreich abgeschlossen: %s"
#: lib/tools.tcl:151
diff --git a/po/fr.po b/po/fr.po
index e6bf1b4..9b828a2 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -780,16 +780,6 @@ msgstr "Toujours (Ne pas faire de test de fusion.)"
msgid "The following branches are not completely merged into %s:"
msgstr "Les branches suivantes ne sont pas complètement fusionnées dans %s :"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Il est difficile de récupérer des branches supprimées.\n"
-"\n"
-"Supprimer les branches sélectionnées ?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2412,7 +2402,7 @@ msgstr "Lancement de : %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "L'outil a terminé avec succès : %s"
#: lib/tools.tcl:151
diff --git a/po/git-gui.pot b/po/git-gui.pot
index 15aea0d..53b7d36 100644
--- a/po/git-gui.pot
+++ b/po/git-gui.pot
@@ -753,13 +753,6 @@ msgstr ""
msgid "The following branches are not completely merged into %s:"
msgstr ""
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2220,7 +2213,7 @@ msgstr ""
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr ""
#: lib/tools.tcl:151
diff --git a/po/hu.po b/po/hu.po
index f761b64..0f87bc1 100644
--- a/po/hu.po
+++ b/po/hu.po
@@ -776,16 +776,6 @@ msgstr "Mindig (Ne legyen merge teszt.)"
msgid "The following branches are not completely merged into %s:"
msgstr "A következő branchek nem teljesen lettek merge-ölve ebbe: %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"A törölt branchek visszaállítása bonyolult. \n"
-"\n"
-" Biztosan törli a kiválasztott brancheket?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2399,7 +2389,7 @@ msgstr "Futtatás: %s..."
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Az eszköz sikeresen befejeződött: %s"
#: lib/tools.tcl:151
diff --git a/po/it.po b/po/it.po
index 294e595..762632c 100644
--- a/po/it.po
+++ b/po/it.po
@@ -778,16 +778,6 @@ msgstr "Sempre (Non effettuare verifiche di fusione)."
msgid "The following branches are not completely merged into %s:"
msgstr "I rami seguenti non sono stati fusi completamente in %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Ricomporre rami cancellati può essere complicato. \n"
-"\n"
-" Eliminare i rami selezionati?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2418,7 +2408,7 @@ msgstr "Eseguo: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Il programma esterno è terminato con successo: %s"
#: lib/tools.tcl:151
diff --git a/po/ja.po b/po/ja.po
index 09d60be..63c4695 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -773,16 +773,6 @@ msgstr "無条件(マージテストしない)"
msgid "The following branches are not completely merged into %s:"
msgstr "以下のブランチは %s に完全にマージされていません:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"ブランチを削除すると元に戻すのは困難です。 \n"
-"\n"
-" 選択したブランチを削除しますか？"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2382,7 +2372,7 @@ msgstr "実行中: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "ツールが完了しました: %s"
#: lib/tools.tcl:151
diff --git a/po/nb.po b/po/nb.po
index 1c5137d..6de93c2 100644
--- a/po/nb.po
+++ b/po/nb.po
@@ -761,16 +761,6 @@ msgstr "Alltid (Ikke utfør sammenslåingstest.)"
msgid "The following branches are not completely merged into %s:"
msgstr "Følgende grener er ikke fullstendig slått sammen med %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Gjenoppretting av fjernede grener er vanskelig. \n"
-"\n"
-" Fjern valgte grener?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2331,7 +2321,7 @@ msgstr "Kjører: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Verktøyet ble fullført med suksess: %s"
#: lib/tools.tcl:151
diff --git a/po/ru.po b/po/ru.po
index db55b3e..04df2aa 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -661,16 +661,6 @@ msgstr "Всегда (не выполнять проверку на объеди
msgid "The following branches are not completely merged into %s:"
msgstr "Следующие ветви объединены с %s не полностью:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Восстанавливать удаленные ветви сложно. \n"
-"\n"
-" Удалить выбранные ветви?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
diff --git a/po/sv.po b/po/sv.po
index 167654c..c1535f9 100644
--- a/po/sv.po
+++ b/po/sv.po
@@ -780,16 +780,6 @@ msgstr "Alltid (utför inte sammanslagningstest)."
msgid "The following branches are not completely merged into %s:"
msgstr "Följande grenar är inte till fullo sammanslagna med %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"Det är svårt att återställa borttagna grenar.\n"
-"\n"
-" Ta bort valda grenar?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
@@ -2398,7 +2388,7 @@ msgstr "Exekverar: %s"
#: lib/tools.tcl:149
#, tcl-format
-msgid "Tool completed succesfully: %s"
+msgid "Tool completed successfully: %s"
msgstr "Verktyget avslutades framgångsrikt: %s"
#: lib/tools.tcl:151
diff --git a/po/zh_cn.po b/po/zh_cn.po
index d2c6866..91c1be2 100644
--- a/po/zh_cn.po
+++ b/po/zh_cn.po
@@ -676,16 +676,6 @@ msgstr "总是合并 (不作合并测试.)"
msgid "The following branches are not completely merged into %s:"
msgstr "下列分支没有完全被合并到 %s:"
-#: lib/branch_delete.tcl:115
-msgid ""
-"Recovering deleted branches is difficult. \n"
-"\n"
-" Delete the selected branches?"
-msgstr ""
-"恢复被删除的分支非常困难.\n"
-"\n"
-"是否要删除所选分支?"
-
#: lib/branch_delete.tcl:141
#, tcl-format
msgid ""
--
1.6.2.1
^ permalink raw reply related
* [PATCH v4 1/2] git-gui: various French translation fixes
From: Sam Hocevar @ 2009-03-24 23:15 UTC (permalink / raw)
To: git, spearce; +Cc: Christian Couder, Nicolas Sebrecht
In-Reply-To: <20090324230238.GQ23521@spearce.org>
Mostly grammar, spelling and typography fixes, but also a few wording
enhancements here and there.
Signed-off-by: Sam Hocevar <sam@zoy.org>
---
Re-sending using one UTF-8 character (♥) so that Mutt does not
try to use iso8859-1.
po/fr.po | 202 +++++++++++++++++++++++++++++++-------------------------------
1 files changed, 101 insertions(+), 101 deletions(-)
diff --git a/po/fr.po b/po/fr.po
index 45773ab..e6bf1b4 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -62,7 +62,7 @@ msgstr ""
"\n"
"%s nécessite au moins Git 1.5.0.\n"
"\n"
-"Peut'on considérer que '%s' est en version 1.5.0 ?\n"
+"Peut-on considérer que '%s' est en version 1.5.0 ?\n"
#: git-gui.sh:1062
msgid "Git directory not found:"
@@ -82,7 +82,7 @@ msgstr "Aucun répertoire de travail"
#: git-gui.sh:1247 lib/checkout_op.tcl:305
msgid "Refreshing file status..."
-msgstr "Rafraichissement du status des fichiers..."
+msgstr "Rafraîchissement du statut des fichiers..."
#: git-gui.sh:1303
msgid "Scanning for modified files ..."
@@ -163,7 +163,7 @@ msgstr "Dépôt"
#: git-gui.sh:2281
msgid "Edit"
-msgstr "Edition"
+msgstr "Édition"
#: git-gui.sh:2283 lib/choose_rev.tcl:561
msgid "Branch"
@@ -199,7 +199,7 @@ msgstr "Naviguer dans la branche..."
#: git-gui.sh:2316
msgid "Visualize Current Branch's History"
-msgstr "Visualiser historique branche courante"
+msgstr "Visualiser l'historique de la branche courante"
#: git-gui.sh:2320
msgid "Visualize All Branch History"
@@ -208,12 +208,12 @@ msgstr "Voir l'historique de toutes les branches"
#: git-gui.sh:2327
#, tcl-format
msgid "Browse %s's Files"
-msgstr "Naviguer l'arborescence de %s"
+msgstr "Parcourir l'arborescence de %s"
#: git-gui.sh:2329
#, tcl-format
msgid "Visualize %s's History"
-msgstr "Voir l'historique de la branche: %s"
+msgstr "Voir l'historique de la branche : %s"
#: git-gui.sh:2334 lib/database.tcl:27 lib/database.tcl:67
msgid "Database Statistics"
@@ -230,7 +230,7 @@ msgstr "Vérifier le dépôt"
#: git-gui.sh:2347 git-gui.sh:2351 git-gui.sh:2355 lib/shortcut.tcl:7
#: lib/shortcut.tcl:39 lib/shortcut.tcl:71
msgid "Create Desktop Icon"
-msgstr "Créer icône sur bureau"
+msgstr "Créer une icône sur le bureau"
#: git-gui.sh:2363 lib/choose_repository.tcl:183 lib/choose_repository.tcl:191
msgid "Quit"
@@ -320,7 +320,7 @@ msgstr "Désindexer"
#: git-gui.sh:2484 lib/index.tcl:410
msgid "Revert Changes"
-msgstr "Annuler les modifications (revert)"
+msgstr "Annuler les modifications"
#: git-gui.sh:2491 git-gui.sh:3069
msgid "Show Less Context"
@@ -382,7 +382,7 @@ msgstr "Documentation en ligne"
#: git-gui.sh:2614 lib/choose_repository.tcl:47 lib/choose_repository.tcl:56
msgid "Show SSH Key"
-msgstr "Montrer clé SSH"
+msgstr "Montrer la clé SSH"
#: git-gui.sh:2707
#, tcl-format
@@ -445,7 +445,7 @@ msgstr "Fichier :"
#: git-gui.sh:3078
msgid "Refresh"
-msgstr "Rafraichir"
+msgstr "Rafraîchir"
#: git-gui.sh:3099
msgid "Decrease Font Size"
@@ -457,7 +457,7 @@ msgstr "Agrandir la police"
#: git-gui.sh:3111 lib/blame.tcl:281
msgid "Encoding"
-msgstr "Encodage"
+msgstr "Codage des caractères"
#: git-gui.sh:3122
msgid "Apply/Reverse Hunk"
@@ -469,7 +469,7 @@ msgstr "Appliquer/Inverser la ligne"
#: git-gui.sh:3137
msgid "Run Merge Tool"
-msgstr "Lancer outil de merge"
+msgstr "Lancer l'outil de fusion"
#: git-gui.sh:3142
msgid "Use Remote Version"
@@ -527,7 +527,7 @@ msgid ""
"Tcl binary distributed by Cygwin."
msgstr ""
"\n"
-"Ceci est du à un problème connu avec\n"
+"Ceci est dû à un problème connu avec\n"
"le binaire Tcl distribué par Cygwin."
#: git-gui.sh:3336
@@ -630,11 +630,11 @@ msgstr "Fichier original :"
#: lib/blame.tcl:1021
msgid "Cannot find HEAD commit:"
-msgstr "Impossible de trouver le commit HEAD:"
+msgstr "Impossible de trouver le commit HEAD :"
#: lib/blame.tcl:1076
msgid "Cannot find parent commit:"
-msgstr "Impossible de trouver le commit parent:"
+msgstr "Impossible de trouver le commit parent :"
#: lib/blame.tcl:1091
msgid "Unable to display parent"
@@ -646,7 +646,7 @@ msgstr "Erreur lors du chargement des différences :"
#: lib/blame.tcl:1232
msgid "Originally By:"
-msgstr "A l'origine par :"
+msgstr "À l'origine par :"
#: lib/blame.tcl:1238
msgid "In File:"
@@ -691,11 +691,11 @@ msgstr "Détacher de la branche locale"
#: lib/branch_create.tcl:22
msgid "Create Branch"
-msgstr "Créer branche"
+msgstr "Créer une branche"
#: lib/branch_create.tcl:27
msgid "Create New Branch"
-msgstr "Créer nouvelle branche"
+msgstr "Créer une nouvelle branche"
#: lib/branch_create.tcl:31 lib/choose_repository.tcl:377
msgid "Create"
@@ -719,7 +719,7 @@ msgstr "Révision initiale"
#: lib/branch_create.tcl:72
msgid "Update Existing Branch:"
-msgstr "Mettre à jour branche existante :"
+msgstr "Mettre à jour une branche existante :"
#: lib/branch_create.tcl:75
msgid "No"
@@ -727,7 +727,7 @@ msgstr "Non"
#: lib/branch_create.tcl:80
msgid "Fast Forward Only"
-msgstr "Mise-à-jour rectiligne seulement (fast-forward)"
+msgstr "Mise à jour rectiligne seulement (fast-forward)"
#: lib/branch_create.tcl:85 lib/checkout_op.tcl:536
msgid "Reset"
@@ -769,7 +769,7 @@ msgstr "Branches locales"
#: lib/branch_delete.tcl:52
msgid "Delete Only If Merged Into"
-msgstr "Supprimer seulement si fusionnée dans:"
+msgstr "Supprimer seulement si fusionnée dans :"
#: lib/branch_delete.tcl:54
msgid "Always (Do not perform merge test.)"
@@ -786,7 +786,7 @@ msgid ""
"\n"
" Delete the selected branches?"
msgstr ""
-"Récupérer des branches supprimées est difficile.\n"
+"Il est difficile de récupérer des branches supprimées.\n"
"\n"
"Supprimer les branches sélectionnées ?"
@@ -796,7 +796,7 @@ msgid ""
"Failed to delete branches:\n"
"%s"
msgstr ""
-"La suppression des branches suivantes a échouée :\n"
+"La suppression des branches suivantes a échoué :\n"
"%s"
#: lib/branch_rename.tcl:14 lib/branch_rename.tcl:22
@@ -902,11 +902,11 @@ msgstr "La stratégie de fusion '%s' n'est pas supportée."
#: lib/checkout_op.tcl:261
#, tcl-format
msgid "Failed to update '%s'."
-msgstr "La mise à jour de '%s' a échouée."
+msgstr "La mise à jour de '%s' a échoué."
#: lib/checkout_op.tcl:273
msgid "Staging area (index) is already locked."
-msgstr "L'index (staging area) est déjà vérouillé"
+msgstr "L'index (staging area) est déjà verrouillé."
#: lib/checkout_op.tcl:288
msgid ""
@@ -918,7 +918,7 @@ msgid ""
"The rescan will be automatically started now.\n"
msgstr ""
"L'état lors de la dernière synchronisation ne correspond plus à l'état du "
-"dépôt\n"
+"dépôt.\n"
"\n"
"Un autre programme Git a modifié ce dépôt depuis la dernière "
"synchronisation. Une resynchronisation doit être effectuée avant de pouvoir "
@@ -956,9 +956,9 @@ msgid ""
"If you wanted to be on a branch, create one now starting from 'This Detached "
"Checkout'."
msgstr ""
-"Vous n'êtes plus ur une branche locale.\n"
+"Vous n'êtes plus sur une branche locale.\n"
"\n"
-"Si vous vouliez être sur une branche, créez en une maintenant en partant de "
+"Si vous vouliez être sur une branche, créez-en une maintenant en partant de "
"'Cet emprunt détaché'."
#: lib/checkout_op.tcl:468 lib/checkout_op.tcl:472
@@ -1000,7 +1000,7 @@ msgstr ""
"mis à jour avec succès, mais la mise à jour d'un fichier interne à Git a "
"échouée.\n"
"\n"
-"Cela n'aurait pas du se produire. %s va abandonner et se terminer."
+"Cela n'aurait pas dû se produire. %s va abandonner et se terminer."
#: lib/choose_font.tcl:39
msgid "Select"
@@ -1023,8 +1023,8 @@ msgid ""
"This is example text.\n"
"If you like this text, it can be your font."
msgstr ""
-"C'est un texte d'exemple.\n"
-"Si vous aimez ce texte, vous pouvez choisir cette police"
+"Ceci est un texte d'exemple.\n"
+"Si vous aimez ce texte, vous pouvez choisir cette police."
#: lib/choose_repository.tcl:28
msgid "Git Gui"
@@ -1040,7 +1040,7 @@ msgstr "Nouveau..."
#: lib/choose_repository.tcl:100 lib/choose_repository.tcl:465
msgid "Clone Existing Repository"
-msgstr "Cloner dépôt existant"
+msgstr "Cloner un dépôt existant"
#: lib/choose_repository.tcl:106
msgid "Clone..."
@@ -1048,7 +1048,7 @@ msgstr "Cloner..."
#: lib/choose_repository.tcl:113 lib/choose_repository.tcl:983
msgid "Open Existing Repository"
-msgstr "Ouvrir dépôt existant"
+msgstr "Ouvrir un dépôt existant"
#: lib/choose_repository.tcl:119
msgid "Open..."
@@ -1056,17 +1056,17 @@ msgstr "Ouvrir..."
#: lib/choose_repository.tcl:132
msgid "Recent Repositories"
-msgstr "Dépôt récemment utilisés"
+msgstr "Dépôts récemment utilisés"
#: lib/choose_repository.tcl:138
msgid "Open Recent Repository:"
-msgstr "Ouvrir dépôt récent :"
+msgstr "Ouvrir un dépôt récent :"
#: lib/choose_repository.tcl:302 lib/choose_repository.tcl:309
#: lib/choose_repository.tcl:316
#, tcl-format
msgid "Failed to create repository %s:"
-msgstr "La création du dépôt %s a échouée :"
+msgstr "La création du dépôt %s a échoué :"
#: lib/choose_repository.tcl:387
msgid "Directory:"
@@ -1093,11 +1093,11 @@ msgstr "Cloner"
#: lib/choose_repository.tcl:473
msgid "Source Location:"
-msgstr "Emplacement source:"
+msgstr "Emplacement source :"
#: lib/choose_repository.tcl:484
msgid "Target Directory:"
-msgstr "Répertoire cible:"
+msgstr "Répertoire cible :"
#: lib/choose_repository.tcl:496
msgid "Clone Type:"
@@ -1137,7 +1137,7 @@ msgstr "L'emplacement %s existe déjà."
#: lib/choose_repository.tcl:622
msgid "Failed to configure origin"
-msgstr "La configuration de l'origine a échouée."
+msgstr "La configuration de l'origine a échoué."
#: lib/choose_repository.tcl:634
msgid "Counting objects"
@@ -1242,7 +1242,7 @@ msgstr "fichiers"
#: lib/choose_repository.tcl:962
msgid "Initial file checkout failed."
-msgstr "Chargement initial du fichier échoué."
+msgstr "Le chargement initial du fichier a échoué."
#: lib/choose_repository.tcl:978
msgid "Open"
@@ -1284,7 +1284,7 @@ msgstr "Révision invalide : %s"
#: lib/choose_rev.tcl:338
msgid "No revision selected."
-msgstr "Pas de révision selectionnée."
+msgstr "Pas de révision sélectionnée."
#: lib/choose_rev.tcl:346
msgid "Revision expression is empty."
@@ -1292,7 +1292,7 @@ msgstr "L'expression de révision est vide."
#: lib/choose_rev.tcl:531
msgid "Updated"
-msgstr "Mise-à-jour:"
+msgstr "Mise à jour:"
#: lib/choose_rev.tcl:559
msgid "URL"
@@ -1320,8 +1320,8 @@ msgid ""
msgstr ""
"Impossible de corriger pendant une fusion.\n"
"\n"
-"Vous êtes actuellement au milieu d'une fusion qui n'a pas été completement "
-"terminée. Vous ne pouvez pas corriger le commit précédant sauf si vous "
+"Vous êtes actuellement au milieu d'une fusion qui n'a pas été complètement "
+"terminée. Vous ne pouvez pas corriger le commit précédent sauf si vous "
"abandonnez la fusion courante.\n"
#: lib/commit.tcl:49
@@ -1409,7 +1409,7 @@ msgstr ""
#: lib/commit.tcl:211
#, tcl-format
msgid "warning: Tcl does not support encoding '%s'."
-msgstr "attention : Tcl ne supporte pas l'encodage '%s'."
+msgstr "attention : Tcl ne supporte pas le codage '%s'."
#: lib/commit.tcl:227
msgid "Calling pre-commit hook..."
@@ -1469,12 +1469,12 @@ msgstr "commit-tree a échoué :"
#: lib/commit.tcl:373
msgid "update-ref failed:"
-msgstr "update-ref a échoué"
+msgstr "update-ref a échoué :"
#: lib/commit.tcl:461
#, tcl-format
msgid "Created commit %s: %s"
-msgstr "Commit créé %s : %s"
+msgstr "Commit %s créé : %s"
#: lib/console.tcl:59
msgid "Working... please wait..."
@@ -1581,24 +1581,24 @@ msgid ""
"LOCAL: deleted\n"
"REMOTE:\n"
msgstr ""
-"LOCAL: supprimé\n"
-"DISTANT:\n"
+"LOCAL : supprimé\n"
+"DISTANT :\n"
#: lib/diff.tcl:125
msgid ""
"REMOTE: deleted\n"
"LOCAL:\n"
msgstr ""
-"DISTANT: supprimé\n"
-"LOCAL:\n"
+"DISTANT : supprimé\n"
+"LOCAL :\n"
#: lib/diff.tcl:132
msgid "LOCAL:\n"
-msgstr "LOCAL:\n"
+msgstr "LOCAL :\n"
#: lib/diff.tcl:135
msgid "REMOTE:\n"
-msgstr "DISTANT:\n"
+msgstr "DISTANT :\n"
#: lib/diff.tcl:197 lib/diff.tcl:296
#, tcl-format
@@ -1624,7 +1624,7 @@ msgid ""
"* Showing only first %d bytes.\n"
msgstr ""
"* Le fichier non suivi fait %d octets.\n"
-"* On montre seulement les premiers %d octets.\n"
+"* Seuls les %d premiers octets sont montrés.\n"
#: lib/diff.tcl:228
#, tcl-format
@@ -1635,7 +1635,7 @@ msgid ""
msgstr ""
"\n"
"* Fichier suivi raccourcis ici de %s.\n"
-"* Pour voir le fichier entier, utiliser un éditeur externe.\n"
+"* Pour voir le fichier entier, utilisez un éditeur externe.\n"
#: lib/diff.tcl:436
msgid "Failed to unstage selected hunk."
@@ -1680,7 +1680,7 @@ msgstr "Vous devez corriger les erreurs suivantes avant de pouvoir commiter."
#: lib/index.tcl:6
msgid "Unable to unlock the index."
-msgstr "Impossible de dévérouiller l'index."
+msgstr "Impossible de déverrouiller l'index."
#: lib/index.tcl:15
msgid "Index Error"
@@ -1700,12 +1700,12 @@ msgstr "Continuer"
#: lib/index.tcl:31
msgid "Unlock Index"
-msgstr "Déverouiller l'index"
+msgstr "Déverrouiller l'index"
#: lib/index.tcl:287
#, tcl-format
msgid "Unstaging %s from commit"
-msgstr "Désindexation de: %s"
+msgstr "Désindexation de : %s"
#: lib/index.tcl:326
msgid "Ready to commit."
@@ -1804,11 +1804,11 @@ msgid ""
msgstr ""
"Vous êtes au milieu d'une modification.\n"
"\n"
-"Le fichier %s est modifié.\n"
+"Le fichier %s a été modifié.\n"
"\n"
"Vous devriez terminer le commit courant avant de lancer une fusion. En "
"faisait comme cela, vous éviterez de devoir éventuellement abandonner une "
-"fusion ayant échouée.\n"
+"fusion ayant échoué.\n"
#: lib/merge.tcl:107
#, tcl-format
@@ -1826,7 +1826,7 @@ msgstr "La fusion s'est faite avec succès."
#: lib/merge.tcl:133
msgid "Merge failed. Conflict resolution is required."
-msgstr "La fusion a echouée. Il est nécessaire de résoudre les conflicts."
+msgstr "La fusion a echoué. Il est nécessaire de résoudre les conflits."
#: lib/merge.tcl:158
#, tcl-format
@@ -1914,16 +1914,16 @@ msgid ""
"\n"
"This operation can be undone only by restarting the merge."
msgstr ""
-"Noter que le diff ne montre que les modifications en conflict.\n"
+"Noter que le diff ne montre que les modifications en conflit.\n"
"\n"
"%s sera écrasé.\n"
"\n"
-"Cette opération ne peut être défaite qu'en relançant la fusion."
+"Cette opération ne peut être inversée qu'en relançant la fusion."
#: lib/mergetool.tcl:45
#, tcl-format
msgid "File %s seems to have unresolved conflicts, still stage?"
-msgstr "Le fichier %s semble avoir des conflicts non résolus, indéxer quand même ?"
+msgstr "Le fichier %s semble avoir des conflits non résolus, indexer quand même ?"
#: lib/mergetool.tcl:60
#, tcl-format
@@ -1932,11 +1932,11 @@ msgstr "Ajouter une résolution pour %s"
#: lib/mergetool.tcl:141
msgid "Cannot resolve deletion or link conflicts using a tool"
-msgstr "Impossible de résoudre la suppression ou de relier des conflicts en utilisant un outil"
+msgstr "Impossible de résoudre la suppression ou de relier des conflits en utilisant un outil"
#: lib/mergetool.tcl:146
msgid "Conflict file does not exist"
-msgstr "Le fichier en conflict n'existe pas."
+msgstr "Le fichier en conflit n'existe pas."
#: lib/mergetool.tcl:264
#, tcl-format
@@ -1958,7 +1958,7 @@ msgid ""
"Error retrieving versions:\n"
"%s"
msgstr ""
-"Erreur lors de la récupération des versions:\n"
+"Erreur lors de la récupération des versions :\n"
"%s"
#: lib/mergetool.tcl:343
@@ -1968,7 +1968,7 @@ msgid ""
"\n"
"%s"
msgstr ""
-"Impossible de lancer l'outil de fusion:\n"
+"Impossible de lancer l'outil de fusion :\n"
"\n"
"%s"
@@ -1983,12 +1983,12 @@ msgstr "L'outil de fusion a échoué."
#: lib/option.tcl:11
#, tcl-format
msgid "Invalid global encoding '%s'"
-msgstr "Encodage global invalide '%s'"
+msgstr "Codage global '%s' invalide"
#: lib/option.tcl:19
#, tcl-format
msgid "Invalid repo encoding '%s'"
-msgstr "Encodage de dépôt invalide '%s'"
+msgstr "Codage de dépôt '%s' invalide"
#: lib/option.tcl:117
msgid "Restore Defaults"
@@ -2001,7 +2001,7 @@ msgstr "Sauvegarder"
#: lib/option.tcl:131
#, tcl-format
msgid "%s Repository"
-msgstr "Dépôt: %s"
+msgstr "Dépôt : %s"
#: lib/option.tcl:132
msgid "Global (All Repositories)"
@@ -2069,7 +2069,7 @@ msgstr "Nouveau modèle de nom de branche"
#: lib/option.tcl:155
msgid "Default File Contents Encoding"
-msgstr "Encodage du contenu des fichiers par défaut"
+msgstr "Codage du contenu des fichiers par défaut"
#: lib/option.tcl:203
msgid "Change"
@@ -2098,11 +2098,11 @@ msgstr "Préférences"
#: lib/option.tcl:314
msgid "Failed to completely save options:"
-msgstr "La sauvegarde complète des options a échouée :"
+msgstr "La sauvegarde complète des options a échoué :"
#: lib/remote.tcl:163
msgid "Remove Remote"
-msgstr "Supprimer dépôt distant"
+msgstr "Supprimer un dépôt distant"
#: lib/remote.tcl:168
msgid "Prune from"
@@ -2118,11 +2118,11 @@ msgstr "Pousser vers"
#: lib/remote_add.tcl:19
msgid "Add Remote"
-msgstr "Ajouter dépôt distant"
+msgstr "Ajouter un dépôt distant"
#: lib/remote_add.tcl:24
msgid "Add New Remote"
-msgstr "Ajouter nouveau dépôt distant"
+msgstr "Ajouter un nouveau dépôt distant"
#: lib/remote_add.tcl:28 lib/tools_dlg.tcl:36
msgid "Add"
@@ -2134,7 +2134,7 @@ msgstr "Détails des dépôts distants"
#: lib/remote_add.tcl:50
msgid "Location:"
-msgstr "Emplacement:"
+msgstr "Emplacement :"
#: lib/remote_add.tcl:62
msgid "Further Action"
@@ -2146,7 +2146,7 @@ msgstr "Récupérer immédiatement"
#: lib/remote_add.tcl:71
msgid "Initialize Remote Repository and Push"
-msgstr "Initialiser dépôt distant et pousser"
+msgstr "Initialiser un dépôt distant et pousser"
#: lib/remote_add.tcl:77
msgid "Do Nothing Else Now"
@@ -2193,7 +2193,7 @@ msgstr "Mise en place de %s (à %s)"
#: lib/remote_branch_delete.tcl:29 lib/remote_branch_delete.tcl:34
msgid "Delete Branch Remotely"
-msgstr "Supprimer branche à distance"
+msgstr "Supprimer une branche à distance"
#: lib/remote_branch_delete.tcl:47
msgid "From Repository"
@@ -2244,8 +2244,8 @@ msgid ""
"One or more of the merge tests failed because you have not fetched the "
"necessary commits. Try fetching from %s first."
msgstr ""
-"Une ou plusieurs des tests de fusion ont échoués parce que vous n'avez pas "
-"récupéré les commits nécessaires. Essayez de récupéré à partir de %s d'abord."
+"Un ou plusieurs des tests de fusion ont échoué parce que vous n'avez pas "
+"récupéré les commits nécessaires. Essayez de récupérer à partir de %s d'abord."
#: lib/remote_branch_delete.tcl:207
msgid "Please select one or more branches to delete."
@@ -2257,14 +2257,14 @@ msgid ""
"\n"
"Delete the selected branches?"
msgstr ""
-"Récupérer des branches supprimées est difficile.\n"
+"Il est difficile de récupérer des branches supprimées.\n"
"\n"
-"Souhaitez vous supprimer les branches sélectionnées ?"
+"Supprimer les branches sélectionnées ?"
#: lib/remote_branch_delete.tcl:226
#, tcl-format
msgid "Deleting branches from %s"
-msgstr "Supprimer les branches de %s"
+msgstr "Suppression des branches de %s"
#: lib/remote_branch_delete.tcl:286
msgid "No repository selected."
@@ -2285,7 +2285,7 @@ msgstr "Suivant"
#: lib/search.tcl:24
msgid "Prev"
-msgstr "Précédant"
+msgstr "Précédent"
#: lib/search.tcl:25
msgid "Case-Sensitive"
@@ -2293,7 +2293,7 @@ msgstr "Sensible à la casse"
#: lib/shortcut.tcl:20 lib/shortcut.tcl:61
msgid "Cannot write shortcut:"
-msgstr "Impossible d'écrire le raccourcis :"
+msgstr "Impossible d'écrire le raccourci :"
#: lib/shortcut.tcl:136
msgid "Cannot write icon:"
@@ -2318,7 +2318,7 @@ msgstr "Réinitialisation du dictionnaire à %s."
#: lib/spellcheck.tcl:73
msgid "Spell checker silently failed on startup"
-msgstr "La vérification d'orthographe a échouée silentieusement au démarrage"
+msgstr "La vérification d'orthographe a échoué silencieusement au démarrage"
#: lib/spellcheck.tcl:80
msgid "Unrecognized spell checker"
@@ -2351,11 +2351,11 @@ msgstr "Générer une clé"
#: lib/sshkey.tcl:56
msgid "Copy To Clipboard"
-msgstr "Copier dans le presse papier"
+msgstr "Copier dans le presse-papier"
#: lib/sshkey.tcl:70
msgid "Your OpenSSH Public Key"
-msgstr "Votre clé publique Open SSH"
+msgstr "Votre clé publique OpenSSH"
#: lib/sshkey.tcl:78
msgid "Generating..."
@@ -2368,7 +2368,7 @@ msgid ""
"\n"
"%s"
msgstr ""
-"Impossible de lancer ssh-keygen:\n"
+"Impossible de lancer ssh-keygen :\n"
"\n"
"%s"
@@ -2398,7 +2398,7 @@ msgstr "Lancer %s nécessite qu'un fichier soit sélectionné."
#: lib/tools.tcl:90
#, tcl-format
msgid "Are you sure you want to run %s?"
-msgstr "Êtes vous sûr de vouloir lancer %s ?"
+msgstr "Êtes-vous sûr de vouloir lancer %s ?"
#: lib/tools.tcl:110
#, tcl-format
@@ -2422,11 +2422,11 @@ msgstr "L'outil a échoué : %s"
#: lib/tools_dlg.tcl:22
msgid "Add Tool"
-msgstr "Ajouter outil"
+msgstr "Ajouter un outil"
#: lib/tools_dlg.tcl:28
msgid "Add New Tool Command"
-msgstr "Ajouter nouvelle commande d'outil"
+msgstr "Ajouter une nouvelle commande d'outil"
#: lib/tools_dlg.tcl:33
msgid "Add globally"
@@ -2438,7 +2438,7 @@ msgstr "Détails sur l'outil"
#: lib/tools_dlg.tcl:48
msgid "Use '/' separators to create a submenu tree:"
-msgstr "Utiliser les séparateurs '/' pour créer un arbre de sous menus :"
+msgstr "Utiliser les séparateurs '/' pour créer un arbre de sous-menus :"
#: lib/tools_dlg.tcl:61
msgid "Command:"
@@ -2462,7 +2462,7 @@ msgstr "Ne pas montrer la fenêtre de sortie des commandes"
#: lib/tools_dlg.tcl:97
msgid "Run only if a diff is selected ($FILENAME not empty)"
-msgstr "Lancer seulement si un diff est selectionné ($FILENAME non vide)"
+msgstr "Lancer seulement si un diff est sélectionné ($FILENAME non vide)"
#: lib/tools_dlg.tcl:121
msgid "Please supply a name for the tool."
@@ -2479,7 +2479,7 @@ msgid ""
"Could not add tool:\n"
"%s"
msgstr ""
-"Impossible d'ajouter l'outil:\n"
+"Impossible d'ajouter l'outil :\n"
"%s"
#: lib/tools_dlg.tcl:190
--
1.6.2.1
^ permalink raw reply related
* [PATCH] Increase the size of the die/warning buffer to avoid truncation
From: Shawn O. Pearce @ 2009-03-24 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Long messages like those from lockfile.c when a lock can't be
obtained truncate with only 256 bytes in the message buffer.
Bump it to 1024 to give more space for these longer cases.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This works around the truncation I noticed in the error message
from the second command in the sequence:
$ git branch foo.lock
$ git branch foo
usage.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/usage.c b/usage.c
index 24f5fc0..820d09f 100644
--- a/usage.c
+++ b/usage.c
@@ -7,7 +7,7 @@
static void report(const char *prefix, const char *err, va_list params)
{
- char msg[256];
+ char msg[1024];
vsnprintf(msg, sizeof(msg), err, params);
fprintf(stderr, "%s%s\n", prefix, msg);
}
--
1.6.2.1.471.g682837
^ permalink raw reply related
* Re: [PATCH v3 1/2] git-gui: various French translation fixes
From: Shawn O. Pearce @ 2009-03-24 23:02 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git, Christian Couder, Nicolas Sebrecht
In-Reply-To: <20090323233924.GA29922@zoy.org>
Sam Hocevar <sam@zoy.org> wrote:
> Mostly grammar, spelling and typography fixes, but also a few wording
> enhancements here and there.
I can't apply; I suspect your mailer mangled the character encoding.
Can you please resend as an attachment?
> po/fr.po | 202 +++++++++++++++++++++++++++++++-------------------------------
> 1 files changed, 101 insertions(+), 101 deletions(-)
>
> diff --git a/po/fr.po b/po/fr.po
> index 45773ab..e6bf1b4 100644
> --- a/po/fr.po
> +++ b/po/fr.po
> @@ -62,7 +62,7 @@ msgstr ""
> "\n"
> "%s n?cessite au moins Git 1.5.0.\n"
> "\n"
> -"Peut'on consid?rer que '%s' est en version 1.5.0 ?\n"
> +"Peut-on consid?rer que '%s' est en version 1.5.0 ?\n"
...
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2 2/2] pack-objects: don't loosen objects available in alternate or kept packs
From: Brandon Casey @ 2009-03-24 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, git, Nicolas Pitre
In-Reply-To: <7viqm15qda.fsf@gitster.siamese.dyndns.org>
Junio,
I notice this patch is in next now (I noticed earlier than today,
but haven't said anything).
I just want to point one minor thing. After figuring out why last_found
was initialized to (void *)1 rather then NULL, you seem to have committed
a version that was slightly different from what I submitted. The logic
is the same, but now the following line is different from the line in
sha1_file.c where I copied it from:
builtin-pack-objects.c (line 1952):
p = (last_found != (void *)1) ? last_found : packed_git;
sha1_file.c (line 1931):
p = (last_found == (void *)1) ? packed_git : last_found;
People should be able to easily recognize the two procedures as "the same".
This small difference may give them pause. If it is possible to amend
this commit before applying to master, perhaps you would like to do so.
Otherwise, no big deal.
-brandon
^ permalink raw reply
* Re: [RFC/PATCH 7/8] user-manual: add global config section
From: J. Bruce Fields @ 2009-03-24 22:42 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530903241517g1453033fs2c02de631595f7e9@mail.gmail.com>
On Wed, Mar 25, 2009 at 12:17:12AM +0200, Felipe Contreras wrote:
> On Tue, Mar 24, 2009 at 11:52 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Sun, Mar 22, 2009 at 08:05:20PM +0200, Felipe Contreras wrote:
> >> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> >> ---
> >> Documentation/user-manual.txt | 34 ++++++++++++++++++++++++++++++++++
> >> 1 files changed, 34 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> >> index 3278aa7..b7678aa 100644
> >> --- a/Documentation/user-manual.txt
> >> +++ b/Documentation/user-manual.txt
> >> @@ -40,6 +40,40 @@ without any explanation.
> >> Finally, see <<todo>> for ways that you can help make this manual more
> >> complete.
> >>
> >> +[[getting-started]]
> >> +Getting started
> >> +=============
> >> +
> >> +You can skip this section safely, however, configuring git at an early stage
> >> +would probably make your overall experience with it more pleasant. Also many
> >> +parts on this manual would be easier to grasp.
> >
> > I'd skip this first paragraph.
>
> Ok. I was regretting it even as I was writing it :p
>
> >> +
> >> +Git's configuration is distributed on different locations: 'system', 'global', and
> >> +'repository'. Variables are stored in the form of 'foo.bar', and the precedence
> >> +order is 'repository' > 'global' > 'system'.
> >
> > "distributed on" isn't right ("among" instead of "on" might work). It's
> > not obvious to me what ">" means in terms of precedence. And I'm not
> > sure the comment about the form conveys any useful information. Also, I
> > think the systemwide configuration is less important, and could be left
> > to the man page.
>
> Ok. That would make it easier.
>
> How about:
> Git's configuration is distributed among different locations--on this
> manual we are only going to deal with 'global' and 'repository', where
> 'repository' variables take precedence over 'global' ones.
Sounds OK, but "on this" should be "in this", or even simpler just:
"this manual will only deal with...". And then 'global' and
'repository' aren't really nouns on their own (what are they
modifying?). So maybe: "deal with 'global' and 'repository' variables"?
>
> >> +
> >> +You would probably want to start setting up something useful:
> >> +------------------------------------------------
> >> +$ git config --global color.ui auto
> >> +------------------------------------------------
> >> +
> >> +This will make prettier the output of certain commands such as `git diff`, but
> >> +that's not important; what is important here is that `color.ui` has been
> >> +stored in the 'global' (for the user) configuration.
> >> +
> >> +You can take a look and manually modify the configuration with the `--edit`
> >
> > "take a look and" isn't really necessary; either eliminate it or replace
> > it by "view and" or just "also".
>
> I like "View and".
OK. Thanks!--b.
^ permalink raw reply
* Re: fatal: unable to write sha1 file git 1.6.2.1
From: Peter @ 2009-03-24 22:42 UTC (permalink / raw)
To: Linus Torvalds, git
In-Reply-To: <alpine.LFD.2.00.0903241510010.3032@localhost.localdomain>
Linus Torvalds wrote:
> On Tue, 24 Mar 2009, Peter wrote:
>
>>> What OS? What filesystem? Are you perhaps running out of space?
>>>
>>
>> Its Lenny Debian 5.0.0, Diskspace is ample . Filesystem is cifs ( this is a
>> windows 2000 share mounted with samba in a VMware Workstation Debian client (
>> yes, I know ... )). Memory usage, according to htop, is constant = 140/504 MB
>> during the whole process until git fails.
>>
>
> Ok, it sounds very much like a possible CIFS problem.
>
> Getting the exact error code for the "close()" will be interesting,
> because the only thing that can return an error under Linux in close() is
> if the filesystem "->flush()" function fails with an error.
>
> In cifs, the cifs_flush() thing does a filemap_fdatawrite(), forcing the
> data out, and that in turn calls do_writepages() which in turn calls
> either generic_writepages() or cifs_writepages() depending on random cifs
> crap.
>
> I'm not seeing any obvious errors there. But I would _not_ be surprised if
> the fchmod(fd, 0444) that we did before the close could be causing this:
> cifs gets confused and thinks that it must not write to the file because
> the file has been turned read-only.
>
> Here's an idea: if this is reproducible for you, does the behavior change
> if you do
>
> [core]
> core.fsyncobjectfiles = true
>
> in your .git/config file? That causes git to always fsync() the written
> data _before_ it does that fchmod(), which in turn means that by the time
> the close() rolls around, there should be no data to write, and thus no
> possibility that anybody gets confused when there is still dirty data on a
> file that has been marked read-only.
>
> Anyway, I'm cc'ing Steve French and Jeff Layton, as the major CIFS go-to
> guys. It does seem like a CIFS bug is likely.
>
> Steve, Jeff: git does basically
>
> open(".git/objects/xy/tmp_obj_xyzzy", O_RDWR|O_CREAT|O_EXCL, 0600) = 5
> write(5, ".."..., len)
> fchmod(5, 0444)
> close(5)
> link(".git/objects/xy/tmp_obj_xyzzy", ".git/objects/xy/xyzzy");
> unlink(".git/objects/xy/tmp_obj_xyzzy");
>
> to write a new datafile. Under CIFS, that "close()" apparently sometimes
> returns with an error, and fails.
>
> I guess we could change the "fchmod()" to happen after the close(), just
> to make it easier for filesystems to get this right. And yes, as outlined
> above, there's a config option to make git use fdatasync() before it does
> that fchmod() too. But it does seem like CIFS is just buggy.
>
> If CIFS has problems with the above sequence (say, if some timeout
> refreshes the inode data or causes a re-connect with the server or
> whatever), then maybe cifs should always do an implicit fdatasync() when
> doing fchmod(), just to make sure that the fchmod won't screw up any
> cached dirty data?
>
> Linus
> --
> 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
>
Hi
Thanks a lot , I will check that out tomorrow, in the meantime, this is
the result of your patch being applied:
$ git add <big stuff>
fatal: error when closing sha1 file (Bad file descriptor)
Peter
^ permalink raw reply
* Re: large(25G) repository in git
From: Adam Heath @ 2009-03-24 22:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <49C8A102.6090408@op5.se>
Andreas Ericsson wrote:
> First of all, I'm going to hint that you would be far better off
> keeping the media files in a separate repository, linked in as a
> submodule in git and with tweaked configuration settings with the
> specific aim of handling huge files.
Already do that. We have a custom overlay/union-type filesystem, that
makes use of a small base directory, where code resides, then each
sub-website is where the content is.
It's just finding documentation thru google that describes the
workflow we are doing is difficult.
> The basis of such a repository is probably the following config
> settings, since media files very rarely compress enough to be
> worth the effort, and their own compressed formats make them
> very unsuitable delta candidates:
> [pack]
> # disable delta-based packing
> depth = 1
> # disable compression
> compression = 0
>
> [gc]
> # don't auto-pack, ever
> auto = 0
> # never automatically consolidate un-.keep'd packs
> autopacklimit = 0
Thanks for the pointers!
> You will have to manually repack this repository from time to
> time, and it's almost certainly a good idea to mark the
> resulting packs with .keep to avoid copying tons of data.
> When packs are being created, objects can be copied from
> existing packs, and send-pack will make use of that so that what
> goes over the wire will simply be copied from the existing packs.
>
> YMMV. If you do come up with settings that work fine for huge
> repos made up of mostly media files, please share your findings.
I'll use these as a basis.
>> So, to work around that, I ran git gc. When done, I discovered that
>> git repacked the *entire* repository. While not something I care for,
>> I can understand that, and live with it. It just took *hours* to do so.
>>
>
> I'm not sure what, if any, magic "git gc" applies before spawning
> "git repack", but running "git repack" directly would almost certainly
> have produced an incremental pack. Perhaps we need to make gc less
> magic.
The repo should only be converted into a single .pack, if the user
explicitily wants it. Any automatic gc call, or called without args,
should just take any loose objects and pack them up. But that's my
opinion.
> Not necessarily all that simple (we do not want to touch the ssh
> password if we can possibly avoid it, but the user shouldn't have
> to type it more than once), but certainly doable. Easier would
> probably be to recommend adding the proper SSH config variables,
> as has been stated elsewhere.
ssh-agent, or password-less anonymous ssh(I've got a custom login
script inside authorized_keys on the remote).
> See above. I *think* you can also do this with git-attributes, but
> I'm not sure. However, keeping the large media files in a sub-module
> would nicely solve that problem anyway, and is probably a good idea
> even with git-attributes support for pack delta- and compression
> settings.
The site would *still* be > 25G in size, at the least, and constantly
getting bigger. This site contains copies of ad videos from their
competitors, plus their own, and is used to market their international
company.
> http://www.thousandparsec.net/~tim/media+git.pdf probably holds all the
> relevant information when it comes to storing large media files with
> git. I have not checked and have no inclination to do so.
http://caca.zoy.org/wiki/git-bigfiles is another one.
^ permalink raw reply
* Re: fatal: unable to write sha1 file git 1.6.2.1
From: Linus Torvalds @ 2009-03-24 22:30 UTC (permalink / raw)
To: Peter; +Cc: Git Mailing List, Steve French, Jeff Layton
In-Reply-To: <49C94B02.5010604@mycircuit.org>
On Tue, 24 Mar 2009, Peter wrote:
> >
> > What OS? What filesystem? Are you perhaps running out of space?
>
> Its Lenny Debian 5.0.0, Diskspace is ample . Filesystem is cifs ( this is a
> windows 2000 share mounted with samba in a VMware Workstation Debian client (
> yes, I know ... )). Memory usage, according to htop, is constant = 140/504 MB
> during the whole process until git fails.
Ok, it sounds very much like a possible CIFS problem.
Getting the exact error code for the "close()" will be interesting,
because the only thing that can return an error under Linux in close() is
if the filesystem "->flush()" function fails with an error.
In cifs, the cifs_flush() thing does a filemap_fdatawrite(), forcing the
data out, and that in turn calls do_writepages() which in turn calls
either generic_writepages() or cifs_writepages() depending on random cifs
crap.
I'm not seeing any obvious errors there. But I would _not_ be surprised if
the fchmod(fd, 0444) that we did before the close could be causing this:
cifs gets confused and thinks that it must not write to the file because
the file has been turned read-only.
Here's an idea: if this is reproducible for you, does the behavior change
if you do
[core]
core.fsyncobjectfiles = true
in your .git/config file? That causes git to always fsync() the written
data _before_ it does that fchmod(), which in turn means that by the time
the close() rolls around, there should be no data to write, and thus no
possibility that anybody gets confused when there is still dirty data on a
file that has been marked read-only.
Anyway, I'm cc'ing Steve French and Jeff Layton, as the major CIFS go-to
guys. It does seem like a CIFS bug is likely.
Steve, Jeff: git does basically
open(".git/objects/xy/tmp_obj_xyzzy", O_RDWR|O_CREAT|O_EXCL, 0600) = 5
write(5, ".."..., len)
fchmod(5, 0444)
close(5)
link(".git/objects/xy/tmp_obj_xyzzy", ".git/objects/xy/xyzzy");
unlink(".git/objects/xy/tmp_obj_xyzzy");
to write a new datafile. Under CIFS, that "close()" apparently sometimes
returns with an error, and fails.
I guess we could change the "fchmod()" to happen after the close(), just
to make it easier for filesystems to get this right. And yes, as outlined
above, there's a config option to make git use fdatasync() before it does
that fchmod() too. But it does seem like CIFS is just buggy.
If CIFS has problems with the above sequence (say, if some timeout
refreshes the inode data or causes a re-connect with the server or
whatever), then maybe cifs should always do an implicit fdatasync() when
doing fchmod(), just to make sure that the fchmod won't screw up any
cached dirty data?
Linus
^ permalink raw reply
* Re: newbie question: git on existing svn repo via eclipse on windows
From: Robin Rosenberg @ 2009-03-24 22:31 UTC (permalink / raw)
To: Michael Gaber; +Cc: git
In-Reply-To: <49C8A66C.3080203@gmx.net>
tisdag 24 mars 2009 10:22:52 skrev Michael Gaber <Michael.Gaber@gmx.net>:
> Hello,
>
> I hope I'm right here to post this question and it hasn't been answered
> 100k times already.
> I'm currently programming my bachelor-thesis and my university only
> gives me a svn repository. Since I'm working a big amount of time
> offline I'd like to have the features a dvcs offers me to commit
> whenever i have completed a minor step even while I'm offline, so I
> don't forget what I've done until i get online again.
> Is there a simple way to do this especially on windows while using
> eclipse and egit.
Depends on your definition of "simple". Egit has no SVN support whatsoever,
so you have to use git-svn and egit side-by-side to accomplish your tasks.
-- robin
^ permalink raw reply
* Re: [RFC/PATCH 7/8] user-manual: add global config section
From: Felipe Contreras @ 2009-03-24 22:17 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20090324215223.GL19389@fieldses.org>
On Tue, Mar 24, 2009 at 11:52 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Sun, Mar 22, 2009 at 08:05:20PM +0200, Felipe Contreras wrote:
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>> Documentation/user-manual.txt | 34 ++++++++++++++++++++++++++++++++++
>> 1 files changed, 34 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>> index 3278aa7..b7678aa 100644
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -40,6 +40,40 @@ without any explanation.
>> Finally, see <<todo>> for ways that you can help make this manual more
>> complete.
>>
>> +[[getting-started]]
>> +Getting started
>> +=============
>> +
>> +You can skip this section safely, however, configuring git at an early stage
>> +would probably make your overall experience with it more pleasant. Also many
>> +parts on this manual would be easier to grasp.
>
> I'd skip this first paragraph.
Ok. I was regretting it even as I was writing it :p
>> +
>> +Git's configuration is distributed on different locations: 'system', 'global', and
>> +'repository'. Variables are stored in the form of 'foo.bar', and the precedence
>> +order is 'repository' > 'global' > 'system'.
>
> "distributed on" isn't right ("among" instead of "on" might work). It's
> not obvious to me what ">" means in terms of precedence. And I'm not
> sure the comment about the form conveys any useful information. Also, I
> think the systemwide configuration is less important, and could be left
> to the man page.
Ok. That would make it easier.
How about:
Git's configuration is distributed among different locations--on this
manual we are only going to deal with 'global' and 'repository', where
'repository' variables take precedence over 'global' ones.
>> +
>> +You would probably want to start setting up something useful:
>> +------------------------------------------------
>> +$ git config --global color.ui auto
>> +------------------------------------------------
>> +
>> +This will make prettier the output of certain commands such as `git diff`, but
>> +that's not important; what is important here is that `color.ui` has been
>> +stored in the 'global' (for the user) configuration.
>> +
>> +You can take a look and manually modify the configuration with the `--edit`
>
> "take a look and" isn't really necessary; either eliminate it or replace
> it by "view and" or just "also".
I like "View and".
>> +option (will use '$EDITOR'):
>
> s/will/which will/.
Ok.
--
Felipe Contreras
^ permalink raw reply
* Re: Implementing stat() with FindFirstFile()
From: Magnus Bäck @ 2009-03-24 21:54 UTC (permalink / raw)
To: git
In-Reply-To: <200903212055.15026.j6t@kdbg.org>
On Saturday, March 21, 2009 at 20:55 CET,
Johannes Sixt <j6t@kdbg.org> wrote:
> On Samstag, 21. März 2009, Magnus Bäck wrote:
>
> > Is there any reason why compat/win32.h uses GetFileAttributesEx()
> > instead of FindFirstFile() to implement the stat() call on Windows?
> > The current implementation requires each queried file to be opened
> > and closed while FindFirstFile() only reads the directory.
>
> There is: File times are extremely important for git. Unfortunately,
> MS's implementation of stat and utime are broken, and they do use
> FindFirstFile(). Read up on the topic here:
>
> http://search.cpan.org/~shay/Win32-UTCFileTime-1.50/lib/Win32/UTCFileTime.pm
Quite interesting, thanks. As it often is, "obvious" changes that
haven't been made aren't that obvious after all.
From what I gather the problematic conversion takes place in the Win32
layer, in which case we might be able to call the ZwQueryDirectoryFile()
kernel routine directly via ntdll.dll to obtain the file times straight
from the file system. Has anyone explored that path, and would it be
acceptable to make such a change?
[...]
--
Magnus Bäck
baeck@swipnet.se
^ permalink raw reply
* Re: [PATCH] Documentation: git-format-patch.txt rewordings and cleanups
From: J. Bruce Fields @ 2009-03-24 22:09 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1237803683-14939-1-git-send-email-bebarino@gmail.com>
On Mon, Mar 23, 2009 at 03:21:23AM -0700, Stephen Boyd wrote:
> Clarify --no-binary description using some words from the original
> commit 37c22a4b (add --no-binary, 2008-05-9). Cleanup --suffix and
> --thread descriptions. Add --thread style option to synopsis. Clarify
> renaming patches example.
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
> Is the synopsis getting too heavy? Maybe it should be changed to:
>
> git format-patch [<options>] [<common diff options>] [<revision range>]
>
> Documentation/git-format-patch.txt | 34 +++++++++++++++++-----------------
> 1 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
> index c2eb5fa..f31098b 100644
> --- a/Documentation/git-format-patch.txt
> +++ b/Documentation/git-format-patch.txt
> @@ -9,9 +9,9 @@ git-format-patch - Prepare patches for e-mail submission
> SYNOPSIS
> --------
> [verse]
> -'git format-patch' [-k] [-o <dir> | --stdout] [--thread]
> +'git format-patch' [-k] [-o <dir> | --stdout] [--thread[=<style>]]
> [--attach[=<boundary>] | --inline[=<boundary>] |
> - [--no-attach]]
> + --no-attach]
> [-s | --signoff] [<common diff options>]
> [-n | --numbered | -N | --no-numbered]
> [--start-number <n>] [--numbered-files]
> @@ -132,9 +132,9 @@ include::diff-options.txt[]
> the Message-Id header to reference.
> +
> The optional <style> argument can be either `shallow` or `deep`.
> -'Shallow' threading makes every mail a reply to the head of the
> +'shallow' threading makes every mail a reply to the head of the
> series, where the head is chosen from the cover letter, the
> -`\--in-reply-to`, and the first patch mail, in this order. 'Deep'
> +`\--in-reply-to`, and the first patch mail, in this order. 'deep'
> threading makes every mail a reply to the previous one. If not
> specified, defaults to the 'format.thread' configuration, or `shallow`
> if that is not set.
> @@ -169,24 +169,24 @@ if that is not set.
> --suffix=.<sfx>::
> Instead of using `.patch` as the suffix for generated
> filenames, use specified suffix. A common alternative is
> - `--suffix=.txt`.
> + `--suffix=.txt`. Leaving this empty will remove the `.patch`
> + suffix.
> +
> -Note that you would need to include the leading dot `.` if you
> -want a filename like `0001-description-of-my-change.patch`, and
> -the first letter does not have to be a dot. Leaving it empty would
> -not add any suffix.
> +Note the first letter is not required to be a dot, you will need to
> +include the leading dot `.` if you want a filename like
> +`0001-description-of-my-change.patch`.
That's a comma-splice, trivially fixed by changing "dot, you" to "dot;
you".
Better?: "Note that the leading dot isn't actually required if you don't
want a dot between the patch name and the suffix."
(Though personally I'd strike the whole sentence, since a) probably
nobody cares, and b) the 1 in a million person that does actually want
to do this can figure it out easily enough on their own with a quick
test.)
--b.
>
> --no-binary::
> - Don't output contents of changes in binary files, just take note
> - that they differ. Note that this disable the patch to be properly
> - applied. By default the contents of changes in those files are
> - encoded in the patch.
> + Do not output contents of changes in binary files, instead
> + display a notice that those files changed. Patches generated
> + using this option cannot be applied properly, but they are
> + still useful for code review.
>
> CONFIGURATION
> -------------
> You can specify extra mail header lines to be added to each message
> -in the repository configuration, new defaults for the subject prefix
> -and file suffix, control attachements, and number patches when outputting
> +in the repository configuration, defaults for the subject prefix
> +and file suffix, configure attachments, and number patches when outputting
> more than one.
>
> ------------
> @@ -234,8 +234,8 @@ $ git format-patch -M -B origin
> +
> Additionally, it detects and handles renames and complete rewrites
> intelligently to produce a renaming patch. A renaming patch reduces
> -the amount of text output, and generally makes it easier to review it.
> -Note that the "patch" program does not understand renaming patches, so
> +the amount of text output, and generally makes it easier to review.
> +Note that non-git "patch" programs won't understand renaming patches, so
> use it only when you know the recipient uses git to apply your patch.
>
> * Extract three topmost commits from the current branch and format them
> --
> 1.6.2
>
> --
> 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
* Re: Default color for commit hash in git-log is unreadable on bright background, and can't be changed.
From: Fyn Fynn @ 2009-03-24 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmybavbg9.fsf@gitster.siamese.dyndns.org>
Thanks a lot, Junio. That's exactly what I needed.
Seeing that you can customize the color so easily, this whole thing is
a non-issue.
Cheers and thanks for making git awesome,
Fynn
On Tue, Mar 24, 2009 at 2:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Fyn Fynn <fynfynn@gmail.com> writes:
>
>> Unfortunately, the default text foreground color for the "commit
>> <HASH>" line of git-log is 3 - yellow.
>> ...
>> Is there any good solution for this that I missed?
>
> Perhaps...
>
> $ git config color.diff.commmit cyan
>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/5] Documentation: removed some uses of the passive voice in git-bisect.txt.
From: J. Bruce Fields @ 2009-03-24 22:02 UTC (permalink / raw)
To: David J. Mellor; +Cc: gitster, git
In-Reply-To: <20090323031906.85EB117A4B@sandstone.whistlingcat.com>
On Sun, Mar 22, 2009 at 08:11:10PM -0700, David J. Mellor wrote:
>
> Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
> ---
> Amended to drop spurious uses of "you" as suggested in:
>
> http://article.gmane.org/gmane.comp.version-control.git/114210
>
> Documentation/git-bisect.txt | 22 +++++++++++-----------
> 1 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index 93d9fc0..a356a2b 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -81,7 +81,7 @@ will have been left with the first bad kernel revision in "refs/bisect/bad".
> Bisect reset
> ~~~~~~~~~~~~
>
> -To return to the original head after a bisect session, you issue the
> +To return to the original head after a bisect session, issue the
> following command:
>
> ------------------------------------------------
> @@ -95,8 +95,8 @@ the bisection state).
> Bisect visualize
> ~~~~~~~~~~~~~~~~
>
> -To see the currently remaining suspects in 'gitk', the following command
> -is issued during the bisection process:
> +To see the currently remaining suspects in 'gitk', issue the following
> +command during the bisection process:
>
> ------------
> $ git bisect visualize
> @@ -115,7 +115,7 @@ $ git bisect view --stat
> Bisect log and bisect replay
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -After having marked revisions as good or bad, you issue the following
> +After having marked revisions as good or bad, issue the following
> command to show what has been done so far:
>
> ------------
> @@ -135,7 +135,7 @@ $ git bisect replay that-file
> Avoiding testing a commit
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -If in the middle of a bisect session, you know that the next suggested
> +If, in the middle of a bisect session, you know that the next suggested
> revision is not a good one to test (e.g. the change the commit
> introduces is known not to work in your environment and you know it
> does not have anything to do with the bug you are chasing), you may
> @@ -151,8 +151,8 @@ $ git reset --hard HEAD~3 # try 3 revisions before what
> # was suggested
> ------------
>
> -Then compile and test the chosen revision. Afterwards the revision
> -is marked as good or bad in the usual manner.
> +Then you compile and test the chosen revision. Afterwards you mark
Two "you"'s got added here?
> +the revision as good or bad in the usual manner.
>
> Bisect skip
> ~~~~~~~~~~~~
> @@ -175,8 +175,8 @@ using the "'<commit1>'..'<commit2>'" notation. For example:
> $ git bisect skip v2.5..v2.6
> ------------
>
> -The effect of this would be that no commit between `v2.5` excluded and
> -`v2.6` included could be tested.
> +This tells the bisect process that no commit between `v2.5` excluded and
> +`v2.6` included should be tested.
Slightly more straightforward: "This tells git not to test any commit in
the range v2.5..v2.6." (But I'm assuming they already know git's
defition of ranges: if you think the reminder's necessary, some other
way to word it might be better; the "exlcuded"/"included" thing is a
little odd. Maybe replace by "exclusive"/"inclusive", or do something
like "after v2.5, up to and including v2.6".)
--b.
>
> Note that if you also want to skip the first commit of the range you
> would issue the command:
> @@ -185,8 +185,8 @@ would issue the command:
> $ git bisect skip v2.5 v2.5..v2.6
> ------------
>
> -This would cause the commits between `v2.5` included and `v2.6` included
> -to be skipped.
> +This tells the bisect process that the commits between `v2.5` included
> +and `v2.6` included should be skipped.
>
>
> Cutting down bisection by giving more parameters to bisect start
> --
> 1.6.2.1
>
> --
> 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
* Re: [RFC/PATCH 7/8] user-manual: add global config section
From: J. Bruce Fields @ 2009-03-24 21:52 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1237745121-6325-8-git-send-email-felipe.contreras@gmail.com>
On Sun, Mar 22, 2009 at 08:05:20PM +0200, Felipe Contreras wrote:
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> Documentation/user-manual.txt | 34 ++++++++++++++++++++++++++++++++++
> 1 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 3278aa7..b7678aa 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -40,6 +40,40 @@ without any explanation.
> Finally, see <<todo>> for ways that you can help make this manual more
> complete.
>
> +[[getting-started]]
> +Getting started
> +=============
> +
> +You can skip this section safely, however, configuring git at an early stage
> +would probably make your overall experience with it more pleasant. Also many
> +parts on this manual would be easier to grasp.
I'd skip this first paragraph.
> +
> +Git's configuration is distributed on different locations: 'system', 'global', and
> +'repository'. Variables are stored in the form of 'foo.bar', and the precedence
> +order is 'repository' > 'global' > 'system'.
"distributed on" isn't right ("among" instead of "on" might work). It's
not obvious to me what ">" means in terms of precedence. And I'm not
sure the comment about the form conveys any useful information. Also, I
think the systemwide configuration is less important, and could be left
to the man page.
> +
> +You would probably want to start setting up something useful:
> +------------------------------------------------
> +$ git config --global color.ui auto
> +------------------------------------------------
> +
> +This will make prettier the output of certain commands such as `git diff`, but
> +that's not important; what is important here is that `color.ui` has been
> +stored in the 'global' (for the user) configuration.
> +
> +You can take a look and manually modify the configuration with the `--edit`
"take a look and" isn't really necessary; either eliminate it or replace
it by "view and" or just "also".
> +option (will use '$EDITOR'):
s/will/which will/.
--b.
> +------------------------------------------------
> +$ git config --global --edit
> +[color]
> + ui = auto
> +------------------------------------------------
> +
> +Or you can manually edit the file which is located in `~/.gitconfig`. Other
> +locations are `/etc/gitconfig` (system), and `.git/config` (repository).
> +
> +Other git configurations will be covered in the rest of the manual, if you
> +want to learn more look at linkgit:git-config[1] for details.
>
> [[repositories-and-branches]]
> Repositories and Branches
> --
> 1.6.2.1.352.gae594
>
> --
> 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
* Re: Default color for commit hash in git-log is unreadable on bright background, and can't be changed.
From: Junio C Hamano @ 2009-03-24 21:48 UTC (permalink / raw)
To: Fyn Fynn; +Cc: git
In-Reply-To: <1a04eebf0903241416g67e7abfdh6b3aa746f12b0e83@mail.gmail.com>
Fyn Fynn <fynfynn@gmail.com> writes:
> Unfortunately, the default text foreground color for the "commit
> <HASH>" line of git-log is 3 - yellow.
> ...
> Is there any good solution for this that I missed?
Perhaps...
$ git config color.diff.commmit cyan
^ permalink raw reply
* Re: large(25G) repository in git
From: Adam Heath @ 2009-03-24 21:44 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git
In-Reply-To: <20090324210427.GC30959@zoy.org>
Sam Hocevar wrote:
> As stated several times by Linus and others, Git was not designed
> to handle large files. My stance on the issue is that before trying
> to optimise operations so that they perform well on large files, too,
> Git should usually avoid such operations, especially deltification.
> One notable exception would be someone storing their mailbox in Git,
> where deltification is a major space saver. But usually, these large
> files are binary blobs that do not benefit from delta search (or even
> compression).
Yeah, in this case, I *know* that my binary blobs are completely
different, and it's just a waste of time for git to come to the same
conclusion. I'd be perfectly willing to have some knob I could turn
that would tell git this.
> Since I also need to handle large files (80 GiB repository), I am
> cleaning up some fixes I did, which can be seen in the git-bigfiles
> project (http://caca.zoy.org/wiki/git-bigfiles). I have not yet tried
> to change git-push (because I submit through git-p4), but I hope to
> address it, too. As time goes I believe some of them could make it into
> mainstream Git.
I'd almost be willing to help. I know the basic premise to how git
works, but the devil is in the details, and I don't have time right
now to learn the internals.
Yet another thing to add to my todo list.
> In your particular case, I would suggest setting pack.packSizeLimit
> to something lower. This would reduce the time spent generating a new
> pack file if the problem were to happen again.
Yeah, saw that one, but *after* I had this problem. The default, if
not set, is unlimited, which in this case, is definately *not* what we
want.
^ permalink raw reply
* Default color for commit hash in git-log is unreadable on bright background, and can't be changed.
From: Fyn Fynn @ 2009-03-24 21:16 UTC (permalink / raw)
To: git
Hi folks.
I'm latest stable git (1.6.2) on a bright background terminal.
Unfortunately, the default text foreground color for the "commit
<HASH>" line of git-log is 3 - yellow. And yellow writing is not very
readable on bright background. Of course, I could customize color 3 at
the terminal letter to be darker, but that breaks everything else that
uses color 3 as a background highlight (vim, ack, etc.)
I've scoured the man pages, but haven't found any way to set the color
for that line in .gitconfig.
So, I suggest that this should be considered a bug. At the very least,
there should be an easy way to set that color for all us using a
bright background terminal - the default Gnome Terminal, the default
Terminal.app, and generally the default on many systems.
Is there any good solution for this that I missed?
Thanks,
Fynn
^ permalink raw reply
* Re: fatal: unable to write sha1 file git 1.6.2.1
From: Peter @ 2009-03-24 21:05 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.0903241226570.3032@localhost.localdomain>
I consolidate from Nicolas and Linus, thanks for your help:
Currently, Git is unable to deal with files that it cannot load entirely
in memory.
What is the size of your largest file?
The biggest is 51 Mb , followed by one that is 23 MB. I was able to add
and commit a part of the dir tree where the biggest file was 14 Mb. So
there seems to be a threshold between 23 Mb and 14 Mb.
> If that is the only error message you got, then afaik the only way that
> can happen is if "close(fd)" returns an error.
>
Yes thats the only message I got.
> The only other "unable to write sha1 file" message happens if
> write_buffer() fails, but if that happens then you should also have gotten
> a
>
> file write error (<error message goes here>)
>
> message in addition to the "unable to write sha1 file".
>
> What OS? What filesystem? Are you perhaps running out of space?
>
Its Lenny Debian 5.0.0, Diskspace is ample . Filesystem is cifs ( this
is a windows 2000 share mounted with samba in a VMware Workstation
Debian client ( yes, I know ... )). Memory usage, according to htop, is
constant = 140/504 MB during the whole process until git fails.
> You could also try to apply this patch to get more information (Junio,
> maybe worth doing regardless? We should try to avoid ambiguous error
> messages that don't give full error information)
>
> Linus
> ---
> sha1_file.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 4563173..54972f9 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2287,7 +2287,7 @@ static void close_sha1_file(int fd)
> fsync_or_die(fd, "sha1 file");
> fchmod(fd, 0444);
> if (close(fd) != 0)
> - die("unable to write sha1 file");
> + die("error when closing sha1 file (%s)", strerror(errno));
> }
>
> /* Size of directory component, including the ending '/' */
> --
>
Will try it, thanks
Peter
^ permalink raw reply
* Re: large(25G) repository in git
From: Sam Hocevar @ 2009-03-24 21:04 UTC (permalink / raw)
To: Adam Heath; +Cc: git
In-Reply-To: <49C7FAB3.7080301@brainfood.com>
On Mon, Mar 23, 2009, Adam Heath wrote:
> We maintain a website in git. This website has a bunch of backend
> server code, and a bunch of data files. Alot of these files are full
> videos.
>
> [...]
>
> Last friday, I was doing a checkin on the production server, and found
> 1.6G of new files. git was quite able at committing that. However,
> pushing was problematic. I was pushing over ssh; so, a new ssh
> connection was open to the preview server. After doing so, git tried
> to create a new pack file. This took *ages*, and the ssh connection
> died. So did git, when it finally got done with the new pack, and
> discovered the ssh connection was gone.
As stated several times by Linus and others, Git was not designed
to handle large files. My stance on the issue is that before trying
to optimise operations so that they perform well on large files, too,
Git should usually avoid such operations, especially deltification.
One notable exception would be someone storing their mailbox in Git,
where deltification is a major space saver. But usually, these large
files are binary blobs that do not benefit from delta search (or even
compression).
Since I also need to handle large files (80 GiB repository), I am
cleaning up some fixes I did, which can be seen in the git-bigfiles
project (http://caca.zoy.org/wiki/git-bigfiles). I have not yet tried
to change git-push (because I submit through git-p4), but I hope to
address it, too. As time goes I believe some of them could make it into
mainstream Git.
In your particular case, I would suggest setting pack.packSizeLimit
to something lower. This would reduce the time spent generating a new
pack file if the problem were to happen again.
Regards,
--
Sam.
^ 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