* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Junio C Hamano @ 2013-01-28 18:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jonathan Nieder, git
In-Reply-To: <CAFXTnz6xBMo42jWdqahYX-bnTBucVmQpFPN29X8tGRd7L=g2wQ@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
>> Come to think of it, is there a reason why "for-each-repo" should
>> not be an extention to "submodule foreach"? We can view this as
>> visiting repositories that _could_ be registered as a submodule, in
>> addition to iterating over the registered submodules, no?
>
> Yes, but I see some possible problems with that approach:
> -'git for-each-repo' does not need to be started from within a git worktree
True, but "git submodule foreach --untracked" can be told that it is
OK not (yet) to be in any superproject, no?
> -'git for-each-repo' and 'git submodule foreach' have different
> semantics for --dirty and --clean
That could be a problem. Is there a good reason why they should use
different definitions of dirtyness?
> -'git for-each-repo' is in C because my 'git-all' shell script was
> horribly slow on large directory trees (especially on windows)
Your for-each-repo could be a good basis to build a new builtin
"submodule--foreach" that is a pure helper hidden from the end users
that does both; cmd_foreach() in git-submodule.sh can simply delegate
to it.
> All of these problems are probably solvable, but it would require
> quite some reworking of git-submodule.sh
Of course some work is needed, but we do not have to convert all the
cmd_foo in git-submodule.sh in one step. For the purpose of
unifying for-each-repo and submodule foreach to deliver the
functionality sooner to the end users, we can go the route to add
only the submodule--foreach builtin, out of which we will get
reusable implementation of module_list and other helper functions we
can leverage later to do other cmd_foo functions.
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Lars Hjemli @ 2013-01-28 18:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vham1xktx.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 6:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> As to the pathspec limiting to affect the loop itself, not the
> argument given to the command that is run, I don't think it is
> absolutely needed; I am perfectly fine with declaring that
> for-each-repo goes to repositories in all subdirectories without
> limit, especially if doing so will make the UI issues we have to
> deal with simpler.
Good (since the relative path of each repo will be exported to the
child process, that process can perform path limiting when needed).
> As to the "option to the command, not to the subcommand, -a option",
> I have been assuming that it was a joke patch, but if "git -a grep"
> turns out to be really useful, "submodule foreach" that iterates
> over the submodules may also want to have such a short and sweet
> mechanism. Between "for-each-repo" and "submodule foreach", I do
> not yet have a strong opinion on which one deserves it more.
>
> Come to think of it, is there a reason why "for-each-repo" should
> not be an extention to "submodule foreach"? We can view this as
> visiting repositories that _could_ be registered as a submodule, in
> addition to iterating over the registered submodules, no?
Yes, but I see some possible problems with that approach:
-'git for-each-repo' does not need to be started from within a git worktree
-'git for-each-repo' and 'git submodule foreach' have different
semantics for --dirty and --clean
-'git for-each-repo' is in C because my 'git-all' shell script was
horribly slow on large directory trees (especially on windows)
All of these problems are probably solvable, but it would require
quite some reworking of git-submodule.sh
--
larsh
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Junio C Hamano @ 2013-01-28 18:35 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jonathan Nieder, git
In-Reply-To: <CAFXTnz6zN0izx8S23JFww5niVD6x-r2e7TSthqZnempUrvAEWw@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> On Mon, Jan 28, 2013 at 9:10 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> ...
>> So if I ran the world, then having commands
>>
>> git -a diff
>>
>> and
>>
>> git for-each-repo git diff
>>
>> do the same thing would be fine. Of course I don't run the world. ;-)
>
> This would make me very happy. Junio?
Ahh, our mails crossed (rather, I responded to the other message I
saw before I saw this one). I am not completely sold on "git -a"
yet, but another worry I have is which one between "submodule
foreach" and "for-each-repo" should use "git -a", if we decide that
it is useful to the users to add it.
^ permalink raw reply
* [PATCH] l10n: de.po: translate "reset" as "neu setzen"
From: Ralf Thielow @ 2013-01-28 18:33 UTC (permalink / raw)
To: trast, jojo; +Cc: git, jk, stimming, Ralf Thielow
In-Reply-To: <1359398014-3325-1-git-send-email-ralf.thielow@gmail.com>
According to the glossary, "reset" should be
translated as "neu setzen" but in a couple of
messages we've translated it as "zurücksetzen".
This fixes that.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
Note that the part "neu" is not used in any places because
I think sometimes it sounds better without them.
po/de.po | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/po/de.po b/po/de.po
index 6c7384b..9b1f589 100644
--- a/po/de.po
+++ b/po/de.po
@@ -2764,7 +2764,7 @@ msgstr "Zweigspitze (HEAD) ist jetzt bei"
#: builtin/checkout.c:609
#, c-format
msgid "Reset branch '%s'\n"
-msgstr "Setze Zweig '%s' zurück\n"
+msgstr "Setze Zweig '%s' neu\n"
#: builtin/checkout.c:612
#, c-format
@@ -2774,7 +2774,7 @@ msgstr "Bereits auf '%s'\n"
#: builtin/checkout.c:616
#, c-format
msgid "Switched to and reset branch '%s'\n"
-msgstr "Gewechselt zu zurückgesetztem Zweig '%s'\n"
+msgstr "Gewechselt zu neu gesetztem Zweig '%s'\n"
#: builtin/checkout.c:618 builtin/checkout.c:955
#, c-format
@@ -7900,19 +7900,19 @@ msgstr "weniger Ausgaben, meldet nur Fehler"
#: builtin/reset.c:250
msgid "reset HEAD and index"
-msgstr "setzt Zweigspitze (HEAD) und Bereitstellung zurück"
+msgstr "setzt Zweigspitze (HEAD) und Bereitstellung neu"
#: builtin/reset.c:251
msgid "reset only HEAD"
-msgstr "setzt nur Zweigspitze (HEAD) zurück"
+msgstr "setzt nur Zweigspitze (HEAD) neu"
#: builtin/reset.c:253 builtin/reset.c:255
msgid "reset HEAD, index and working tree"
-msgstr "setzt Zweigspitze (HEAD), Bereitstellung und Arbeitsbaum zurück"
+msgstr "setzt Zweigspitze (HEAD), Bereitstellung und Arbeitsbaum neu"
#: builtin/reset.c:257
msgid "reset HEAD but keep local changes"
-msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen"
+msgstr "setzt Zweigspitze (HEAD) neu, behält aber lokale Änderungen"
#: builtin/reset.c:275
#, c-format
@@ -7952,7 +7952,7 @@ msgstr "'%s' Zurücksetzung ist in einem bloßen Projektarchiv nicht erlaubt"
#: builtin/reset.c:333
#, c-format
msgid "Could not reset index file to revision '%s'."
-msgstr "Konnte Bereitstellungsdatei nicht zu Version '%s' zurücksetzen."
+msgstr "Konnte Bereitstellungsdatei nicht zu Version '%s' setzen."
#: builtin/reset.c:339
msgid "Unstaged changes after reset:"
@@ -8833,7 +8833,7 @@ msgstr "Baut lokale Versionen auf einem aktuellerem externen Zweig neu auf"
#: common-cmds.h:24
msgid "Reset current HEAD to the specified state"
msgstr ""
-"Setzt die aktuelle Zweigspitze (HEAD) zu einem spezifizierten Zustand zurück"
+"Setzt die aktuelle Zweigspitze (HEAD) zu einem spezifizierten Zustand"
#: common-cmds.h:25
msgid "Remove files from the working tree and from the index"
--
1.8.1.1.439.g50a6b54
^ permalink raw reply related
* [PATCH] l10n: de.po: translate "revision" consistently as "Version"
From: Ralf Thielow @ 2013-01-28 18:33 UTC (permalink / raw)
To: trast, jojo; +Cc: git, jk, stimming, Ralf Thielow
In-Reply-To: <1359398014-3325-1-git-send-email-ralf.thielow@gmail.com>
In the German translation, we have translated "revision"
as both "Revision" and "Version". In the context of version
control, revision has the same meaning as commit, so we don't
need to use both terms. "revision" is now consistently translated
as "Version".
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
po/de.po | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/po/de.po b/po/de.po
index ed8330a..6c7384b 100644
--- a/po/de.po
+++ b/po/de.po
@@ -156,7 +156,7 @@ msgstr "Dem Projektarchiv fehlen folgende vorausgesetzte Versionen:"
#: builtin/log.c:751 builtin/log.c:1358 builtin/log.c:1574 builtin/merge.c:347
#: builtin/shortlog.c:157
msgid "revision walk setup failed"
-msgstr "Einrichtung des Revisionsgangs fehlgeschlagen"
+msgstr "Einrichtung des Versionsgangs fehlgeschlagen"
#: bundle.c:186
#, c-format
@@ -2201,7 +2201,7 @@ msgstr "arbeite länger, um bessere Übereinstimmungen zu finden"
#: builtin/blame.c:2380
msgid "Use revisions from <file> instead of calling git-rev-list"
-msgstr "Benutzt Revisionen von <Datei> anstatt \"git-rev-list\" aufzurufen"
+msgstr "Benutzt Versionen von <Datei> anstatt \"git-rev-list\" aufzurufen"
#: builtin/blame.c:2381
msgid "Use <file>'s contents as the final image"
@@ -2832,7 +2832,7 @@ msgstr ""
#: builtin/checkout.c:730
msgid "internal error in revision walk"
-msgstr "interner Fehler im Revisionsgang"
+msgstr "interner Fehler im Versionsgang"
#: builtin/checkout.c:734
msgid "Previous HEAD position was"
@@ -6193,7 +6193,7 @@ msgstr "findet Vorfahren für eine einzelne n-Wege-Zusammenführung"
#: builtin/merge-base.c:100
msgid "list revs not reachable from others"
-msgstr "listet Revisionen auf, die nicht durch Andere erreichbar sind"
+msgstr "listet Versionen auf, die nicht durch Andere erreichbar sind"
#: builtin/merge-base.c:102
msgid "is the first one ancestor of the other?"
@@ -6831,7 +6831,7 @@ msgstr "erzeugt keine leeren Pakete"
#: builtin/pack-objects.c:2481
msgid "read revision arguments from standard input"
-msgstr "liest Argumente bezüglich Revisionen von der Standard-Eingabe"
+msgstr "liest Argumente bezüglich Versionen von der Standard-Eingabe"
#: builtin/pack-objects.c:2483
msgid "limit the objects to those that are not yet packed"
@@ -7917,7 +7917,7 @@ msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen"
#: builtin/reset.c:275
#, c-format
msgid "Failed to resolve '%s' as a valid revision."
-msgstr "Konnte '%s' nicht als gültige Revision auflösen."
+msgstr "Konnte '%s' nicht als gültige Version auflösen."
#: builtin/reset.c:278 builtin/reset.c:286
#, c-format
@@ -8193,7 +8193,7 @@ msgstr ""
"git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order] [--"
"current] [--color[=<Wann>] | --no-color] [--sparse] [--more=<n> | --list | --"
"independent | --merge-base] [--no-name | --sha1-name] [--topics] "
-"[(<Revision> | <glob>)...]"
+"[(<Version> | <glob>)...]"
#: builtin/show-branch.c:10
msgid "git show-branch (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]"
@@ -9440,7 +9440,7 @@ msgstr "Kein \"stash\" gefunden."
#: git-stash.sh:359
#, sh-format
msgid "Too many revisions specified: $REV"
-msgstr "Zu viele Revisionen angegeben: $REV"
+msgstr "Zu viele Versionen angegeben: $REV"
#: git-stash.sh:365
#, sh-format
--
1.8.1.1.439.g50a6b54
^ permalink raw reply related
* [PATCHv2] l10n: de.po: translate 11 new messages
From: Ralf Thielow @ 2013-01-28 18:33 UTC (permalink / raw)
To: trast, jojo; +Cc: git, jk, stimming, Ralf Thielow
In-Reply-To: <1359353699-3987-1-git-send-email-ralf.thielow@gmail.com>
Translate 11 new messages came from git.pot update
in 46bc403 (l10n: Update git.pot (11 new, 7 removed
messages)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Thomas Rast <trast@inf.ethz.ch>
---
po/de.po | 37 ++++++++++++++++++-------------------
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/po/de.po b/po/de.po
index 3779f4c..ed8330a 100644
--- a/po/de.po
+++ b/po/de.po
@@ -5,7 +5,7 @@
#
msgid ""
msgstr ""
-"Project-Id-Version: git 1.8.1\n"
+"Project-Id-Version: git 1.8.2\n"
"Report-Msgid-Bugs-To: Git Mailing List <git@vger.kernel.org>\n"
"POT-Creation-Date: 2013-01-25 12:33+0800\n"
"PO-Revision-Date: 2012-10-02 19:35+0200\n"
@@ -1033,9 +1033,9 @@ msgid "unable to access '%s': %s"
msgstr "konnte nicht auf '%s' zugreifen: %s"
#: wrapper.c:423
-#, fuzzy, c-format
+#, c-format
msgid "unable to access '%s'"
-msgstr "konnte nicht auf '%s' zugreifen: %s"
+msgstr "konnte nicht auf '%s' zugreifen"
#: wrapper.c:434
#, c-format
@@ -2997,14 +2997,14 @@ msgid "Would remove %s\n"
msgstr "Würde %s löschen\n"
#: builtin/clean.c:26
-#, fuzzy, c-format
+#, c-format
msgid "Skipping repository %s\n"
-msgstr "ungültiges Projektarchiv '%s'"
+msgstr "Überspringe Projektarchiv %s\n"
#: builtin/clean.c:27
-#, fuzzy, c-format
+#, c-format
msgid "Would skip repository %s\n"
-msgstr "ungültiges Projektarchiv '%s'"
+msgstr "Würde Projektarchiv %s überspringen\n"
#: builtin/clean.c:28
#, c-format
@@ -3223,9 +3223,8 @@ msgid "--bare and --origin %s options are incompatible."
msgstr "Die Optionen --bare und --origin %s sind inkompatibel."
#: builtin/clone.c:708
-#, fuzzy
msgid "--bare and --separate-git-dir are incompatible."
-msgstr "Die Optionen --bare und --origin %s sind inkompatibel."
+msgstr "Die Optionen --bare und --separate-git-dir sind inkompatibel."
#: builtin/clone.c:721
#, c-format
@@ -5449,7 +5448,7 @@ msgstr "zeigt Quelle"
#: builtin/log.c:104
msgid "Use mail map file"
-msgstr ""
+msgstr "verwendet \"mailmap\"-Datei"
#: builtin/log.c:105
msgid "decorate options"
@@ -5542,7 +5541,7 @@ msgstr "beginnt die Nummerierung der Patches bei <n> anstatt bei 1"
#: builtin/log.c:1114
msgid "mark the series as Nth re-roll"
-msgstr ""
+msgstr "kennzeichnet die Serie als n-te Fassung"
#: builtin/log.c:1116
msgid "Use [<prefix>] instead of [PATCH]"
@@ -7099,6 +7098,8 @@ msgid ""
"Updates were rejected because the destination reference already exists\n"
"in the remote."
msgstr ""
+"Aktualisierungen wurden zurückgewiesen, weil die Zielreferenz bereits\n"
+"im Fernarchiv existiert."
#: builtin/push.c:269
#, c-format
@@ -7841,14 +7842,12 @@ msgstr ""
"git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<Version>]"
#: builtin/reset.c:26
-#, fuzzy
msgid "git reset [-q] <tree-ish> [--] <paths>..."
-msgstr "git reset [-q] <Version> [--] <Pfade>..."
+msgstr "git reset [-q] <Versionsreferenz> [--] <Pfade>..."
#: builtin/reset.c:27
-#, fuzzy
msgid "git reset --patch [<tree-ish>] [--] [<paths>...]"
-msgstr "git reset --patch [<Version>] [--] [<Pfade>...]"
+msgstr "git reset --patch [<Versionsreferenz>] [--] [<Pfade>...]"
#: builtin/reset.c:33
msgid "mixed"
@@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes"
msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen"
#: builtin/reset.c:275
-#, fuzzy, c-format
+#, c-format
msgid "Failed to resolve '%s' as a valid revision."
-msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
+msgstr "Konnte '%s' nicht als gültige Revision auflösen."
#: builtin/reset.c:278 builtin/reset.c:286
#, c-format
@@ -7926,9 +7925,9 @@ msgid "Could not parse object '%s'."
msgstr "Konnte Objekt '%s' nicht parsen."
#: builtin/reset.c:283
-#, fuzzy, c-format
+#, c-format
msgid "Failed to resolve '%s' as a valid tree."
-msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
+msgstr "Konnte '%s' nicht als gültigen Baum auflösen."
#: builtin/reset.c:292
msgid "--patch is incompatible with --{hard,mixed,soft}"
--
1.8.1.1.439.g50a6b54
^ permalink raw reply related
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Junio C Hamano @ 2013-01-28 18:31 UTC (permalink / raw)
To: Matthieu Moy
Cc: Michael J Gruber, git, Jonathan Nieder, Robin Rosenberg,
Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <vpq8v7dw4f5.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I think "add -u && commit" vs "commit -a" you brought up is a good
>> thing to mention, so let's do this.
>
> I'm OK with your proposal. Let me know if you want me to resend.
Thanks for a quick response. As you may have guessed, I am sending
these after running "commit --amend", so ...
>> The inconsistency of 'git add -u' and 'git add -A' are particularly
>
> Nitpick: this should be "inconsistencies" (or "is particularly").
... it is much easier for me to fix these locally instead of getting
a reroll.
Will amend with s/are particularly/is particularly/; thanks.
^ permalink raw reply
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
From: Ramsay Jones @ 2013-01-28 18:29 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Eric Blake, Junio C Hamano, Mark Levedahl, Alex Riesen,
Jason Pyeron, git, Torsten Bögershausen,
Stephen & Linda Smith
In-Reply-To: <20130126010359.GH3341@elie.Belkin>
Jonathan Nieder wrote:
> Throughout git, it is assumed that the WIN32 preprocessor symbol is
> defined on native Windows setups (mingw and msvc) and not on Cygwin.
> On Cygwin, most of the time git can pretend this is just another Unix
> machine, and Windows-specific magic is generally counterproductive.
>
> Unfortunately Cygwin *does* define the WIN32 symbol in some headers.
> Best to rely on a new git-specific symbol NATIVE_WINDOWS instead,
> defined as follows:
>
> #if defined(WIN32) && !defined(__CYGWIN__)
> # define NATIVE_WINDOWS
> #endif
>
> After this change, it should be possible to drop the
> CYGWIN_V15_WIN32API setting without any negative effect.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
If we go with this approach, could we prefix the symbol name with GIT_
in order to reduce the global namespace pollution?
eg GIT_NATIVE_WINDOWS, or GIT_NATIVE_WIN32 or just GIT_WIN32.
(Yeah, I'm not good at choosing names!)
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Matthieu Moy @ 2013-01-28 18:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael J Gruber, git, Jonathan Nieder, Robin Rosenberg,
Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <7v4ni1xjuc.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think "add -u && commit" vs "commit -a" you brought up is a good
> thing to mention, so let's do this.
I'm OK with your proposal. Let me know if you want me to resend.
> The inconsistency of 'git add -u' and 'git add -A' are particularly
Nitpick: this should be "inconsistencies" (or "is particularly").
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Ralf Thielow @ 2013-01-28 18:13 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git, jk, stimming, trast
In-Reply-To: <ke69ta$1e4$1@ger.gmane.org>
On Mon, Jan 28, 2013 at 05:39:27PM +0100, Joachim Schmitz wrote:
> Ralf Thielow wrote:
> >Translate 11 new messages came from git.pot update
> >in 46bc403 (l10n: Update git.pot (11 new, 7 removed
> >messages)).
> >
> >Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
> >---
> > po/de.po | 37 ++++++++++++++++++-------------------
> > 1 file changed, 18 insertions(+), 19 deletions(-)
> >
> >diff --git a/po/de.po b/po/de.po
> >index 3779f4c..ed8330a 100644
> >--- a/po/de.po
> >+++ b/po/de.po
> >@@ -5,7 +5,7 @@
> > #
> > msgid ""
> > msgstr ""
> >-"Project-Id-Version: git 1.8.1\n"
> >+"Project-Id-Version: git 1.8.2\n"
>
> Not "Projekt-Id-Version ..."?
>
I don't think that we need to translate this.
> > #: builtin/reset.c:33
> > msgid "mixed"
> >@@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes"
> > msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale
> >Änderungen"
>
> Not "reset -> setze" and "keep" -> halte (imperativ)?
> Or is the enlish text wrong and should be "resets" and "keeps"
>
All translations which describe an option shown by "git <command> -h"
are (or should be) like this. The reading is like "This option..."
followed by such a messages. That's at least how it's done. I don't think
it sounds bad.
According to the glossary, the translation here is wrong because "reset" is
not "*zurück* setzen" but "neu setzen". I'll fix this (and perhaps other
messages) on a commit on top.
> Bye, Jojo
>
>
> --
> 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: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Junio C Hamano @ 2013-01-28 18:07 UTC (permalink / raw)
To: Michael J Gruber
Cc: Matthieu Moy, git, Jonathan Nieder, Robin Rosenberg,
Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <51067353.2090006@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:
>> 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'.
>
> Since I didn't follow this thread, my first reaction was: "Huh? Aren't
> they treewide?" (for the relative tree)
>
> So, for someone reading just the commit message, it would be helpful to
> say what the others do, i.e. default to the relative tree at pwd (rather
> than defaulting to an empty tree, or all files whether tracked or not,
> or...).
I think "add -u && commit" vs "commit -a" you brought up is a good
thing to mention, so let's do this. Another tweak is that I did
s/filepattern/pathspec/ here. I know that both the documentation
and the help text for "git add" say filepattern, but we say pathspec
starting from glossary fairly consistently everywhere in the rest of
the system.
We should probably update the documentation/help for "git add", but
that is entirely a separate topic.
add: warn when -u or -A is used without pathspec
Most Git commands that can be used with or without pathspec operate
tree-wide by default, the pathspec being used to restrict their
scope. A few exceptions are: 'git grep', 'git clean', 'git add -u'
and 'git add -A'. When run in a subdirectory without pathspec, they
operate only on paths in the current directory.
The inconsistency 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. It also means that "git
add -u && git commit" will record a state that is different from
what is recorded with "git commit -a".
Flipping the default now is unacceptable, so let's start training
users to type 'git add -u|-A :/' or 'git add -u|-A .' explicitly, to
prepare for the next steps:
* forbid 'git add -u|-A' without pathspec (like 'git add' without
option)
* much later, maybe, re-allow 'git add -u|-A' without pathspec, that
will add all tracked and modified files, or all files, tree-wide.
A nice side effect of this patch is that it makes the :/ magic
pathspec easier to discover for users.
When the command is called from the root of the tree, there is no
ambiguity and no need to change the behavior, hence no need to warn.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Ralf Thielow @ 2013-01-28 17:55 UTC (permalink / raw)
To: Thomas Rast; +Cc: jk, stimming, git
In-Reply-To: <87sj5l38d6.fsf@pctrast.inf.ethz.ch>
On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote:
> Ralf Thielow <ralf.thielow@gmail.com> writes:
>
> > #: builtin/reset.c:275
> > -#, fuzzy, c-format
> > +#, c-format
> > msgid "Failed to resolve '%s' as a valid revision."
> > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
> > +msgstr "Konnte '%s' nicht als gültige Revision auflösen."
>
> You don't have "revision" in the glossary[1] yet. Wouldn't it be
> appropriate to treat it as "commit", and translate as "Version" to avoid
> introducing yet another term?
>
> Or am I missing some subtle distinction between commit and revision?
>
I don't think there's a distinction. Since we've already translated
"revision" as "Revision" in a couple of other messages, I'll make a
new "s/Revision/Version" commit on top.
> Since it's only a single nit, feel free to add my ack when you reroll:
>
> Acked-by: Thomas Rast <trast@inf.ethz.ch>
>
>
> [1] https://github.com/ralfth/git-po-de/wiki/Glossary
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] fixup! git-remote-testpy: fix path hashing on Python 3
From: Junio C Hamano @ 2013-01-28 17:53 UTC (permalink / raw)
To: John Keeping; +Cc: Michael Haggerty, git, Sverre Rabbelier
In-Reply-To: <20130128112043.GZ7498@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> ---
> On Mon, Jan 28, 2013 at 11:44:34AM +0100, Michael Haggerty wrote:
>> NAK. It is still not right. If the locale is not utf-8 based, then it
>> is incorrect to re-encode the string using utf-8. I think you really
>> have to use sys.getfilesystemencoding() as I suggested.
>
> If you'd asked me what the patch contained I would have said it did use
> getfilesystemencoding(), but I can't disbelieve my own eyes :-(
>
> Junio, please can you squash this in?
Sure. Thanks for double-checking, Michael. I knew there was
something missing but I didn't spot the difference myself.
> git-remote-testpy.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-remote-testpy.py b/git-remote-testpy.py
> index 6098bdd..ca67899 100644
> --- a/git-remote-testpy.py
> +++ b/git-remote-testpy.py
> @@ -49,7 +49,7 @@ def encode_filepath(path):
> """
> if sys.hexversion < 0x03000000:
> return path
> - return path.encode('utf-8', 'surrogateescape')
> + return path.encode(sys.getfilesystemencoding(), 'surrogateescape')
>
>
> def get_repo(alias, url):
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Junio C Hamano @ 2013-01-28 17:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Manlio Perillo, wookietreiber, git
In-Reply-To: <5106A5CE.3000800@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Manlio Perillo venit, vidit, dixit 28.01.2013 15:02:
>> Please, test it and report any behaviour you think is incorrect.
>
> OK, that seems to work and to be quite helpful.
>
> Minor nit: "git add -u" could use the same fileset as "git commit". But
> I don't know whether completion can act upon the presence of options.
> Currently, it also includes untracked files (just like without -u) but
> omits unmodified and ignored ones, which is already quite an improvement.
>
> I won't be able to review the completion code but may contribute a few
> lines to t/t9902-completion.sh, possibly.
Thanks both for commenting. I'll find time to read it over again
and perhaps we can merge it to 'next' and advertise it in the next
issue of "What's cooking" report to ask for wider testing to move it
forward.
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Junio C Hamano @ 2013-01-28 17:45 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Lars Hjemli, git
In-Reply-To: <20130128081006.GA2434@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Tracing backwards: it would be really nice to be able to do
>
> git for-each-repo git grep -e foo -- '*.c'
This is a very good example that shows the command that is run in
the repositories found may want pathspecs passed, but at the same
time, makes me realize that these repositories have to be fairly
uniform for this command to be useful. For example, 'src/*.c' or
'inc/*.h' pathspecs wouldn't be useful unless majority if not all
projects the loop finds follow that layout convention. This is not
necessarily limited to pathspecs, of course. Unless they all have
the 'next' branch "git for-each-repo checkout next" would not work,
etc. etc.
As to the pathspec limiting to affect the loop itself, not the
argument given to the command that is run, I don't think it is
absolutely needed; I am perfectly fine with declaring that
for-each-repo goes to repositories in all subdirectories without
limit, especially if doing so will make the UI issues we have to
deal with simpler.
As to the "option to the command, not to the subcommand, -a option",
I have been assuming that it was a joke patch, but if "git -a grep"
turns out to be really useful, "submodule foreach" that iterates
over the submodules may also want to have such a short and sweet
mechanism. Between "for-each-repo" and "submodule foreach", I do
not yet have a strong opinion on which one deserves it more.
Come to think of it, is there a reason why "for-each-repo" should
not be an extention to "submodule foreach"? We can view this as
visiting repositories that _could_ be registered as a submodule, in
addition to iterating over the registered submodules, no?
If these two are unified, then we do not have to even worry about
which one deserves "git -a" more.
^ permalink raw reply
* Bug, feature, or pilot error: format-patch
From: Gene Czarcinski @ 2013-01-28 17:03 UTC (permalink / raw)
To: Git
I am not on the mailing list so please CC me. I am running git 1.8.1 on
Fedora 18.
I aam having what appears to be a problem. Here is the sequence which
generally describes what I did and what happened:
git checkout -b test1 master
git am 0001-simple-1.patch
git checkout -b test2 master
git am 0001-simple-2.patch ### this is known to conflict
with 0001-simple-1.patch
git checkout test1
git merge test2
[here git-merge detects a conflict]
git mergetool ###to resolve the conflict
[conflict resolved]
git commit -a -s
git log
[shows two commits -- one for simple-2 and one for the merge]
git format-patch master..HEAD
[two patch files created: 0001-simple-1.patch and 0002-simple-2.patch]
[0002-simple-2.patch and 0001-simple-2.patch are exactly equal and do
not reflect the resolved conflict]
If you do git-diff between <commit-patch-1> and HEAD, you get something
different that you got from format-patch.
1. Bug ... format-patch is broken
2. Feature ... that is the way it works
3. Pilot error ... ??
I can create a good version of patch-2 manually but should I have to?
Color me foolish but I assumed I could do git-format-patch in one branch
and then use git-am to recreate that branch elsewhere.
Gene
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Lars Hjemli @ 2013-01-28 17:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git
In-Reply-To: <20130128081006.GA2434@elie.Belkin>
On Mon, Jan 28, 2013 at 9:10 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Lars Hjemli wrote:
>
>> [1] The 'git -a' rewrite patch shows how I think about this command -
>> it's just an option to the 'git' command, modifying the way any
>> subcommand is invoked (btw: I don't expect that patch to be applied
>> since 'git-all' was deemed to generic, so I'll just carry the patch in
>> my own tree).
>
> As one data point, 'git all' also seems too generic to me but 'git -a'
> doesn't. Intuition can be weird.
>
> So if I ran the world, then having commands
>
> git -a diff
>
> and
>
> git for-each-repo git diff
>
> do the same thing would be fine. Of course I don't run the world. ;-)
This would make me very happy. Junio?
--
larsh
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Joachim Schmitz @ 2013-01-28 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <1359353699-3987-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow wrote:
> Translate 11 new messages came from git.pot update
> in 46bc403 (l10n: Update git.pot (11 new, 7 removed
> messages)).
>
> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
> ---
> po/de.po | 37 ++++++++++++++++++-------------------
> 1 file changed, 18 insertions(+), 19 deletions(-)
>
> diff --git a/po/de.po b/po/de.po
> index 3779f4c..ed8330a 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -5,7 +5,7 @@
> #
> msgid ""
> msgstr ""
> -"Project-Id-Version: git 1.8.1\n"
> +"Project-Id-Version: git 1.8.2\n"
Not "Projekt-Id-Version ..."?
> #: builtin/reset.c:33
> msgid "mixed"
> @@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes"
> msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale
> Änderungen"
Not "reset -> setze" and "keep" -> halte (imperativ)?
Or is the enlish text wrong and should be "resets" and "keeps"
Bye, Jojo
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Michael J Gruber @ 2013-01-28 16:22 UTC (permalink / raw)
To: Manlio Perillo; +Cc: Junio C Hamano, wookietreiber, git
In-Reply-To: <510684FB.80104@gmail.com>
Manlio Perillo venit, vidit, dixit 28.01.2013 15:02:
> Il 28/01/2013 13:52, Michael J Gruber ha scritto:
>> Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
>>> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>>>> wookietreiber <kizkizzbangbang@googlemail.com> writes:
>>>
>>>>> I have a feature request for `git add` auto completion:
>>>>>
>> [...]
>>> For the OP: the last patch can be found in the mailing list archive,
>>> with the subject:
>>> [PATCH v5] git-completion.bash: add support for path completion
>>> and date:
>>> Fri, 11 Jan 2013 19:48:43 +0100
>>>
>>> Can you please test it?
>>>
>
>> I haven't looked at the patch, but in the example above, untracked
>> files) could be added as well (unless you use -u), so maybe the scope
>> should depend on the option? If the new completion code kept me from
>> adding untracked files easily it wouldn't be an improvement.
>
>
> The patch will suggest (for git add command), all the files that are
> candidate to be added to the index file.
>
> Please, test it and report any behaviour you think is incorrect.
OK, that seems to work and to be quite helpful.
Minor nit: "git add -u" could use the same fileset as "git commit". But
I don't know whether completion can act upon the presence of options.
Currently, it also includes untracked files (just like without -u) but
omits unmodified and ignored ones, which is already quite an improvement.
I won't be able to review the completion code but may contribute a few
lines to t/t9902-completion.sh, possibly.
Michael
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 14:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, wookietreiber, git
In-Reply-To: <51067487.9050505@drmicha.warpmail.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 13:52, Michael J Gruber ha scritto:
> Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
>> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>>> wookietreiber <kizkizzbangbang@googlemail.com> writes:
>>
>>>> I have a feature request for `git add` auto completion:
>>>>
> [...]
>> For the OP: the last patch can be found in the mailing list archive,
>> with the subject:
>> [PATCH v5] git-completion.bash: add support for path completion
>> and date:
>> Fri, 11 Jan 2013 19:48:43 +0100
>>
>> Can you please test it?
>>
>
> I haven't looked at the patch, but in the example above, untracked
> files) could be added as well (unless you use -u), so maybe the scope
> should depend on the option? If the new completion code kept me from
> adding untracked files easily it wouldn't be an improvement.
>
The patch will suggest (for git add command), all the files that are
candidate to be added to the index file.
Please, test it and report any behaviour you think is incorrect.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEGhPsACgkQscQJ24LbaUTYOwCdFagTRkHzUHoFwy3U+Vz6tAzE
tVIAnj8fAbyGrlNUoUgI4ZshwOtlEH8v
=jy8R
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Michael J Gruber @ 2013-01-28 12:52 UTC (permalink / raw)
To: Manlio Perillo; +Cc: Junio C Hamano, wookietreiber, git
In-Reply-To: <5106444F.2040007@gmail.com>
Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>> wookietreiber <kizkizzbangbang@googlemail.com> writes:
>
>>> I have a feature request for `git add` auto completion:
>>>
>>> `git add` auto completion suggests all files / directories,
>>> filtered by nothing. I guess it would be much nicer (as in
>>> increasing productivity) if it would only suggest unstaged
>>> content, as reported by `git status`, because that would be the
>>> only content one would be able to add.
>
>> I think that is what Manlio Perillo tried to do with the stalled
>> mp/complete-paths topic that is queued in 'pu'.
>
>> Manlio, any progress?
>
> Well, I assumed that the patch was stalled due to missing review from
> git completion experts...
>
> For this reason I have not updated it with your latest suggestions,
> waiting for the review (also, because now I'm busy with other projects).
>
> For the OP: the last patch can be found in the mailing list archive,
> with the subject:
> [PATCH v5] git-completion.bash: add support for path completion
> and date:
> Fri, 11 Jan 2013 19:48:43 +0100
>
> Can you please test it?
>
>
>
>
> Regards Manlio
>
I haven't looked at the patch, but in the example above, untracked
files) could be added as well (unless you use -u), so maybe the scope
should depend on the option? If the new completion code kept me from
adding untracked files easily it wouldn't be an improvement.
Michael
^ permalink raw reply
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Michael J Gruber @ 2013-01-28 12:47 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, gitster, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki,
Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <1359364593-10933-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:
> 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'.
Since I didn't follow this thread, my first reaction was: "Huh? Aren't
they treewide?" (for the relative tree)
So, for someone reading just the commit message, it would be helpful to
say what the others do, i.e. default to the relative tree at pwd (rather
than defaulting to an empty tree, or all files whether tracked or not,
or...).
Otherwise, I'd rather switch sooner than later; it's so easy to take
"git add -u && git commit == git commit -a" for granted and to miss
staging some hunks. But 2.0 is around the corner anyway, isn't it ;)
> The inconsistency 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.
>
> A nice side effect of this patch is that it makes the :/ special
> filepattern easier to discover for users.
>
> When the command is called from the root of the tree, there is no
> ambiguity and no need to change the behavior, hence no need to warn.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> Changes since v2:
>
> * Typo consistant -> consistent
>
> * Mention both short and long option names (Thanks Junio). I went for
> a two-lines display which I find a bit nicer to read than Junio's
> version, but I'm fine with both.
>
> Documentation/git-add.txt | 7 ++++---
> builtin/add.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index fd9e36b..5333559 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
> from the index if the corresponding files in the working tree
> have been removed.
> +
> -If no <filepattern> is given, default to "."; in other words,
> -update all tracked files in the current directory and its
> -subdirectories.
> +If no <filepattern> is given, the current version of Git defaults to
> +"."; in other words, update all tracked files in the current directory
> +and its subdirectories. This default will change in a future version
> +of Git, hence the form without <filepattern> should not be used.
>
> -A::
> --all::
> diff --git a/builtin/add.c b/builtin/add.c
> index 7cb6cca..7738025 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags)
> return exit_status;
> }
>
> +static void warn_pathless_add(const char *option_name, const char *short_name) {
> + /*
> + * To be consistent 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 (or %s)' with no path argument from a\n"
> + "subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n"
> + "To add content for the whole tree, run:\n"
> + "\n"
> + " git add %s :/\n"
> + " (or git add %s :/)\n"
> + "\n"
> + "To restrict the command to the current directory, run:\n"
> + "\n"
> + " git add %s .\n"
> + " (or git add %s .)\n"
> + "\n"
> + "With the current Git version, the command is restricted to the current directory."),
> + option_name, short_name,
> + option_name, short_name,
> + option_name, short_name);
> +}
> +
> int cmd_add(int argc, const char **argv, const char *prefix)
> {
> int exit_status = 0;
> @@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> int add_new_files;
> int require_pathspec;
> char *seen = NULL;
> + const char *option_with_implicit_dot = NULL;
> + const char *short_option_with_implicit_dot = NULL;
>
> git_config(add_config, NULL);
>
> @@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> die(_("-A and -u are mutually incompatible"));
> if (!show_only && ignore_missing)
> die(_("Option --ignore-missing can only be used together with --dry-run"));
> - if ((addremove || take_worktree_changes) && !argc) {
> + if (addremove) {
> + option_with_implicit_dot = "--all";
> + short_option_with_implicit_dot = "-A";
> + }
> + if (take_worktree_changes) {
> + option_with_implicit_dot = "--update";
> + short_option_with_implicit_dot = "-u";
> + }
> + if (option_with_implicit_dot && !argc) {
> static const char *here[2] = { ".", NULL };
> + if (prefix)
> + warn_pathless_add(option_with_implicit_dot,
> + short_option_with_implicit_dot);
> argc = 1;
> argv = here;
> }
>
^ permalink raw reply
* [PATCH] fixup! git-remote-testpy: fix path hashing on Python 3
From: John Keeping @ 2013-01-28 11:20 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Sverre Rabbelier
In-Reply-To: <51065692.9000708@alum.mit.edu>
---
On Mon, Jan 28, 2013 at 11:44:34AM +0100, Michael Haggerty wrote:
> NAK. It is still not right. If the locale is not utf-8 based, then it
> is incorrect to re-encode the string using utf-8. I think you really
> have to use sys.getfilesystemencoding() as I suggested.
If you'd asked me what the patch contained I would have said it did use
getfilesystemencoding(), but I can't disbelieve my own eyes :-(
Junio, please can you squash this in?
git-remote-testpy.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index 6098bdd..ca67899 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -49,7 +49,7 @@ def encode_filepath(path):
"""
if sys.hexversion < 0x03000000:
return path
- return path.encode('utf-8', 'surrogateescape')
+ return path.encode(sys.getfilesystemencoding(), 'surrogateescape')
def get_repo(alias, url):
--
1.8.1.1
^ permalink raw reply related
* [CLOSED FIXED] Bug: file named - on git commit
From: Rene Moser @ 2013-01-28 11:19 UTC (permalink / raw)
To: git
In-Reply-To: <87txq11sbk.fsf@pctrast.inf.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 289 bytes --]
On 01/28/2013 12:05 PM, Thomas Rast wrote:
> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
> need to read blob from the standard input, 2012-06-27), which is
> included starting with v1.7.12 and the v1.7.11.3 maint release. Please
> upgrade.
Thanks.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Thomas Rast @ 2013-01-28 11:05 UTC (permalink / raw)
To: Rene Moser; +Cc: git
In-Reply-To: <51065540.1090007@renemoser.net>
Rene Moser <mail@renemoser.net> writes:
>
> Found a little issue in git version 1.7.9.5 if a file named "-", causing
> "git commit" to read from stdin.
>
> (So you must hit ctrl-d or ctrl-c to finish the commit.)
>
> Everything looks ok to me after the commit. Other users reported to be
> fixed in 1.8.1.1 but haven't it tested myself.
>
> This does not work:
>
> mkdir tmp && cd tmp;
> echo foo >./-;
> git init; git add .;
> git commit -m "is this a bug?"
This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
need to read blob from the standard input, 2012-06-27), which is
included starting with v1.7.12 and the v1.7.11.3 maint release. Please
upgrade.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ 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