* 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] 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: [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 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 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: 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/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: 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
* [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
* [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
* [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
* 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
* 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: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
* [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Andrej Andb @ 2013-01-28 19:14 UTC (permalink / raw)
To: git; +Cc: Andrej Andb
---
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c6bafe6..1309196 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2068,7 +2068,7 @@ sub picon_url {
if (!$avatar_cache{$email}) {
my ($user, $domain) = split('@', $email);
$avatar_cache{$email} =
- "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
+ "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
"$domain/$user/" .
"users+domains+unknown/up/single";
}
@@ -2083,7 +2083,7 @@ sub gravatar_url {
my $email = lc shift;
my $size = shift;
$avatar_cache{$email} ||=
- "http://www.gravatar.com/avatar/" .
+ "//www.gravatar.com/avatar/" .
Digest::MD5::md5_hex($email) . "?s=";
return $avatar_cache{$email} . $size;
}
--
1.8.1.1
^ permalink raw reply related
* [PATCH] fixup! mergetools: simplify how we handle "vim" and "defaults"
From: John Keeping @ 2013-01-28 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Aguilar
---
Junio, please can you squash this into f9924e5 on jk/mergetool,
providing that David is OK with that?
The original change breaks custom mergetool by making changing the logic
around default functions so that they are now only defined when the tool
file exists in $MERGE_TOOLS_DIR but we need the default implementations
when a custom tool is in use, which by definition means that the file
doesn't exist in $MERGE_TOOLS_DIR.
git-mergetool--lib.sh | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 1d0fb12..211ffe5 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -48,15 +48,6 @@ valid_tool () {
setup_tool () {
tool="$1"
- if ! test -f "$MERGE_TOOLS_DIR/$tool"
- then
- # Use a special return code for this case since we want to
- # source "defaults" even when an explicit tool path is
- # configured since the user can use that to override the
- # default path in the scriptlet.
- return 2
- fi
-
# Fallback definitions, to be overriden by tools.
can_merge () {
return 0
@@ -80,6 +71,15 @@ setup_tool () {
echo "$1"
}
+ if ! test -f "$MERGE_TOOLS_DIR/$tool"
+ then
+ # Use a special return code for this case since we want to
+ # source "defaults" even when an explicit tool path is
+ # configured since the user can use that to override the
+ # default path in the scriptlet.
+ return 2
+ fi
+
# Load the redefined functions
. "$MERGE_TOOLS_DIR/$tool"
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
From: John Keeping @ 2013-01-28 19:37 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <1359334346-5879-4-git-send-email-davvid@gmail.com>
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
> Refactor show_tool_help() so that the tool-finding logic is broken out
> into a separate show_tool_names() function.
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
> filter_tools renamed to show_tool_names() and simplfied
> to use ls -1. show_tool_names() now has a preamble as discussed.
>
> git-mergetool--lib.sh | 68 +++++++++++++++++++++++++++++----------------------
> 1 file changed, 39 insertions(+), 29 deletions(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index db3eb58..fe068f6 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -2,6 +2,35 @@
> # git-mergetool--lib is a library for common merge tool functions
> MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
>
> +mode_ok () {
> + diff_mode && can_diff ||
> + merge_mode && can_merge
> +}
> +
> +is_available () {
> + merge_tool_path=$(translate_merge_tool_path "$1") &&
> + type "$merge_tool_path" >/dev/null 2>&1
> +}
> +
Can we move show_tool_names() to be above show_tool_help()? It's a
very minor nit but I prefer having related functionality grouped
together.
> +show_tool_names () {
> + condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
Would this be better with one value on each line? Also perhaps
per_line_prefix -> line_prefix.
> +
> + ( cd "$MERGE_TOOLS_DIR" && ls -1 * ) |
> + while read toolname
> + do
> + if setup_tool "$toolname" 2>/dev/null &&
> + (eval "$condition" "$toolname")
> + then
> + if test -n "$preamble"
> + then
> + echo "$preamble"
> + preamble=
> + fi
> + printf "%s%s\n" "$per_line_prefix" "$tool"
This needs to be:
printf "$per_line_prefix%s\n" "$tool"
since $per_line_prefix is usually '\t\t' which isn't expanded if we
format it with %s - an alternative would be to change the value passed
in to '$TAB$TAB' with literal tabs.
> + fi
> + done
> +}
> +
> diff_mode() {
> test "$TOOL_MODE" = diff
> }
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Lars Hjemli @ 2013-01-28 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vr4l5w385.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 7:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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?
Yes.
>
>> -'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?
I suspected that 'submodule foreach --dirty' might want to compare the
HEAD sha1 in the submodule against the one recorded in the
superproject (similar to what 'git submodule status' does), but such a
check could be triggered by a different flag (e.g. --behind/--ahead or
something similar).
>> -'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.
Ok, I'll rework my patches in this direction. Thanks.
--
larsh
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 20:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, wookietreiber, git
In-Reply-To: <5106A5CE.3000800@drmicha.warpmail.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 17:22, Michael J Gruber ha scritto:
> [...]
>> 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.
It is possible, but I have not implemented since I was not sure about it
and I wanted to avoid to make the patch more hard to review.
I will work on it after the patch is approved.
> 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.
>
Ah, I missed this test; thanks.
The proposed patch must update it.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEG2+UACgkQscQJ24LbaURstACfdNxuFvaokBSTls20bSQ7jPHA
8I0An3fX6oRKuc2lzAgPVBLjsbjbw91V
=igwr
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Jens Lehmann @ 2013-01-28 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, Jonathan Nieder, git, Heiko Voigt
In-Reply-To: <7vr4l5w385.fsf@alter.siamese.dyndns.org>
Am 28.01.2013 19:51, schrieb Junio C Hamano:
> 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?
Hmm, I'm not sure how that would work as it looks for gitlinks
in the index which point to work tree paths.
>> -'git for-each-repo' and 'git submodule foreach' have different
>> semantics for --dirty and --clean
I'm confused, what semantics of --dirty and --clean does current
'git submodule foreach' have? I can't find any sign of it in the
current code ... did I miss something while skimming through this
thread? Or are you talking about status and diff here?
> That could be a problem. Is there a good reason why they should use
> different definitions of dirtyness?
I don't see any (except of course for comparing a gitlink with the
HEAD of the submodule, which is an additional condition that only
applies to submodules). But I think the current for-each-repo
proposal doesn't allow to traverse repos which contain untracked
content (and it would be nice if the user could somehow combine
that with the current --dirty flag to have both in one go).
>> -'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.
I like that approach, because the operations are very similar from
the user's point of view. But please remember that internally they
would work differently, as submodule foreach walks the index and
only descends into those submodules that are populated (and contain
a .git directory or file) while for-each-repo scans the whole work
tree, which makes it a more expensive operation.
>> 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.
I really like that idea!
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 20:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, wookietreiber, git
In-Reply-To: <7vd2wpxki1.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 18:52, Junio C Hamano ha scritto:
> [...]
>
> 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.
Thanks.
I will try to update the patch, with your latest suggestions (avoid
tricky POSIX shell syntax, and CDPATH issue - if I remember correctly),
and with an update for the t/t9902-completion.sh test (that I completely
missed).
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEG3IcACgkQscQJ24LbaUTR/wCfSC/kHxseKAQ9rnK2ba/WwND1
cmsAn2CuHpRs2VjippTwkT5O3ul9cQKb
=5Way
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Philip Oakley @ 2013-01-28 20:33 UTC (permalink / raw)
To: Ralf Thielow, Thomas Rast; +Cc: jk, stimming, Git List
In-Reply-To: <20130128175514.GA2926@rath-ubuntu>
From: "Ralf Thielow" <ralf.thielow@gmail.com>
Sent: Monday, January 28, 2013 5:55 PM
> 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.
It was a problem I had http://stackoverflow.com/a/11792712/717355
answered as:
See "SPECIFYING REVISIONS" of git rev-parse:
A revision parameter <rev> typically, but not necessarily, names a
commit object.
It uses what is called an extended SHA1 syntax, [and includes] various
ways to spell object names.
It had me confused for a while.
> 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
> --
Philip Oakley
^ 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 20:34 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Lars Hjemli, Jonathan Nieder, git, Heiko Voigt
In-Reply-To: <5106DBB7.70007@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 28.01.2013 19:51, schrieb Junio C Hamano:
>> 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?
>
> Hmm, I'm not sure how that would work as it looks for gitlinks
> in the index which point to work tree paths.
I was imagining that "foreach --untracked" could go something like this:
* If you are inside an existing git repository, read its index to
learn the gitlinks in the directory and its subdirectories.
* Start from the current directory and recursively apply the
procedure in this step:
* Scan the directory and iterate over the ones that has ".git" in
it:
* If it is a gitlinked one, show it, but do not descend into it
unless --recursive is given (e.g. you start from /home/jens,
find /home/jens/proj/ directory that has /home/jens/proj/.git
in it. /home/jens/.git/index knows that it is a submodule of
the top-level superproject. "proj" is handled, and it is up
to the --recursive option if its submodules are handled).
* If it is _not_ a gitlinked one, show it and descend into it
(e.g. /home/jens/ is not a repository or /home/jens/proj is
not a tracked submodule) to apply this procedure recursively.
Of course, without --untracked, we have no need to iterate over the
readdir() return values; instead we just scan the index of the
top-level superproject.
>>> -'git for-each-repo' and 'git submodule foreach' have different
>>> semantics for --dirty and --clean
>
> I'm confused, what semantics of --dirty and --clean does current
> 'git submodule foreach' have? I can't find any sign of it in the
> current code ... did I miss something while skimming through this
> thread? Or are you talking about status and diff here?
I think Lars is hinting that "submodule foreach" could restrict its
operation to a similar --dirty/--clean/--both option he has. Of
course, the command given to foreach can decide to become no-op by
inspecting the submodule itself, so in that sense, --dirty/--clean
can be done without, but I think it would make sense to have it in
"submodule foreach" even without the "--untracked" option.
> But I think the current for-each-repo
> proposal doesn't allow to traverse repos which contain untracked
> content (and it would be nice if the user could somehow combine
> that with the current --dirty flag to have both in one go).
Perhaps. I personally felt it was really strange that submodule
diff and status consider that it is a sin to have untracked and
unignored cruft in the submodule working tree, though.
^ permalink raw reply
* Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
From: Junio C Hamano @ 2013-01-28 20:36 UTC (permalink / raw)
To: John Keeping; +Cc: David Aguilar, git
In-Reply-To: <20130128193700.GB7498@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
>> + printf "%s%s\n" "$per_line_prefix" "$tool"
>
> This needs to be:
>
> printf "$per_line_prefix%s\n" "$tool"
>
> since $per_line_prefix is usually '\t\t' which isn't expanded if we
> format it with %s - an alternative would be to change the value passed
> in to '$TAB$TAB' with literal tabs.
I would prefer the latter, actually. I do understand the
convenience of being able to write backslash-t, but I do not think
it outweighs the potential risk of mistakingly passing a string with
per-cent in it.
^ permalink raw reply
* [ANNOUNCE] Git v1.8.1.2
From: Junio C Hamano @ 2013-01-28 20:41 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v1.8.1.2 is now available at the
usual places. This contains a handful of fixes that will also
appear in the next feature release.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
29a2dee568b1f86e9d3d8f9dcc376f24439b6a0c git-1.8.1.2.tar.gz
3df491003d026b8f4b2de378e57b930a98f0a595 git-htmldocs-1.8.1.2.tar.gz
142222a27dfec52256831f2d0e2ee655f75c1077 git-manpages-1.8.1.2.tar.gz
Also the following public repositories all have a copy of the v1.8.1.2
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git 1.8.1.2 Release Notes
=========================
Fixes since v1.8.1.1
--------------------
* An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* Command line completion for "tcsh" emitted an unwanted space
after completing a single directory name.
* Command line completion leaked an unnecessary error message while
looking for possible matches with paths in <tree-ish>.
* "git archive" did not record uncompressed size in the header when
streaming a zip archive, which confused some implementations of unzip.
* When users spelled "cc:" in lowercase in the fake "header" in the
trailer part, "git send-email" failed to pick up the addresses from
there. As e-mail headers field names are case insensitive, this
script should follow suit and treat "cc:" and "Cc:" the same way.
Also contains various documentation fixes.
----------------------------------------------------------------
Changes since v1.8.1.1 are as follows:
Antoine Pelisse (3):
dir.c: Make git-status --ignored more consistent
git-status: Test --ignored behavior
status: always report ignored tracked directories
Dylan Smith (1):
git-completion.bash: silence "not a valid object" errors
Eric S. Raymond (1):
Remove the suggestion to use parsecvs, which is currently broken.
John Keeping (1):
git-for-each-ref.txt: 'raw' is a supported date format
Jonathan Nieder (1):
contrib/vim: simplify instructions for old vim support
Junio C Hamano (2):
Start preparing for 1.8.1.2
Git 1.8.1.2
Marc Khouzam (1):
Prevent space after directories in tcsh completion
Michael Haggerty (8):
Introduce new static function real_path_internal()
real_path_internal(): add comment explaining use of cwd
Introduce new function real_path_if_valid()
longest_ancestor_length(): use string_list_split()
longest_ancestor_length(): take a string_list argument for prefixes
longest_ancestor_length(): require prefix list entries to be normalized
setup_git_directory_gently_1(): resolve symlinks in ceiling paths
string_list_longest_prefix(): remove function
Nguyễn Thái Ngọc Duy (1):
attr: make it build with DEBUG_ATTR again
Nickolai Zeldovich (1):
git-send-email: treat field names as case-insensitively
Peter Eisentraut (1):
git-commit-tree(1): correct description of defaults
René Scharfe (5):
archive-zip: write uncompressed size into header even with streaming
t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
t0024, t5000: use test_lazy_prereq for UNZIP
t5000, t5003: move ZIP tests into their own script
t5003: check if unzip supports symlinks
Sebastian Staudt (1):
config.txt: Document help.htmlpath config parameter
^ 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