* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
From: Piotr Krukowiecki @ 2013-01-21 19:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Git Mailing List, Jonathan Nieder,
Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <7vwqv6fiz7.fsf@alter.siamese.dyndns.org>
On Mon, Jan 21, 2013 at 8:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> Most git commands that can be used with our without a filepattern are
>> tree-wide by default, the filepattern being used to restrict their scope.
>> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
>>
>> The inconsistancy of 'git add -u' and 'git add -A' are particularly
>> problematic since other 'git add' subcommands (namely 'git add -p' and
>> 'git add -e') are tree-wide by default.
>>
>> Flipping the default now is unacceptable, so this patch starts training
>> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
>> for the next steps:
>>
>> * forbid 'git add -u|-A' without filepattern (like 'git add' without
>> option)
>>
>> * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a
>> tree-wide scope.
>>
>
> I have to wonder if "git add -p" and "git add -e" are the ones that
> are broken, and the migration suggested here is going in the wrong
> direction, though. After all "add -p" and "add -e" are interactive
> by their nature, so it is a _lot_ easier to change their default
> behaviour in the name of "usability fix", "consistency fix", or
> whatever. Wouldn't we achieve the same consistency across modes of
> "add" if we made them relative to the current directory?
Consistency is one issue. +1 for having consistent behavior. But even
if all "git add" modes work consistently on current subdirectory, they
will be inconsistent with other git command, for example "git status"
or "git diff". I think it'd be better to have all git command work the
same (is that possible? is there a list of all commands which work on
current dir vs those working on whole tree?). I believe changing all
commands to work on current subdir is not an option.
Another issue is usability. Can we definitely say which is better: add
all changes from current subdir, or add all changes from whole tree? I
don't know. At the moment I think whole tree is better. That's usually
what I want. If I want to add only some changes, I first list the
status or run diff, and then explicitly say what to add. OTOH "add" is
kind of dangerous command - adding content to index is not reversible
(i.e. if there already is a previous version in index with changes,
"add" will overwrite it). But at the same time, another "dangerous"
command, "git add -a" works on whole tree. I use it frequently and
never had any problem with it.
So, from me +1 on making all commands work on whole tree.
--
Piotr Krukowiecki
^ permalink raw reply
* Re: [PATCH v2 0/6] GIT, Git, git
From: Junio C Hamano @ 2013-01-21 19:56 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: davvid, git
In-Reply-To: <1860384981.631689.1358793375131.JavaMail.ngmail@webmail20.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
> (as can be seen in the corresponding release note where 'GIT' was
> changed to 'Git' in the header line).
Didn't I already say that we never changed the name? The same
description seems to appear in [1/6] as well.
^ permalink raw reply
* Re: [PATCH v2 0/6] GIT, Git, git
From: Junio C Hamano @ 2013-01-21 20:01 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: davvid, git
In-Reply-To: <7vobgifgz2.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Ackermann <th.acker@arcor.de> writes:
>
>> Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
>> (as can be seen in the corresponding release note where 'GIT' was
>> changed to 'Git' in the header line).
>
> Didn't I already say that we never changed the name? The same
> description seems to appear in [1/6] as well.
What we stopped doing was to use "poor man's small caps". I do
agree the change in 1/6 to run s/GIT/Git/ is the right thing to do.
^ permalink raw reply
* Re: [RFC] git rm -u
From: Matthieu Moy @ 2013-01-21 20:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Piotr Krukowiecki, Jonathan Nieder, Eric James Michael Ritz,
Git Mailing List, Tomas Carnecky
In-Reply-To: <7v1udegy2o.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,
> 2007-08-16) changed the semantics to limit the operation to the
> working tree.
Not really. It fixed "git add -u path", not plain "git add -u". A quick
test checking out and compiling v1.5.2.5~1^ shows that "git add -u ."
from a subdirectory was adding everything from the root.
My interpretation is that v1.5.2.5~1 fixed an actual bug, without
thinking about what would happen when "git add -u" was called without
path, so the behavior is "what happens to be the most natural to
implement". Indeed, the behavior was actually documented only later, in
v1.5.4.3~3 (Feb 21 00:29:39 2008, Clarified the meaning of git-add -u in
the documentation), the previous doc said only "If no paths are
specified, all tracked files are updated.".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
From: Matthieu Moy @ 2013-01-21 20:06 UTC (permalink / raw)
To: Piotr Krukowiecki
Cc: Junio C Hamano, Git Mailing List, Jonathan Nieder,
Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <CAA01CsqwuR+HTUWA+iqSamOcR0WBhwK0kfn5+80L95TZn-SRng@mail.gmail.com>
Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
> Another issue is usability. Can we definitely say which is better: add
> all changes from current subdir, or add all changes from whole tree? I
> don't know.
Hard to tell, depending on users, use-case, ...
But the good news is: whatever option is chosen, the other one is only a
few keystrokes away (git add -u . or git add -u :/).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCHv2] l10n: de.po: fix some minor issues
From: Ralf Thielow @ 2013-01-21 20:07 UTC (permalink / raw)
To: trast; +Cc: jk, stimming, git, Ralf Thielow
In-Reply-To: <87622ql4tl.fsf@pctrast.inf.ethz.ch>
This fixes some minor issues and improves the
German translation a bit. The following things
were changed:
- use complete sentences in option related messages
- translate "use" consistently as "verwendet"
- don't translate "make sense" as "macht Sinn"
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
2013/1/21 Thomas Rast <trast@inf.ethz.ch>:
> Ralf Thielow <ralf.thielow@gmail.com> writes:
>
[...]
> It would be easier on the reviewers if you could split out such
> search&replace changes as s/benutzt/verwendet/ into a separate patch.
>
Yeah, I'll do so next time.
Thanks for your comments.
Ralf
po/de.po | 205 +++++++++++++++++++++++++++++++++------------------------------
1 file changed, 109 insertions(+), 96 deletions(-)
diff --git a/po/de.po b/po/de.po
index c8ad2f0..d3f4913 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1550,12 +1550,12 @@ msgstr "Hinzufügen von Dateien fehlgeschlagen"
#: builtin/add.c:392
msgid "-A and -u are mutually incompatible"
-msgstr "-A und -u sind zueinander inkompatibel"
+msgstr "Die Optionen -A und -u sind zueinander inkompatibel."
#: builtin/add.c:394
msgid "Option --ignore-missing can only be used together with --dry-run"
msgstr ""
-"Die Option --ignore-missing kann nur zusammen mit --dry-run benutzt werden."
+"Die Option --ignore-missing kann nur zusammen mit --dry-run verwendet werden."
#: builtin/add.c:414
#, c-format
@@ -2045,15 +2045,18 @@ msgstr "stellt <Wurzelverzeichnis> vor alle Dateinamen"
#: builtin/apply.c:4384
msgid "--3way outside a repository"
-msgstr "--3way außerhalb eines Projektarchivs"
+msgstr "Die Option --3way kann nicht außerhalb eines Projektarchivs verwendet"
+" werden."
#: builtin/apply.c:4392
msgid "--index outside a repository"
-msgstr "--index außerhalb eines Projektarchivs"
+msgstr "Die Option --index kann nicht außerhalb eines Projektarchivs verwendet"
+" werden."
#: builtin/apply.c:4395
msgid "--cached outside a repository"
-msgstr "--cached außerhalb eines Projektarchivs"
+msgstr "Die Option --cached kann nicht außerhalb eines Projektarchivs verwendet"
+" werden."
#: builtin/apply.c:4411
#, c-format
@@ -2503,7 +2506,7 @@ msgstr "Zweigspitze (HEAD) wurde nicht unter \"refs/heads\" gefunden!"
#: builtin/branch.c:836
msgid "--column and --verbose are incompatible"
-msgstr "--column und --verbose sind inkompatibel"
+msgstr "Die Optionen --column und --verbose sind inkompatibel."
#: builtin/branch.c:887
#, c-format
@@ -2518,8 +2521,8 @@ msgstr "Zweig '%s' hat keinen externen Übernahmezweig gesetzt"
#: builtin/branch.c:914
msgid "-a and -r options to 'git branch' do not make sense with a branch name"
msgstr ""
-"Die Optionen -a und -r bei 'git branch' machen mit einem Zweignamen keinen "
-"Sinn."
+"Die Optionen -a und -r bei 'git branch' können nicht gemeimsam mit einem "
+"Zweignamen verwendet werden."
#: builtin/branch.c:917
#, c-format
@@ -2720,12 +2723,12 @@ msgstr "Konnte Ergebnis der Zusammenführung von '%s' nicht hinzufügen."
#: builtin/checkout.c:245
#, c-format
msgid "'%s' cannot be used with updating paths"
-msgstr "'%s' kann nicht mit Pfaden benutzt werden"
+msgstr "'%s' kann nicht mit Pfaden verwendet werden"
#: builtin/checkout.c:248 builtin/checkout.c:251
#, c-format
msgid "'%s' cannot be used with %s"
-msgstr "'%s' kann nicht mit '%s' benutzt werden"
+msgstr "'%s' kann nicht mit '%s' verwendet werden"
#: builtin/checkout.c:254
#, c-format
@@ -2849,18 +2852,18 @@ msgstr "Referenz ist kein Baum: %s"
#: builtin/checkout.c:964
msgid "paths cannot be used with switching branches"
-msgstr "Pfade können nicht mit dem Wechseln von Zweigen benutzt werden"
+msgstr "Pfade können nicht beim Wechseln von Zweigen verwendet werden"
#: builtin/checkout.c:967 builtin/checkout.c:971
#, c-format
msgid "'%s' cannot be used with switching branches"
-msgstr "'%s' kann nicht mit dem Wechseln von Zweigen benutzt werden"
+msgstr "'%s' kann nicht beim Wechseln von Zweigen verwendet werden"
#: builtin/checkout.c:975 builtin/checkout.c:978 builtin/checkout.c:983
#: builtin/checkout.c:986
#, c-format
msgid "'%s' cannot be used with '%s'"
-msgstr "'%s' kann nicht mit '%s' benutzt werden"
+msgstr "'%s' kann nicht mit '%s' verwendet werden"
#: builtin/checkout.c:991
#, c-format
@@ -2938,11 +2941,11 @@ msgstr "second guess 'git checkout no-such-branch'"
#: builtin/checkout.c:1057
msgid "-b, -B and --orphan are mutually exclusive"
-msgstr "-b, -B und --orphan schliessen sich gegenseitig aus"
+msgstr "Die Optionen -b, -B und --orphan schließen sich gegenseitig aus."
#: builtin/checkout.c:1074
msgid "--track needs a branch name"
-msgstr "--track benötigt einen Zweignamen"
+msgstr "Bei der Option --track muss ein Zweigname angegeben werden."
#: builtin/checkout.c:1081
msgid "Missing branch name; try -b"
@@ -3010,7 +3013,7 @@ msgstr "löscht nur ignorierte Dateien"
#: builtin/clean.c:78
msgid "-x and -X cannot be used together"
-msgstr "-x und -X können nicht zusammen benutzt werden"
+msgstr "Die Optionen -x und -X können nicht gemeinsam verwendet werden."
#: builtin/clean.c:82
msgid ""
@@ -3079,7 +3082,7 @@ msgstr "um von einem lokalen Projektarchiv zu klonen"
#: builtin/clone.c:76
msgid "don't use local hardlinks, always copy"
-msgstr "benutzt lokal keine harten Links, immer Kopien"
+msgstr "verwendet lokal keine harten Links, immer Kopien"
#: builtin/clone.c:78
msgid "setup as shared repository"
@@ -3107,7 +3110,7 @@ msgstr "Name"
#: builtin/clone.c:88
msgid "use <name> instead of 'origin' to track upstream"
-msgstr "benutzt <Name> statt 'origin' für externes Projektarchiv"
+msgstr "verwendet <Name> statt 'origin' für externes Projektarchiv"
#: builtin/clone.c:90
msgid "checkout <branch> instead of the remote's HEAD"
@@ -3208,7 +3211,7 @@ msgstr "Sie müssen ein Projektarchiv zum Klonen angeben."
#: builtin/clone.c:705
#, c-format
msgid "--bare and --origin %s options are incompatible."
-msgstr "--bare und --origin %s Optionen sind inkompatibel."
+msgstr "Die Optionen --bare und --origin %s sind inkompatibel."
#: builtin/clone.c:719
#, c-format
@@ -3217,7 +3220,8 @@ msgstr "Projektarchiv '%s' existiert nicht."
#: builtin/clone.c:724
msgid "--depth is ignored in local clones; use file:// instead."
-msgstr "--depth wird in lokalen Klonen ignoriert; benutzen Sie stattdessen file://."
+msgstr "Die Option --depth wird in lokalen Klonen ignoriert; benutzen Sie "
+"stattdessen file://"
#: builtin/clone.c:734
#, c-format
@@ -3293,7 +3297,7 @@ msgstr "Abstand zwischen Spalten"
#: builtin/column.c:51
msgid "--command must be the first argument"
-msgstr "Option --command muss zuerst angegeben werden"
+msgstr "Die Option --command muss an erster Stelle stehen."
#: builtin/commit.c:34
msgid "git commit [options] [--] <filepattern>..."
@@ -3531,7 +3535,8 @@ msgstr "Ungültiger Modus '%s' für unbeobachtete Dateien"
#: builtin/commit.c:984
msgid "Using both --reset-author and --author does not make sense"
-msgstr "Verwendung von --reset-author und --author macht keinen Sinn."
+msgstr "Die Optionen --reset-author und --author können nicht gemeinsam "
+"verwendet werden."
#: builtin/commit.c:995
msgid "You have nothing to amend."
@@ -3548,29 +3553,30 @@ msgstr "\"cherry-pick\" ist im Gange -- kann nicht nachbessern."
#: builtin/commit.c:1003
msgid "Options --squash and --fixup cannot be used together"
msgstr ""
-"Die Optionen --squash und --fixup können nicht gemeinsam benutzt werden."
+"Die Optionen --squash und --fixup können nicht gemeinsam verwendet werden."
#: builtin/commit.c:1013
msgid "Only one of -c/-C/-F/--fixup can be used."
-msgstr "Nur eines von -c/-C/-F/--fixup kann benutzt werden."
+msgstr "Es kann nur eine Option von -c/-C/-F/--fixup verwendet werden."
#: builtin/commit.c:1015
msgid "Option -m cannot be combined with -c/-C/-F/--fixup."
-msgstr "Option -m kann nicht mit -c/-C/-F/--fixup kombiniert werden"
+msgstr "Die Option -m kann nicht mit -c/-C/-F/--fixup kombiniert werden."
#: builtin/commit.c:1023
msgid "--reset-author can be used only with -C, -c or --amend."
-msgstr "--reset--author kann nur mit -C, -c oder --amend benutzt werden"
+msgstr "Die Option --reset--author kann nur mit -C, -c oder --amend verwendet werden."
#: builtin/commit.c:1040
msgid "Only one of --include/--only/--all/--interactive/--patch can be used."
msgstr ""
-"Nur eines von --include/--only/--all/--interactive/--patch kann benutzt "
-"werden."
+"Es kann nur eine Option von --include/--only/--all/--interactive/--patch "
+"verwendet werden."
#: builtin/commit.c:1042
msgid "No paths with --include/--only does not make sense."
-msgstr "--include/--only machen ohne Pfade keinen Sinn."
+msgstr "Die Optionen --include und --only können nur mit der Angabe von Pfaden "
+"verwendet werden."
#: builtin/commit.c:1044
msgid "Clever... amending the last one with dirty index."
@@ -3590,11 +3596,11 @@ msgstr "Ungültiger \"cleanup\" Modus %s"
#: builtin/commit.c:1061
msgid "Paths with -a does not make sense."
-msgstr "Pfade mit -a machen keinen Sinn."
+msgstr "Die Option -a kann nur mit der Angabe von Pfaden verwendet werden."
#: builtin/commit.c:1067 builtin/commit.c:1202
msgid "--long and -z are incompatible"
-msgstr "--long und -z sind inkompatibel"
+msgstr "Die Optionen --long und -z sind inkompatibel."
#: builtin/commit.c:1162 builtin/commit.c:1398
msgid "show status concisely"
@@ -3715,18 +3721,18 @@ msgstr "verwendet Beschreibung der angegebenen Version wieder"
#: builtin/commit.c:1378
msgid "use autosquash formatted message to fixup specified commit"
msgstr ""
-"benutzt eine automatisch zusammengesetzte Beschreibung zum Nachbessern der "
+"verwendet eine automatisch zusammengesetzte Beschreibung zum Nachbessern der "
"angegebenen Version"
#: builtin/commit.c:1379
msgid "use autosquash formatted message to squash specified commit"
msgstr ""
-"benutzt eine automatisch zusammengesetzte Beschreibung zum Zusammenführen "
+"verwendet eine automatisch zusammengesetzte Beschreibung zum Zusammenführen "
"der angegebenen Version"
#: builtin/commit.c:1380
msgid "the commit is authored by me now (used with -C/-c/--amend)"
-msgstr "Setzt Sie als Autor der Version (benutzt mit -C/-c/--amend)"
+msgstr "Setzt Sie als Autor der Version (verwendet mit -C/-c/--amend)"
#: builtin/commit.c:1381 builtin/log.c:1073 builtin/revert.c:109
msgid "add Signed-off-by:"
@@ -3734,7 +3740,7 @@ msgstr "fügt 'Signed-off-by:'-Zeile hinzu"
#: builtin/commit.c:1382
msgid "use specified template file"
-msgstr "benutzt angegebene Vorlagendatei"
+msgstr "verwendet angegebene Vorlagendatei"
#: builtin/commit.c:1383
msgid "force edit of commit"
@@ -3876,19 +3882,19 @@ msgstr "Ort der Konfigurationsdatei"
#: builtin/config.c:52
msgid "use global config file"
-msgstr "benutzt globale Konfigurationsdatei"
+msgstr "verwendet globale Konfigurationsdatei"
#: builtin/config.c:53
msgid "use system config file"
-msgstr "benutzt systemweite Konfigurationsdatei"
+msgstr "verwendet systemweite Konfigurationsdatei"
#: builtin/config.c:54
msgid "use repository config file"
-msgstr "benutzt Konfigurationsdatei des Projektarchivs"
+msgstr "verwendet Konfigurationsdatei des Projektarchivs"
#: builtin/config.c:55
msgid "use given config file"
-msgstr "benutzt die angegebene Konfigurationsdatei"
+msgstr "verwendet die angegebene Konfigurationsdatei"
#: builtin/config.c:56
msgid "Action"
@@ -4076,15 +4082,15 @@ msgstr "protokolliert die Suchstrategie in der Standard-Fehlerausgabe"
#: builtin/describe.c:405
msgid "use any ref in .git/refs"
-msgstr "benutzt jede Referenz in .git/refs"
+msgstr "verwendet alle Referenzen in .git/refs"
#: builtin/describe.c:406
msgid "use any tag in .git/refs/tags"
-msgstr "benutzt alle Markierungen in .git/refs/tags"
+msgstr "verwendet alle Markierungen in .git/refs/tags"
#: builtin/describe.c:407
msgid "always use long format"
-msgstr "benutzt immer langes Format"
+msgstr "verwendet immer langes Format"
#: builtin/describe.c:410
msgid "only output exact matches"
@@ -4113,7 +4119,7 @@ msgstr ""
#: builtin/describe.c:436
msgid "--long is incompatible with --abbrev=0"
-msgstr "--long ist inkompatibel mit --abbrev=0"
+msgstr "Die Optionen --long und --abbrev=0 sind inkompatibel."
#: builtin/describe.c:462
msgid "No names found, cannot describe anything."
@@ -4121,7 +4127,7 @@ msgstr "Keine Namen gefunden, kann nichts beschreiben."
#: builtin/describe.c:482
msgid "--dirty is incompatible with committishes"
-msgstr "--dirty ist inkompatibel mit Versionen"
+msgstr "Die Option --dirty kann nicht mit Versionen verwendet werden."
#: builtin/diff.c:79
#, c-format
@@ -4426,7 +4432,7 @@ msgstr "fetch --all akzeptiert kein Projektarchiv als Argument"
#: builtin/fetch.c:986
msgid "fetch --all does not make sense with refspecs"
-msgstr "fetch --all macht keinen Sinn mit Referenzspezifikationen"
+msgstr "fetch --all kann nicht mit Referenzspezifikationen verwendet werden."
#: builtin/fetch.c:997
#, c-format
@@ -4436,8 +4442,8 @@ msgstr "Kein externes Archiv (einzeln oder Gruppe): %s"
#: builtin/fetch.c:1005
msgid "Fetching a group and specifying refspecs does not make sense"
msgstr ""
-"Abholen einer Gruppe mit Angabe von Referenzspezifikationen macht keinen "
-"Sinn."
+"Das Abholen einer Gruppe von externen Archiven kann nicht mit der Angabe\n"
+"von Referenzspezifikationen verwendet werden."
#: builtin/fmt-merge-msg.c:13
msgid "git fmt-merge-msg [-m <message>] [--log[=<n>]|--no-log] [--file <file>]"
@@ -4464,7 +4470,7 @@ msgstr "Text"
#: builtin/fmt-merge-msg.c:661
msgid "use <text> as start of message"
-msgstr "benutzt <Text> als Beschreibungsanfang"
+msgstr "verwendet <Text> als Beschreibungsanfang"
#: builtin/fmt-merge-msg.c:662
msgid "file to read from"
@@ -4673,11 +4679,11 @@ msgstr "durchläuft höchstens <Tiefe> Ebenen"
#: builtin/grep.c:667
msgid "use extended POSIX regular expressions"
-msgstr "benutzt erweiterte reguläre Ausdrücke aus POSIX"
+msgstr "verwendet erweiterte reguläre Ausdrücke aus POSIX"
#: builtin/grep.c:670
msgid "use basic POSIX regular expressions (default)"
-msgstr "benutzt grundlegende reguläre Ausdrücke aus POSIX (Standard)"
+msgstr "verwendet grundlegende reguläre Ausdrücke aus POSIX (Standard)"
#: builtin/grep.c:673
msgid "interpret patterns as fixed strings"
@@ -4685,7 +4691,7 @@ msgstr "interpretiert Muster als feste Zeichenketten"
#: builtin/grep.c:676
msgid "use Perl-compatible regular expressions"
-msgstr "benutzt Perl-kompatible reguläre Ausdrücke"
+msgstr "verwendet Perl-kompatible reguläre Ausdrücke"
#: builtin/grep.c:679
msgid "show line numbers"
@@ -4813,24 +4819,27 @@ msgstr "ungültiges Objekt %s"
#: builtin/grep.c:866
msgid "--open-files-in-pager only works on the worktree"
-msgstr "--open-files-in-pager arbeitet nur innerhalb des Arbeitsbaums"
+msgstr "Die Option --open-files-in-pager kann nur innerhalb des "
+"Arbeitsbaums verwendet werden."
#: builtin/grep.c:889
msgid "--cached or --untracked cannot be used with --no-index."
-msgstr "--cached oder --untracked kann nicht mit --no-index benutzt werden"
+msgstr "Die Optionen --cached und --untracked können nicht mit --no-index "
+"verwendet werden."
#: builtin/grep.c:894
msgid "--no-index or --untracked cannot be used with revs."
-msgstr "--no-index oder --untracked kann nicht mit Versionen benutzt werden"
+msgstr "Die Optionen --no-index und --untracked können nicht mit Versionen "
+"verwendet werden."
#: builtin/grep.c:897
msgid "--[no-]exclude-standard cannot be used for tracked contents."
-msgstr ""
-"--[no-]exlude-standard kann nicht mit beobachteten Inhalten benutzt werden"
+msgstr "Die Option --[no-]exclude-standard kann nicht mit beobachteten "
+"Inhalten verwendet werden."
#: builtin/grep.c:905
msgid "both --cached and trees are given."
-msgstr "sowohl --cached als auch Zweige gegeben"
+msgstr "Die Option --cached kann nicht mit Zweigen verwendet werden."
#: builtin/hash-object.c:60
msgid ""
@@ -5223,7 +5232,7 @@ msgstr "%s ist ungültig"
#: builtin/index-pack.c:1559
msgid "--fix-thin cannot be used without --stdin"
-msgstr "--fix-thin kann nicht ohne --stdin benutzt werden"
+msgstr "Die Option --fix-thin kann nicht ohne --stdin verwendet werden."
#: builtin/index-pack.c:1563 builtin/index-pack.c:1573
#, c-format
@@ -5232,7 +5241,7 @@ msgstr "Name der Paketdatei '%s' endet nicht mit '.pack'"
#: builtin/index-pack.c:1582
msgid "--verify with no packfile name given"
-msgstr "--verify ohne Name der Paketdatei angegeben"
+msgstr "Die Option --verify wurde ohne Namen der Paketdatei angegeben."
#: builtin/init-db.c:35
#, c-format
@@ -5474,11 +5483,11 @@ msgstr "Zwei Ausgabeverzeichnisse?"
#: builtin/log.c:1068
msgid "use [PATCH n/m] even with a single patch"
-msgstr "benutzt [PATCH n/m] auch mit einzelnem Patch"
+msgstr "verwendet [PATCH n/m] auch mit einzelnem Patch"
#: builtin/log.c:1071
msgid "use [PATCH] even with multiple patches"
-msgstr "benutzt [PATCH] auch mit mehreren Patches"
+msgstr "verwendet [PATCH] auch mit mehreren Patches"
#: builtin/log.c:1075
msgid "print patches to standard out"
@@ -5490,7 +5499,7 @@ msgstr "erzeugt ein Deckblatt"
#: builtin/log.c:1079
msgid "use simple number sequence for output file names"
-msgstr "benutzt einfache Nummernfolge für die Namen der Ausgabedateien"
+msgstr "verwendet einfache Nummernfolge für die Namen der Ausgabedateien"
#: builtin/log.c:1080
msgid "sfx"
@@ -5506,7 +5515,7 @@ msgstr "beginnt die Nummerierung der Patches bei <n> anstatt bei 1"
#: builtin/log.c:1085
msgid "Use [<prefix>] instead of [PATCH]"
-msgstr "benutzt [<Prefix>] anstatt [PATCH]"
+msgstr "verwendet [<Prefix>] anstatt [PATCH]"
#: builtin/log.c:1088
msgid "store resulting files in <dir>"
@@ -5596,23 +5605,23 @@ msgstr "unechte Einreicher-Informationen %s"
#: builtin/log.c:1208
msgid "-n and -k are mutually exclusive."
-msgstr "-n und -k schließen sich gegenseitig aus"
+msgstr "Die Optionen -n und -k schließen sich gegenseitig aus."
#: builtin/log.c:1210
msgid "--subject-prefix and -k are mutually exclusive."
-msgstr "--subject-prefix und -k schließen sich gegenseitig aus"
+msgstr "Die Optionen --subject-prefix und -k schließen sich gegenseitig aus."
#: builtin/log.c:1218
msgid "--name-only does not make sense"
-msgstr "--name-only macht keinen Sinn"
+msgstr "Die Option --name-only kann nicht verwendet werden."
#: builtin/log.c:1220
msgid "--name-status does not make sense"
-msgstr "--name-status macht keinen Sinn"
+msgstr "Die Option --name-status kann nicht verwendet werden."
#: builtin/log.c:1222
msgid "--check does not make sense"
-msgstr "--check macht keinen Sinn"
+msgstr "Die Option --check kann nicht verwendet werden."
#: builtin/log.c:1245
msgid "standard output, or directory, which one?"
@@ -5654,7 +5663,7 @@ msgstr "zeigt den Dateistatus mit Markierungen"
#: builtin/ls-files.c:465
msgid "use lowercase letters for 'assume unchanged' files"
-msgstr "benutzt Kleinbuchstaben für Dateien mit 'assume unchanged' Markierung"
+msgstr "verwendet Kleinbuchstaben für Dateien mit 'assume unchanged' Markierung"
#: builtin/ls-files.c:467
msgid "show cached files in the output (default)"
@@ -5770,7 +5779,7 @@ msgstr "listet nur Dateinamen auf"
#: builtin/ls-tree.c:140
msgid "use full path names"
-msgstr "benutzt vollständige Pfadnamen"
+msgstr "verwendet vollständige Pfadnamen"
#: builtin/ls-tree.c:142
msgid "list entire tree; not just current directory (implies --full-name)"
@@ -6072,7 +6081,8 @@ msgstr "Bin auf einem Zweig, der noch geboren wird; kann nicht quetschen."
#: builtin/merge.c:1194
msgid "Non-fast-forward commit does not make sense into an empty head"
-msgstr "nicht vorzuspulende Version macht in einem leeren Zweig keinen Sinn"
+msgstr "Nicht vorzuspulende Version kann nicht in einem leeren Zweig "
+"verwendet werden."
#: builtin/merge.c:1309
#, c-format
@@ -6171,7 +6181,7 @@ msgstr "sendet Ergebnisse zur Standard-Ausgabe"
#: builtin/merge-file.c:34
msgid "use a diff3 based merge"
-msgstr "benutzt eine diff3 basierte Zusammenführung"
+msgstr "verwendet eine diff3 basierte Zusammenführung"
#: builtin/merge-file.c:35
msgid "for conflicts, use our version"
@@ -6305,11 +6315,11 @@ msgstr "zeigt nur Namen an (keine SHA-1)"
#: builtin/name-rev.c:230
msgid "only use tags to name the commits"
-msgstr "benutzt nur Markierungen um die Versionen zu benennen"
+msgstr "verwendet nur Markierungen um die Versionen zu benennen"
#: builtin/name-rev.c:232
msgid "only use refs matching <pattern>"
-msgstr "benutzt nur Referenzen die <Muster> entsprechen"
+msgstr "verwendet nur Referenzen die <Muster> entsprechen"
#: builtin/name-rev.c:234
msgid "list all commits reachable from all refs"
@@ -6672,7 +6682,7 @@ msgstr "Notiz-Referenz"
#: builtin/notes.c:1071
msgid "use notes from <notes_ref>"
-msgstr "benutzt Notizen von <Notiz-Referenz>"
+msgstr "verwendet Notizen von <Notiz-Referenz>"
#: builtin/notes.c:1106 builtin/remote.c:1598
#, c-format
@@ -6774,12 +6784,12 @@ msgstr "verwendet existierende Objekte wieder"
#: builtin/pack-objects.c:2475
msgid "use OFS_DELTA objects"
-msgstr "benutzt OFS_DELTA Objekte"
+msgstr "verwendet OFS_DELTA Objekte"
#: builtin/pack-objects.c:2477
msgid "use threads when searching for best delta matches"
msgstr ""
-"benutzt Threads bei der Suche nach den besten Übereinstimmungen bei "
+"verwendet Threads bei der Suche nach den besten Übereinstimmungen bei "
"Unterschieden"
#: builtin/pack-objects.c:2479
@@ -6883,7 +6893,7 @@ msgstr "Kurzschrift für Markierung ohne <Markierung>"
#: builtin/push.c:64
msgid "--delete only accepts plain target ref names"
-msgstr "--delete akzeptiert nur reine Referenz-Namen als Ziel"
+msgstr "Die Option --delete akzeptiert nur reine Referenznamen als Ziel."
#: builtin/push.c:99
msgid ""
@@ -7088,23 +7098,23 @@ msgstr ""
#: builtin/push.c:310
msgid "--all and --tags are incompatible"
-msgstr "--all und --tags sind inkompatibel"
+msgstr "Die Optionen --all und --tags sind inkompatibel."
#: builtin/push.c:311
msgid "--all can't be combined with refspecs"
-msgstr "--all kann nicht mit Referenzspezifikationen kombiniert werden"
+msgstr "Die Option --all kann nicht mit Referenzspezifikationen kombiniert werden."
#: builtin/push.c:316
msgid "--mirror and --tags are incompatible"
-msgstr "--mirror und --tags sind inkompatibel"
+msgstr "Die Optionen --mirror und --tags sind inkompatibel."
#: builtin/push.c:317
msgid "--mirror can't be combined with refspecs"
-msgstr "--mirror kann nicht mit Referenzspezifikationen kombiniert werden"
+msgstr "Die Option --mirror kann nicht mit Referenzspezifikationen kombiniert werden."
#: builtin/push.c:322
msgid "--all and --mirror are incompatible"
-msgstr "--all und --mirror sind inkompatibel"
+msgstr "Die Optionen --all und --mirror sind inkompatibel."
#: builtin/push.c:382
msgid "repository"
@@ -7125,7 +7135,7 @@ msgstr "löscht Referenzen"
#: builtin/push.c:387
msgid "push tags (can't be used with --all or --mirror)"
msgstr ""
-"versendet Markierungen (kann nicht mit --all oder --mirror benutzt werden)"
+"versendet Markierungen (kann nicht mit --all oder --mirror verwendet werden)"
#: builtin/push.c:390
msgid "force updates"
@@ -7141,7 +7151,7 @@ msgstr "steuert rekursives Versenden von Unterprojekten"
#: builtin/push.c:394
msgid "use thin pack"
-msgstr "benutzt kleinere Pakete"
+msgstr "verwendet kleinere Pakete"
#: builtin/push.c:395 builtin/push.c:396
msgid "receive pack program"
@@ -7157,11 +7167,11 @@ msgstr "entfernt lokal gelöschte Referenzen"
#: builtin/push.c:410
msgid "--delete is incompatible with --all, --mirror and --tags"
-msgstr "--delete ist inkompatibel mit --all, --mirror und --tags"
+msgstr "Die Option --delete ist inkompatibel mit --all, --mirror und --tags."
#: builtin/push.c:412
msgid "--delete doesn't make sense without any refs"
-msgstr "--delete macht ohne irgendeine Referenz keinen Sinn"
+msgstr "Die Option --delete kann nur mit Referenzen verwendet werden."
#: builtin/read-tree.c:36
msgid ""
@@ -7369,13 +7379,14 @@ msgstr ""
#: builtin/remote.c:185
msgid "specifying a master branch makes no sense with --mirror"
-msgstr "Angabe eines Hauptzweiges macht mit --mirror keinen Sinn"
+msgstr "Die Option --mirror kann nicht mit der Angabe eines Hauptzweiges "
+"verwendet werden."
#: builtin/remote.c:187
msgid "specifying branches to track makes sense only with fetch mirrors"
msgstr ""
-"die Angabe von zu folgenden Zweigen macht nur mit dem Anfordern von "
-"Spiegelarchiven Sinn"
+"Die Angabe von zu folgenden Zweigen kann nur mit dem Anfordern von "
+"Spiegelarchiven verwendet werden."
#: builtin/remote.c:195 builtin/remote.c:646
#, c-format
@@ -7726,7 +7737,8 @@ msgstr "löscht URLs"
#: builtin/remote.c:1447
msgid "--add --delete doesn't make sense"
-msgstr "--add --delete macht keinen Sinn"
+msgstr "Die Optionen --add und --delete können nicht gemeinsam verwendet "
+"werden."
#: builtin/remote.c:1487
#, c-format
@@ -7945,7 +7957,7 @@ msgstr "git cherry-pick <Unterkommando>"
#: builtin/revert.c:70 builtin/revert.c:92
#, c-format
msgid "%s: %s cannot be used with %s"
-msgstr "%s: %s kann nicht mit %s benutzt werden"
+msgstr "%s: %s kann nicht mit %s verwendet werden"
#: builtin/revert.c:103
msgid "end revert or cherry-pick sequence"
@@ -8423,7 +8435,7 @@ msgstr "annotierte und GPG-signierte Markierung"
#: builtin/tag.c:464
msgid "use another key to sign the tag"
-msgstr "benutzt einen anderen Schlüssel um die Markierung zu signieren"
+msgstr "verwendet einen anderen Schlüssel um die Markierung zu signieren"
#: builtin/tag.c:465
msgid "replace the tag if exists"
@@ -9195,7 +9207,7 @@ msgstr "\"git-am\" scheint im Gange zu sein. Kann nicht neu aufbauen."
#: git-rebase.sh:296
msgid "The --exec option must be used with the --interactive option"
-msgstr "Die --exec Option muss mit der --interactive Option benutzt werden"
+msgstr "Die Option --exec muss mit --interactive verwendet werden."
#: git-rebase.sh:301
msgid "No rebase in progress?"
@@ -9204,7 +9216,7 @@ msgstr "Kein Neuaufbau im Gange?"
#: git-rebase.sh:312
msgid "The --edit-todo action can only be used during interactive rebase."
msgstr "Die --edit-todo Aktion kann nur während eines interaktiven "
-"Neuaufbaus benutzt werden."
+"Neuaufbaus verwendet werden."
#: git-rebase.sh:319
msgid "Cannot read HEAD"
@@ -9626,7 +9638,8 @@ msgstr "Fehler bei Rekursion in Unterprojekt-Pfad '$sm_path'"
#: git-submodule.sh:803
msgid "The --cached option cannot be used with the --files option"
-msgstr "Die --cached Option kann nicht mit der --files Option benutzt werden"
+msgstr "Die Optionen --cached und --files können nicht gemeinsam verwendet "
+"werden."
#. unexpected type
#: git-submodule.sh:843
--
1.8.1.1.250.geacf011
^ permalink raw reply related
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
From: Matthieu Moy @ 2013-01-21 20:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <7vwqv6fiz7.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Wouldn't we achieve the same consistency across modes of
> "add" if we made them relative to the current directory?
As other people already said, it would be nice to have consistency
accross most if not all commands. AFAICT, the only exceptions to
"tree-wide by default, say '.' to restrict to subdirectory" are git add
-u|-A, git grep and git clean.
Arguably, the "subtree by default" is a safety feature of "git clean",
and should be kept.
I don't care too deepely about "git grep". From previous discussions,
IIRC, other people didn't care either.
On the other hand, I can think of at least "git log", "git diff", "git
status" and to some extend "git commit" as tree-wide by default with
optional path restriction. I'd like "git add" to be on the same side.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCHv2] l10n: de.po: fix some minor issues
From: Thomas Rast @ 2013-01-21 20:28 UTC (permalink / raw)
To: Ralf Thielow; +Cc: jk, stimming, git
In-Reply-To: <1358798856-5185-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow <ralf.thielow@gmail.com> writes:
> This fixes some minor issues and improves the
> German translation a bit. The following things
> were changed:
> - use complete sentences in option related messages
> - translate "use" consistently as "verwendet"
> - don't translate "make sense" as "macht Sinn"
>
> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Thomas Rast <trast@inf.ethz.ch>
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
From: Robin Rosenberg @ 2013-01-21 20:29 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jonathan Nieder, Eric James Michael Ritz, Tomas Carnecky, git,
gitster
In-Reply-To: <vpqy5fmva6b.fsf@grenoble-inp.fr>
----- Ursprungligt meddelande -----
> > git diff
> > #looks good
> > git add -u
>
> That's indeed the kind of mistake I'd like to avoid. In your example,
> "git diff" is tree-wide, and "git add -u" is limited to ., so in
> general
> "git add -u" won't stage the same thing as "git diff" just showed.
Good point. I rarely cd to anything but the top of the tree, but that
might be just me. OTOH, git diff after -u would remind me. It would bad if -u
was tree wide and diff wasn't, but fortunately that's not the case.
The -A is a bit worse since it adds all the crap files lying around.
-- robin
^ permalink raw reply
* Re: [PATCH v3 0/2] Make git-svn work with gitdir links
From: Philip Oakley @ 2013-01-21 21:45 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano, Barry Wardell, "Joachim Schmitz"
In-Reply-To: <kdjip9$4j7$1@ger.gmane.org>
From: "Joachim Schmitz" <jojo@schmitz-digital.de>
Sent: Monday, January 21, 2013 2:19 PM
> Junio C Hamano wrote:
>> Barry Wardell <barry.wardell@gmail.com> writes:
[...]
>> Thanks for your persistence ;-) As this is a pretty old topic, I'll
>> give two URLs for people who are interested to view the previous
>> threads:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/192133
>> http://thread.gmane.org/gmane.comp.version-control.git/192127
>>
>> You would want to mark it as test_expect_failure in the first patch
>> and then flip it to text_expect_success in the second patch where
>> you fix the breakage? Otherwise, after applying the first patch,
>> the testsuite will break needlessly.
>
> I'd just apply them the other way round, 1st fix the problem, 2nd add
> a test for it
Isn't it a case of, 1st demonstrate the problem with a test, and then
2nd fix the problem.
Those less principled could could simply "fix" a non-existent problem
merely to get themselves into the change log, or worse, even if one may
fix-test under the hood.
>
> Bye, Jojo
Philip
^ permalink raw reply
* Re: [PATCH v3 0/2] Make git-svn work with gitdir links
From: Junio C Hamano @ 2013-01-21 22:08 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List, Barry Wardell, "Joachim Schmitz"
In-Reply-To: <2931F4CC43E4406DBB878482C2F0E4F4@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> From: "Joachim Schmitz" <jojo@schmitz-digital.de>
> Sent: Monday, January 21, 2013 2:19 PM
>> Junio C Hamano wrote:
>>> Barry Wardell <barry.wardell@gmail.com> writes:
> [...]
>>> Thanks for your persistence ;-) As this is a pretty old topic, I'll
>>> give two URLs for people who are interested to view the previous
>>> threads:
>>>
>>> http://thread.gmane.org/gmane.comp.version-control.git/192133
>>> http://thread.gmane.org/gmane.comp.version-control.git/192127
>>>
>>> You would want to mark it as test_expect_failure in the first patch
>>> and then flip it to text_expect_success in the second patch where
>>> you fix the breakage? Otherwise, after applying the first patch,
>>> the testsuite will break needlessly.
>>
>> I'd just apply them the other way round, 1st fix the problem, 2nd
>> add a test for it
>
> Isn't it a case of, 1st demonstrate the problem with a test, and then
> 2nd fix the problem.
>
> Those less principled could could simply "fix" a non-existent problem
> merely to get themselves into the change log, or worse, even if one
> may fix-test under the hood.
For a small/trivial fix, fixing the code and protecting the fix from
future breakages by adding tests that expect success in a single
commit is the most sensible thing to do. People who are interested,
and people who are auditing, can locally revert only the code change
to see the new tests fail fairly easily in such a case.
For a more involved series, it is easier to demonstrate a breakage
by adding tests that expect failure in the first commit, and then in
subsequent commits, to fix a class of bugs in the code and flipping
expect_failure into expect_success for the tests that the updated
code in the commit fixes.
For this particular topic, squashing the two patches into a single
commit may probably be the more appropriate between the two.
Thanks.
^ permalink raw reply
* Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
From: Jonathan Nieder @ 2013-01-21 22:22 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster, Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <1358769611-3625-1-git-send-email-Matthieu.Moy@imag.fr>
Hi,
Matthieu Moy wrote:
> The inconsistancy of 'git add -u' and 'git add -A' are particularly
> problematic since other 'git add' subcommands (namely 'git add -p' and
> 'git add -e') are tree-wide by default.
>
> Flipping the default now is unacceptable, so this patch starts training
> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
> for the next steps:
Thanks for tackling this.
> --- a/builtin/add.c
> +++ b/builtin/add.c
[...]
> + if (option_with_implicit_dot && !argc) {
> + /*
> + * To be consistant with "git add -p" and most Git
> + * commands, we should default to being tree-wide, but
> + * this is not the original behavior and can't be
> + * changed until users trained themselves not to type
> + * "git add -u" or "git add -A". For now, we warn and
> + * keep the old behavior. Later, this warning can be
> + * turned into a die(...), and eventually we may
> + * reallow the command with a new behavior.
> + */
> + warning(_("The behavior of 'git add %s' with no path argument will change in a future\n"
Would it be possible to make this conditional on cwd not being at the
toplevel (the case where "git add -u :/" and "git add -u ." have
different behavior)? E.g.,
static const char *here[2] = { ".", NULL };
if (prefix)
warning(...);
Thanks,
Jonathan
^ permalink raw reply
* [RFC] Instruct git-completion.bash that we are in test mode
From: Jean-Noël AVILA @ 2013-01-21 22:30 UTC (permalink / raw)
To: git
In test mode, git completion should only propose core commands.
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
---
I reworked the patch so that the test argument is only evaluated
when sourcing the file and there is no environment clutter.
At least, "it works for me".
contrib/completion/git-completion.bash | 8 +++++++-
t/t9902-completion.sh | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 14dd5e7..ac9fa65 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -531,10 +531,16 @@ __git_complete_strategy ()
return 1
}
+if [ "x$1" != "xTEST" ]; then
+ __git_cmdlist () { git help -a|egrep '^ [a-zA-Z0-9]'; }
+else
+ __git_cmdlist () { git help -a| egrep -m 1 -B1000 PATH | egrep '^ [a-zA-Z0-9]'; }
+fi
+
__git_list_all_commands ()
{
local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(__git_cmdlist)
do
case $i in
*--*) : helper pattern;;
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..51463b2 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -13,7 +13,7 @@ complete ()
return 0
}
-. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash"
+. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" TEST
# We don't need this function to actually join words or do anything special.
# Also, it's cleaner to avoid touching bash's internal completion variables.
--
1.8.1.1.271.g02f55e6
^ permalink raw reply related
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Jeff King @ 2013-01-21 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Duy Nguyen, git, spearce, mfick
In-Reply-To: <7v38xxnfv3.fsf@alter.siamese.dyndns.org>
On Sat, Jan 19, 2013 at 11:16:00AM -0800, Junio C Hamano wrote:
> For example, if you mirror-clone from either of my repositories from
> GitHub:
>
> git clone --mirror git://github.com/git/git/
> git clone --mirror git://github.com/gitster/git/
>
> you will see stuff that does not belong to the project; objects that
> are only reachable from refs/pull/* are not something I approved to
> be placed in my repository; I as the project owner do not want to
> give these objects to a cloner as if they are part of my project.
>
> The server side can hide refs/pull/ and refs/pull-request-tags/ so
> that clones (and ls-remote) will not see clutter, and nobody gets
> hurt.
I think it is unfortunately not so simple as that. You do not want them
to be part of your "clone --mirror", but some people do (because they
will inspect them when evaluating the pull request). And that decision
is, I think, in the eye of the cloner, not the eye of the repo owner. I
think in your case it is a little harder to see, in that you do not care
about the PR mechanism for git.git at all, but let us think for a minute
about a project that actually uses PRs.
For an ordinary developer, they would be content to fetch the branch
tips and tags (and that is what we do by default with "git clone). They
do not need to fetch all of refs/pull. If they learn out-of-band that PR
123 exists, they can in theory ask for refs/pull/123/head. That works
even with your proposal, because it is just about dropping the
advertisement, not the availability of refs.
But what about entities which really do want all of refs/pull? I can
think of two good reasons to want them:
1. You really do want a mirror, because you are creating a backup or
alternate distribution channel. IOW, you are using "git clone
--mirror", but it is missing those refs.
2. You are a developer who is sometimes disconnected. You want to
fetch all of the PRs, and then examine them at your leisure.
Without advertising, how do they ask for the wildcard of `refs/pull/*`?
They're stuck massaging some out-of-band data into a set of distinct
fetch refspecs.
I don't know much about what's in Gerrit's refs/changes, but I imagine
one could make a similar argument that their value is in the eye of the
client. And later you give this example:
> Another example. If you run ls-remote against the above two
> repositories, you will notice that the latter has tons more
> branches. The former are to publish only the primary integration
> branches, while the latter are to show individual topics.
>
> I wish I didn't have to do this if I could.
>
> We have periodical "What's cooking" postings that let interested
> parties learn topics out-of-band. If I can hide refs/heads/??/*
> from normal users' clones while actually keeping individual topics
> there at the same place, I do not have to push into two places.
Most people do not want to see those heads. But some people (like me)
do, and it is a great convenience to be able to fetch them all with a
wildcard refspec, which cannot work if they are not advertised. I would
have to parse what's cooking and fetch them each individually. That's
not a technologically insurmountable problem, but it means git is being
a lot less helpful than it could be.
So I think in these cases of "extra refs", some clients would want them,
and some would not. And only they can know which camp they are in, not
the server side. Which is why the current system works pretty well: we
advertise everything and let the client decide what it wants. Clone very
sanely fetches only refs/heads/* (and associated tags), and you can put
whatever extra junk you want elsewhere in the hierarchy. A mirrored
clone will fetch it, but to me that is the point of --mirror. And if you
want some arbitrary subset, then you can implement that, too, by the
use of fetch refspecs[1].
The downside, of course, is that the ref advertisement is bigger than
many clients will want. But dealing with that is a separate issue from
"these refs should never be shown", as solutions for one may not work
from the other (e.g., if we delayed ref advertisement until the client
had spoken, the client could tell us what refspecs they are interested
in).
For your topic branch example, why don't you push to refs/topics of the
main git repository? Then normal cloners wouldn't see it, but anybody
interested could add the appropriate fetch refspec.
-Peff
[1] It may be that refspecs are not as expressive as we would like,
but that is a client side problem we can deal with. For instance,
you cannot currently say "give me everything except refs/foo/*".
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Jeff King @ 2013-01-21 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <7vip6rjyn3.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 02:08:32PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Jeff King <peff@peff.net> writes:
> >
> >>> [uploadPack]
> >>> hiderefs = refs/changes
> >>
> >> Would you want to do the same thing on receive-pack? It could benefit
> >> from the same reduction in network cost (although it tends to be invoked
> >> less frequently than upload-pack).
> > ...
> > As I said, I view this primarily as solving the cluttering issue.
> > The use of hiderefs to hide these refs that point at objects I do
> > not consider belong to my repository from the pushers equally makes
> > sense as such, I think.
>
> Now that raises one question. Should this be transfer.hiderefs that
> governs both upload-pack and receive-pack? I tend to think the
> answer is yes.
Yes, that is what I was getting at (and it should have individual
hiderefs for each side that override the transfer.*, in case somebody
wants to make the distinction).
> It may even make sense to have "git push" honor it, excluding them
> from "git push --mirror" (or "git push --all" if some of the
> branches are hidden); I haven't thought things through, though.
That is harder, as that is something that happens on the client. How
does the client learn about the transfer.hiderefs setting on the remote?
It has to be out-of-band, at which point calling it by the same name has
little benefit.
-Peff
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Jeff King @ 2013-01-21 23:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <7vpq0zn2za.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 10:06:33AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> [uploadPack]
> >> hiderefs = refs/changes
> >
> > Would you want to do the same thing on receive-pack? It could benefit
> > from the same reduction in network cost (although it tends to be invoked
> > less frequently than upload-pack).
>
> Do *I* want to do? Not when there already is a patch exists; I'd
> rather take existing and tested patch ;-)
The patch we have is below, but I do not think you want it, as it is
missing several things:
- docs and tests
- handling multiple values
- anything but raw prefix matching (you even have to put in the "/"
yourself).
It was not my patch originally, and I never bothered to clean and
upstream it because I didn't think it was something anybody else would
be interested in. I'm happy to do so, but if you are working in the area
anyway, it would make sense to be part of your series.
-Peff
---
diff --git b/builtin/receive-pack.c a/builtin/receive-pack.c
index 0afb8b2..b22670c 100644
--- b/builtin/receive-pack.c
+++ a/builtin/receive-pack.c
@@ -39,6 +39,7 @@ static void *head_name_to_free;
static int auto_gc = 1;
static const char *head_name;
static void *head_name_to_free;
+static const char *hide_refs;
static int sent_capabilities;
static enum deny_action parse_deny_action(const char *var, const char *value)
@@ -113,11 +114,19 @@ static void show_ref(const char *path, const unsigned char *sha1)
return 0;
}
+ if (strcmp(var, "receive.hiderefs") == 0) {
+ git_config_string(&hide_refs, var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
static void show_ref(const char *path, const unsigned char *sha1)
{
+ if (hide_refs && strncmp(path, hide_refs, strlen(hide_refs)) == 0)
+ return 0;
+
if (sent_capabilities)
packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
else
^ permalink raw reply related
* Re: [PATCH v3 08/31] parse_pathspec: add PATHSPEC_EMPTY_MATCH_ALL
From: Martin von Zweigbergk @ 2013-01-21 23:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <1358080539-17436-9-git-send-email-pclouds@gmail.com>
Hi,
I was tempted to ask this before, and the recent thread regarding "add
-u/A" [1] convinced me to.
On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> We have two ways of dealing with empty pathspec:
>
> 1. limit it to current prefix
> 2. match the entire working directory
>
> Some commands go with #1, some with #2. get_pathspec() and
> parse_pathspec() only supports #1. Make it support #2 too via
> PATHSPEC_EMPTY_MATCH_ALL flag.
If #2 is indeed the direction we want to go, then maybe we should make
that the default behavior from parse_pathspec()? I.e. rename the flag
"PATHSPEC_EMPTY_MATCH_PREFIX" (or something). Makes sense?
Btw, Matthieu was asking where we use #1. If you do invert the name
and meaning of the flag, then the answer to that question should be
(mostly?) obvious from a re-roll of your series (i.e. all the places
where PATHSPEC_EMPTY_MATCH_PREFIX is used).
Martin
[1] http://thread.gmane.org/gmane.comp.version-control.git/213988/focus=214113
^ permalink raw reply
* Re: [PATCH v2] unpack-trees: do not abort when overwriting an existing file with the same content
From: Jeff King @ 2013-01-21 23:15 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1358768433-26096-1-git-send-email-pclouds@gmail.com>
On Mon, Jan 21, 2013 at 06:40:33PM +0700, Nguyen Thai Ngoc Duy wrote:
> + /*
> + * If it has the same content that we are going to overwrite,
> + * there's no point in complaining. We still overwrite it in
> + * the end though.
> + */
> + if (ce &&
> + S_ISREG(st->st_mode) && S_ISREG(ce->ce_mode) &&
> + (!trust_executable_bit ||
> + (0100 & (ce->ce_mode ^ st->st_mode)) == 0) &&
> + st->st_size < SAME_CONTENT_SIZE_LIMIT &&
> + sha1_object_info(ce->sha1, &ce_size) == OBJ_BLOB &&
> + ce_size == st->st_size) {
> + void *buffer = NULL;
> + unsigned long size;
> + enum object_type type;
> + struct strbuf sb = STRBUF_INIT;
> + int matched =
> + strbuf_read_file(&sb, ce->name, ce_size) == ce_size &&
> + (buffer = read_sha1_file(ce->sha1, &type, &size)) != NULL &&
> + type == OBJ_BLOB &&
> + size == ce_size &&
> + !memcmp(buffer, sb.buf, size);
> + free(buffer);
> + strbuf_release(&sb);
> + if (matched)
> + return 0;
> + }
Can you elaborate on when this code is triggered?
In the general case, shouldn't we already know the sha1 of what's on
disk in the index, and be able to just compare the hashes? And if we
don't, because the entry is start-dirty, should we be updating it
(possibly earlier, so we do not even get into the "need to write" code
path) instead of doing this ad-hoc byte comparison?
Confused...
-Peff
^ permalink raw reply
* Re: [RFC] git rm -u
From: Junio C Hamano @ 2013-01-21 23:18 UTC (permalink / raw)
To: Matthieu Moy
Cc: Piotr Krukowiecki, Jonathan Nieder, Eric James Michael Ritz,
Git Mailing List, Tomas Carnecky
In-Reply-To: <vpqhamapal1.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,
>> 2007-08-16) changed the semantics to limit the operation to the
>> working tree.
>
> Not really. It fixed "git add -u path", not plain "git add -u". A quick
> test checking out and compiling v1.5.2.5~1^ shows that "git add -u ."
> from a subdirectory was adding everything from the root.
>
> My interpretation is that v1.5.2.5~1 fixed an actual bug, without
> thinking about what would happen when "git add -u" was called without
> path, so the behavior is "what happens to be the most natural to
> implement".
I guess at this point it does not matter that much if that was an
unintended consequence of a buggy fix, or a new behaviour by design.
We initially were tree-wide but later limited the operation to the
current directory.
I think your "Check 'git diff' then run 'git add -u'" example may be
a good enough argument that it is a good idea to restore the
originally intended "tree-wide" behaviour in any case.
^ permalink raw reply
* Re: [RFC] Instruct git-completion.bash that we are in test mode
From: Junio C Hamano @ 2013-01-21 23:32 UTC (permalink / raw)
To: Jean-Noël AVILA; +Cc: git
In-Reply-To: <201301212330.10824.jn.avila@free.fr>
"Jean-Noël AVILA" <jn.avila@free.fr> writes:
> At least, "it works for me".
I suspect that your approach will still not fix the case in which
you build a branch with a new command git-check-ignore, and then
check out another branch that does not yet have that command without
first running "make clean".
Does the following really pass with your patch?
git checkout origin/next
make
git checkout origin/maint
git apply your_patch.mbox
make
cd t && sh ./t9902-completion.sh
> + __git_cmdlist () { git help -a| egrep -m 1 -B1000 PATH | egrep '^ [a-zA-Z0-9]'; }
'egrep' is not even in POSIX in the first place but grep -E ought to
be a replacement for it, so I'll let it pass, but "-m1 -B1000"?
Please stay within portable options.
git help -a |
sed -n -e '/^ [a-z]/p' -e '/^git commands available from elsewhere/q'/'
might be a good enough substitute, I think, if we were to take your
approach, but I suspect it needs a lot more to limit the output in
the test mode.
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Junio C Hamano @ 2013-01-21 23:33 UTC (permalink / raw)
To: Jeff King; +Cc: git, spearce, mfick
In-Reply-To: <20130121230108.GB17156@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> It may even make sense to have "git push" honor it, excluding them
>> from "git push --mirror" (or "git push --all" if some of the
>> branches are hidden); I haven't thought things through, though.
>
> That is harder, as that is something that happens on the client. How
> does the client learn about the transfer.hiderefs setting on the remote?
No, I was talking about running "git push" from a repository that
has the transfer.hiderefs set, emulating a fetch from a client by
pushing out in the reverse direction.
^ permalink raw reply
* Re: [PATCH v6 0/8] push: update remote tags only with force
From: Jeff King @ 2013-01-21 23:40 UTC (permalink / raw)
To: Chris Rorvick
Cc: Junio C Hamano, Max Horn, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Felipe Contreras
In-Reply-To: <CAEUsAPZr+bNNA-pqrQbBGvku4T3h58Ub66mK2zLeHqghEKw5Aw@mail.gmail.com>
On Thu, Jan 17, 2013 at 09:18:50PM -0600, Chris Rorvick wrote:
> On Thu, Jan 17, 2013 at 7:06 PM, Jeff King <peff@peff.net> wrote:
> > However, if instead of the rule being
> > "blobs on the remote side cannot be replaced", if it becomes "the old
> > value on the remote side must be referenced by what we replace it with",
> > that _is_ something we can calculate reliably on the sending side.
>
> Interesting. I would have thought knowing reachability implied having
> the old object in the sending repository.
No, because if you do not have it, then you know it is not reachable
from your refs (or your repository is corrupted). If you do have it, it
_might_ be reachable. For commits, checking is cheap (merge-base) and we
already do it. For trees and blobs, it is much more expensive, as you
have to walk the whole object graph. While it might be "more correct"
in some sense to say "it's OK to replace a tree with a commit that
points to it", in practice I doubt anyone cares, so you can probably
just punt on those ones and say "no, it's not a fast forward".
> > And
> > that is logically an extension of the fast-forward rule, which is why I
> > suggested placing it with ref_newer (but the latter should probably be
> > extended to not suggest merging if we _know_ it is a non-commit object).
>
> Sounds great, especially if it is not dependent on the sender actually
> having the old object. Until this is implemented, though, I don't
> understand what was wrong with doing the checks in the
> is_forwardable() helper function (of course after fixing the
> regression/bug.)
I don't think it is wrong per se; I just think that the check would go
more naturally where we are checking whether the object does indeed
fast-forward. Because is_forwardable in some cases must say "I don't
know; I don't have the object to check its type, so maybe it is
forwardable, and maybe it is not". Whereas when we do the actual
reachability check, we can say definitely "this is not reachable because
I don't have it, or this is not reachable because it is a commit and I
checked, or this might be reachable but I don't care to check because it
has a funny type".
I think looking at it as the latter makes it more obvious how to handle
the "maybe" situation (e.g., the bug in is_forwardable was hard to see).
Anyway, I do not care that much where it goes. To me, the important
thing is the error message. I do think the error "already exists" is a
reasonable one for refs/tags (we do not allow non-force pushes of
existing tags), but not necessarily for other cases, like trying to push
a blob over a blob. The problem there is not "already exists" but rather
"a blob is not something that can fast-forward". Using the existing
REJECT_NONFASTFORWARD is insufficient (because later code will recommend
pull-then-push, which is wrong). So I'd be in favor of creating a new
error status for it.
-Peff
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Jeff King @ 2013-01-21 23:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <7v38xuf6w5.fsf@alter.siamese.dyndns.org>
On Mon, Jan 21, 2013 at 03:33:46PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> It may even make sense to have "git push" honor it, excluding them
> >> from "git push --mirror" (or "git push --all" if some of the
> >> branches are hidden); I haven't thought things through, though.
> >
> > That is harder, as that is something that happens on the client. How
> > does the client learn about the transfer.hiderefs setting on the remote?
>
> No, I was talking about running "git push" from a repository that
> has the transfer.hiderefs set, emulating a fetch from a client by
> pushing out in the reverse direction.
Ah. That seems a bit more questionable to me, as you are assuming that
the face that the repository shows to network clients is the same as it
would show when it is the client itself. That wouldn't be true, for
example, when pushing to a backup repository which would expect to get
everything.
Of course the same problem comes from a backup repository which wants to
fetch from you. Which again comes down to the fact that I think this
ref-hiding is really in the eye of the receiver, not the sender.
-Peff
^ permalink raw reply
* Re: [PATCH v6 0/8] push: update remote tags only with force
From: Junio C Hamano @ 2013-01-21 23:53 UTC (permalink / raw)
To: Jeff King
Cc: Chris Rorvick, Max Horn, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Felipe Contreras
In-Reply-To: <20130121234002.GE17156@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... The problem there is not "already exists" but rather
> "a blob is not something that can fast-forward". Using the existing
> REJECT_NONFASTFORWARD is insufficient (because later code will recommend
> pull-then-push, which is wrong). So I'd be in favor of creating a new
> error status for it.
Very well said.
Please make it so ;-) or should I?
^ permalink raw reply
* Re: [PATCH v3 1/6] Change old system name 'GIT' to 'Git'
From: Junio C Hamano @ 2013-01-22 0:39 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: davvid, git
In-Reply-To: <1335904329.632749.1358795780375.JavaMail.ngmail@webmail20.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
> (as can be seen in the corresponding release note where 'GIT' was
> changed to 'Git' in the header line). So change every occurrence
> of 'GIT" in the documention to 'Git'.
>
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
> ---
This is more about "stop using poor-man's small caps".
I think it misses "GIT - the stupid content tracker" in README, but
probably it is OK (it is not an end-user facing documentation).
I noticed that these two places still use poor-man's small caps
after this patch.
* Documentation/SubmittingPatches:
that are being emailed around. Although core GIT is a lot
* Documentation/git-credential.txt:
TYPICAL USE OF GIT CREDENTIAL
With these two updated, I think it is a sensible change and the
patch is timed reasonably well. It applies to 'maint', and other
topics in flight do not seem to add new uses of GIT.
Not commenting on other 5 patches in the series yet, but if they
interact with other topics in flight, they may have to be separated
out. We'll see.
Thanks.
^ 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