* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: Junio C Hamano @ 2013-01-28 2:53 UTC (permalink / raw)
To: David Aguilar; +Cc: git, John Keeping
In-Reply-To: <CAJDDKr75K3RGgU79nrznbpjQMLQGkDs=W8XEofURNsS1X1bvjg@mail.gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Okay, cool, so no need to reroll, ya?
It was more like "please don't switch to incremental yet"; I tweaked
the mode_ok in your v2 and pushed out the result on 'pu' again.
There may later be comments from others that make us realize some
patches need to be rerolled, but nothing from me for now.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 07/11] sequencer.c: teach append_signoff how to detect duplicate s-o-b
From: Jonathan Nieder @ 2013-01-28 3:08 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, pclouds, gitster, Brandon Casey
In-Reply-To: <1359335515-13818-8-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
This replaces the previous (slightly broken) logic that checked
whether the sign-off to be appended would be redundant and puts the
fixed logic further down the call-chain next to the rest of footer
parsing.
I am not thrilled with the
0 = no rfc-style footer
1 = rfc-style footer, no sign-off found
2 = rfc-style footer, sign-off found but not as last field
3 = rfc-style footer, sign-off found as last field
convention but since it's local to sequencer.c and this logic to scan
all lines for the sign-off can probably be ripped out soon I don't
mind.
The general direction is good and the execution looks obviously
correct.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: [PATCH v3 07/11] sequencer.c: teach append_signoff how to detect duplicate s-o-b
From: Jonathan Nieder @ 2013-01-28 3:14 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, pclouds, gitster, Brandon Casey
In-Reply-To: <1359335515-13818-8-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> --- a/sequencer.c
> +++ b/sequencer.c
[...]
> @@ -1096,10 +1117,16 @@ void append_signoff(struct strbuf *msgbuf, int ignore_footer)
> strbuf_addch(&sob, '\n');
> for (i = msgbuf->len - 1 - ignore_footer; i > 0 && msgbuf->buf[i - 1] != '\n'; i--)
> ; /* do nothing */
> - if (prefixcmp(msgbuf->buf + i, sob.buf)) {
> - if (!i || !has_conforming_footer(msgbuf, ignore_footer))
> - strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0, "\n", 1);
> - strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0, sob.buf, sob.len);
> - }
> +
> + if (i)
> + has_footer = has_conforming_footer(msgbuf, &sob, ignore_footer);
Is this "if (i)" test needed? I'd expect that if the message has no newlines,
has_conforming_footer() would notice that and return 0.
^ permalink raw reply
* Re: [PATCH v3 08/11] sequencer.c: teach append_signoff to avoid adding a duplicate newline
From: Jonathan Nieder @ 2013-01-28 3:23 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, pclouds, gitster, Brandon Casey
In-Reply-To: <1359335515-13818-9-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> Teach append_signoff to detect whether a blank line exists at the position
> that the signed-off-by line will be added, and avoid adding an additional
> one if one already exists. This is necessary to allow format-patch to add a
> s-o-b to a patch with no commit message without adding an extra newline.
I assume this means you're preserving historical behavior when adding
a sign-off to a commit with empty description (which is a good thing),
but what is that behavior? Is it a deliberate choice or something
that developed by default?
[...]
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1118,11 +1118,15 @@ void append_signoff(struct strbuf *msgbuf, int ignore_footer, unsigned flag)
> for (i = msgbuf->len - 1 - ignore_footer; i > 0 && msgbuf->buf[i - 1] != '\n'; i--)
> ; /* do nothing */
>
> - if (i)
> - has_footer = has_conforming_footer(msgbuf, &sob, ignore_footer);
> -
> - if (!has_footer)
> - strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0, "\n", 1);
> + if (msgbuf->buf[i] != '\n') {
> + if (i)
> + has_footer = has_conforming_footer(msgbuf, &sob,
> + ignore_footer);
> +
> + if (!has_footer)
> + strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0,
> + "\n", 1);
> + }
>
> if (has_footer != 3 && (!no_dup_sob || has_footer != 2))
This is too much nesting for my small mind to keep track of. Am I
correct in imagining the effect is the same as the following?
has_footer = has_conforming_footer(...)
if (!has_footer && msgbuf->buf[i] != '\n')
strbuf_splice(...); /* add blank line */
if (has_footer != 3 && ...
^ permalink raw reply
* Re: [PATCH v3 09/11] t4014: more tests about appending s-o-b lines
From: Jonathan Nieder @ 2013-01-28 3:31 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, pclouds, gitster, Brandon Casey
In-Reply-To: <1359335515-13818-10-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
[...]
> --- a/t/t4014-format-patch.sh
> +++ b/t/t4014-format-patch.sh
> @@ -1021,4 +1021,246 @@ test_expect_success 'cover letter using branch description (6)' '
> grep hello actual >/dev/null
> '
>
> +append_signoff()
> +{
> + C=`git commit-tree HEAD^^{tree} -p HEAD` &&
> + git format-patch --stdout --signoff ${C}^..${C} |
> + tee append_signoff.patch |
> + sed -n "1,/^---$/p" |
> + grep -n -E "^Subject|Sign|^$"
> +}
Is "grep -n" portable? I didn't find any uses of it elsewhere in the
testsuite.
Style: checking exit status from format-patch, avoiding sed|grep pipeline:
C=$(git commit-tree HEAD^ -p HEAD) &&
git format-patch --stdout --signoff $C^..$C >append_signoff.patch &&
awk '
/^---$/ { exit; }
/^Subject/ || /^Sign/ || /^$/ { print NR ":" $0 }
' <append_signoff.patch >actual
^ permalink raw reply
* Re: [PATCH v3 10/11] format-patch: update append_signoff prototype
From: Jonathan Nieder @ 2013-01-28 3:35 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, pclouds, gitster, Brandon Casey
In-Reply-To: <1359335515-13818-11-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> From: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>
> This is a preparation step for merging with append_signoff from
> sequencer.c
Avoids a small unfreed allocation, too. Neat.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
(On the other hand, this means more malloc churn when running
"format-patch -s" on a long series of patches, but I don't think
anyone will mind.)
[...]
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -1193,16 +1192,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> rev.subject_prefix = strbuf_detach(&sprefix, NULL);
> }
>
> - if (do_signoff) {
> - const char *committer;
> - const char *endpos;
> - committer = git_committer_info(IDENT_STRICT);
sequencer.c uses fmt_name() which uses IDENT_STRICT, too. Phew.
^ permalink raw reply
* Re: [PATCH v3 11/11] Unify appending signoff in format-patch, commit and sequencer
From: Jonathan Nieder @ 2013-01-28 3:39 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, pclouds, gitster, Brandon Casey
In-Reply-To: <1359335515-13818-12-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> --- a/log-tree.c
> +++ b/log-tree.c
[...]
> @@ -208,94 +207,6 @@ void show_decorations(struct rev_info *opt, struct commit *commit)
> putchar(')');
> }
>
> -/*
> - * Search for "^[-A-Za-z]+: [^@]+@" pattern. It usually matches
> - * Signed-off-by: and Acked-by: lines.
> - */
That's stricter than the test from sequencer.c. Maybe it's worth
stealing to avoid false positives?
^ permalink raw reply
* Re: [PATCH v3 00/11] unify appending of sob
From: Jonathan Nieder @ 2013-01-28 3:48 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, pclouds, gitster
In-Reply-To: <1359335515-13818-1-git-send-email-drafnel@gmail.com>
Brandon Casey wrote:
> Round 3.
Thanks for a pleasant read. My only remaining observations are
cosmetic, except for a portability question in Duy's test script, a
small behavior change when the commit message ends with an
RFC2822-style header with no trailing newline and the possibility of
tightening the pattern in sequencer.c to match the strictness of
format-patch (which could easily wait for a later patch).
Jonathan
^ permalink raw reply
* Updating shared ref from remote helper, or fetch hook
From: Jed Brown @ 2013-01-28 5:19 UTC (permalink / raw)
To: git
I'm working on an hg remote helper that uses git notes for the sha1
revision, so that git users can more easily refer to specific commits
when communicating with hg users. Since there may be multiple
concurrent fast-import streams, I write the notes to a private ref
(refs/notes/hg-REMOTE), to be merged eventually using
git notes --ref hg merge hg-REMOTE*
There will never be conflicts because each hg commit translates to a
unique git commit, thus even if multiple concurrent remotes process the
same commit, the corresponding note will match.
Unfortunately, I couldn't find a safe way to get this run after a fetch
or clone. Of course I can ask the user to arrange to have this command
run, but it would be a better interface to have it run automatically
since it is a natural responsibility of the remote helper. Am I missing
a way to do this or a viable alternative approach?
^ permalink raw reply
* Re: [PATCH v3 05/11] sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
From: Brandon Casey @ 2013-01-28 5:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, pclouds, gitster, Brandon Casey
In-Reply-To: <20130128025140.GI8206@elie.Belkin>
On Sun, Jan 27, 2013 at 6:51 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Jonathan Nieder wrote:
>
>> Here's the tweak I suggested last time. I think its behavior is
>> slightly better in the "ends with incomplete line" case because it
>> limits the characters examined by is_rfc2822_line() and
>> is_cherry_picked_from_line() not to include buf[len] (which would
>> presumably sometimes be '\0').
>
> Whoops, that revealed a subtlety --- the '\n' or '\0' is what prevents
> exiting the loop in is_rfc2822_line when the line does not contain a
> colon. Here's a corrected version of the tweak, that should actually
> work. :)
>
> diff --git i/sequencer.c w/sequencer.c
> index 0b5cd18c..108ea27b 100644
> --- i/sequencer.c
> +++ w/sequencer.c
> @@ -1029,13 +1029,11 @@ static int is_rfc2822_line(const char *buf, int len)
> for (i = 0; i < len; i++) {
> int ch = buf[i];
> if (ch == ':')
> + return 1;
> + if (!isalnum(ch) && ch != '-')
> break;
> - if (isalnum(ch) || (ch == '-'))
> - continue;
> - return 0;
> }
> -
> - return 1;
> + return 0;
> }
>
> static int is_cherry_picked_from_line(const char *buf, int len)
> @@ -1043,9 +1041,7 @@ static int is_cherry_picked_from_line(const char *buf, int len)
> /*
> * We only care that it looks roughly like (cherry picked from ...)
> */
> - return !prefixcmp(buf, cherry_picked_prefix) &&
> - (buf[len - 1] == ')' ||
> - (buf[len - 1] == '\n' && buf[len - 2] == ')'));
> + return !prefixcmp(buf, cherry_picked_prefix) && buf[len - 1] == ')';
> }
>
> static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
> @@ -1072,8 +1068,8 @@ static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
> ; /* do nothing */
> k++;
>
> - if (!(is_rfc2822_line(buf + i, k - i) ||
> - is_cherry_picked_from_line(buf + i, k - i)))
> + if (!is_rfc2822_line(buf + i, k - i - 1) &&
> + !is_cherry_picked_from_line(buf + i, k - i - 1))
> return 0;
> }
> return 1;
Looks good to me.
-Brandon
^ permalink raw reply
* Re: [PATCH v3 09/11] t4014: more tests about appending s-o-b lines
From: Junio C Hamano @ 2013-01-28 5:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Brandon Casey, git, pclouds, Brandon Casey
In-Reply-To: <20130128033146.GM8206@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Brandon Casey wrote:
>
> [...]
>> --- a/t/t4014-format-patch.sh
>> +++ b/t/t4014-format-patch.sh
>> @@ -1021,4 +1021,246 @@ test_expect_success 'cover letter using branch description (6)' '
>> grep hello actual >/dev/null
>> '
>>
>> +append_signoff()
>> +{
>> + C=`git commit-tree HEAD^^{tree} -p HEAD` &&
>> + git format-patch --stdout --signoff ${C}^..${C} |
>> + tee append_signoff.patch |
>> + sed -n "1,/^---$/p" |
>> + grep -n -E "^Subject|Sign|^$"
>> +}
>
> Is "grep -n" portable? I didn't find any uses of it elsewhere in the
> testsuite.
Yes, "-n" is in POSIX. Even though we use it ourselves, "git grep"
supports it, too.
Any Emacs user would scream if their platform "grep" does not
support it, as it will make M-x grep (or grep-find) useless.
> Style: checking exit status from format-patch, avoiding sed|grep pipeline:
>
> C=$(git commit-tree HEAD^ -p HEAD) &&
> git format-patch --stdout --signoff $C^..$C >append_signoff.patch &&
> awk '
> /^---$/ { exit; }
> /^Subject/ || /^Sign/ || /^$/ { print NR ":" $0 }
> ' <append_signoff.patch >actual
Yeah, awk/perl would be fine, too, and it is good that you pointed
out that the original was losing the exit status from format-patch.
Thanks.
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Duy Nguyen @ 2013-01-28 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <7vpq0t3x60.fsf@alter.siamese.dyndns.org>
On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> This is not a tangent, but if you want to go this "forbid making our
> repository depend on objects we do not have but we know about after
> we peek submodule odb" route [*1*], write_sha1_file() needs to be
> told about has_sha1_file_proper(). We may "git add" a new blob in
> the superproject, the blob may not yet exist in *our* repository,
> but may happen to already exist in the submodue odb. In such a
> case, write_sha1_file() has to write that blob in our repository,
> without the existing has_sha1_file() check bypassing it. Otherwise
> our attempt to create a tree that contains that blob will fail,
> saying that the blob only seems to exist to us via submodule odb but
> not in our repository.
Another thing needs to be done for this to work. The current reading
order is packs first, loose objects next. If we create a local loose
duplicate of an alternate packed object, our local version will never
be read. Regardless the submodule odb issue, I think we should prefer
reading local loose objects over alternate packed ones.
--
Duy
^ permalink raw reply
* Re: [PATCH v3 00/11] unify appending of sob
From: Junio C Hamano @ 2013-01-28 5:49 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Brandon Casey, git, pclouds
In-Reply-To: <20130128034831.GQ8206@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Brandon Casey wrote:
>
>> Round 3.
>
> Thanks for a pleasant read. My only remaining observations are
> cosmetic, except for a portability question in Duy's test script, a
> small behavior change when the commit message ends with an
> RFC2822-style header with no trailing newline and the possibility of
> tightening the pattern in sequencer.c to match the strictness of
> format-patch (which could easily wait for a later patch).
>
> Jonathan
Thanks for a quick review. I agree that this series is getting very
close with your help.
^ permalink raw reply
* Re: [PATCH v3 09/11] t4014: more tests about appending s-o-b lines
From: Junio C Hamano @ 2013-01-28 5:51 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Brandon Casey, git, pclouds, Brandon Casey
In-Reply-To: <7vboc9zwv1.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> Is "grep -n" portable? I didn't find any uses of it elsewhere in the
>> testsuite.
>
> Yes, "-n" is in POSIX. Even though we use it ourselves, "git grep"
> supports it, too.
Ehh even though we *DONT* use it ourselves, ... that is.
I do not think we mind, if its use helps our test.
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Junio C Hamano @ 2013-01-28 5:54 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Jens Lehmann
In-Reply-To: <CACsJy8BJZgyEn1n2GWgAVSGhSkVUO-P=GXwR02OcDf0ziTTRaA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> This is not a tangent, but if you want to go this "forbid making our
>> repository depend on objects we do not have but we know about after
>> we peek submodule odb" route [*1*], write_sha1_file() needs to be
>> told about has_sha1_file_proper(). We may "git add" a new blob in
>> the superproject, the blob may not yet exist in *our* repository,
>> but may happen to already exist in the submodue odb. In such a
>> case, write_sha1_file() has to write that blob in our repository,
>> without the existing has_sha1_file() check bypassing it. Otherwise
>> our attempt to create a tree that contains that blob will fail,
>> saying that the blob only seems to exist to us via submodule odb but
>> not in our repository.
>
> Another thing needs to be done for this to work. The current reading
For *what* to work??? I think the performance consideration is the
only thing that should drive the read-order; correctness should not
be affected.
> order is packs first, loose objects next. If we create a local loose
> duplicate of an alternate packed object, our local version will never
> be read. Regardless the submodule odb issue, I think we should prefer
> reading local loose objects over alternate packed ones.
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Duy Nguyen @ 2013-01-28 5:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <7vy5fdyhs0.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 12:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> This is not a tangent, but if you want to go this "forbid making our
>>> repository depend on objects we do not have but we know about after
>>> we peek submodule odb" route [*1*], write_sha1_file() needs to be
>>> told about has_sha1_file_proper(). We may "git add" a new blob in
>>> the superproject, the blob may not yet exist in *our* repository,
>>> but may happen to already exist in the submodue odb. In such a
>>> case, write_sha1_file() has to write that blob in our repository,
>>> without the existing has_sha1_file() check bypassing it. Otherwise
>>> our attempt to create a tree that contains that blob will fail,
>>> saying that the blob only seems to exist to us via submodule odb but
>>> not in our repository.
>>
>> Another thing needs to be done for this to work. The current reading
>
> For *what* to work???
The "forbid making our repository depend on objects we do not have but
we know about afterwe peek submodule odb"
> I think the performance consideration is the
> only thing that should drive the read-order; correctness should not
> be affected.
>
>> order is packs first, loose objects next. If we create a local loose
>> duplicate of an alternate packed object, our local version will never
>> be read. Regardless the submodule odb issue, I think we should prefer
>> reading local loose objects over alternate packed ones.
--
Duy
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Junio C Hamano @ 2013-01-28 6:06 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Jens Lehmann
In-Reply-To: <CACsJy8CXC=poDBenBwo6t8=Qv-_zvGbvHYo-cDdGA8_fpw4Cyg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
>>> Another thing needs to be done for this to work. The current reading
>>
>> For *what* to work???
>
> The "forbid making our repository depend on objects we do not have but
> we know about afterwe peek submodule odb"
With your "when our object database is contaminated, check objects
we base our new object on are available in local or our alternates"
together with the "when we try write_object(), do not bypass it with
has_sha1_file() check because that may find the object in submodule odb
we should *not* have access to; instead check with the same 'local
or our alternates' test" I brought up in the message you were
responding to, I do not think object read order does not make a
difference to our effort to prevent the object database breakage due
to temporary contamination by submodule objects.
>>> Regardless the submodule odb issue, I think we should prefer
>>> reading local loose objects over alternate packed ones.
I suspect you are alluding to make write_object() check with
has_sha1_file_locally() so that we can wean our repository from
existing alternates, but I do not think it is a right approach
(instead, you just fully repack locally if you want to dissociate
yourself from your alternates). What I was suggesting was to change
it to check with has_sha1_file_proper(), to make sure we do not omit
writing an object we need to access to, when we know it will vanish
once we stop temporarily borrowing from the submodule object store.
^ permalink raw reply
* [PATCH] l10n: de.po: translate 11 new messages
From: Ralf Thielow @ 2013-01-28 6:14 UTC (permalink / raw)
To: trast, jk, stimming; +Cc: git, Ralf Thielow
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"
"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 6/7] read-cache: refuse to create index referring to external objects
From: Duy Nguyen @ 2013-01-28 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <CACsJy8BJZgyEn1n2GWgAVSGhSkVUO-P=GXwR02OcDf0ziTTRaA@mail.gmail.com>
On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> Regardless the submodule odb issue, I think we should prefer
> reading local loose objects over alternate packed ones.
I think I went from one problem to another and did not make it clear.
The reason behind this preference is security. With "all packs first"
reading order, someone can create a pack in the alternate source and
that pack will override the same local loose objects (local packed
ones are safe). If someone can create a malicious version with the
same SHA-1, we (well, the user) are in trouble. If the user uses this
repository directly then the malicious object can be used without
detected, even if it does not match the original SHA-1, as we do not
always verify content against its SHA-1 for common commands.
--
Duy
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Junio C Hamano @ 2013-01-28 6:36 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Jens Lehmann
In-Reply-To: <CACsJy8BwCCAZyMZ2w9fyMaNJsHRNp2V3Aen8g3drAkZ4y9mfBg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> Regardless the submodule odb issue, I think we should prefer
>> reading local loose objects over alternate packed ones.
>
> I think I went from one problem to another and did not make it clear.
> The reason behind this preference is security.
Reading from ours first would not help you at all if you are lacking
some that you do need from your local repository and the only
solution is not to borrow from untrustworthy sources, I think.
You borrow only from a trusted source in the first place, no?
^ permalink raw reply
* What's cooking in git.git (Jan 2013, #10; Sun, 27)
From: Junio C Hamano @ 2013-01-28 6:45 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of next month.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* bc/git-p4-for-python-2.4 (2013-01-26) 2 commits
- git-p4.py: support Python 2.4
- git-p4.py: support Python 2.5
With small updates to remove dependency on newer features of
Python, keep git-p4 usable with older Python.
Will merge to 'next'.
* jk/gc-auto-after-fetch (2013-01-26) 1 commit
- Merge branch 'jk/maint-gc-auto-after-fetch' into jk/gc-auto-after-fetch
(this branch uses jk/maint-gc-auto-after-fetch.)
This is to resolve merge conflicts early for the same topic to
recent codebase.
Will merge to 'next'.
* jk/maint-gc-auto-after-fetch (2013-01-26) 2 commits
- fetch-pack: avoid repeatedly re-scanning pack directory
- fetch: run gc --auto after fetching
(this branch is used by jk/gc-auto-after-fetch.)
Help "fetch only" repositories that does not trigger "gc --auto"
often enough.
Will merge to 'next' via jk/gc-auto-after-fetch.
* jk/read-commit-buffer-data-after-free (2013-01-26) 3 commits
- logmsg_reencode: lazily load missing commit buffers
- logmsg_reencode: never return NULL
- commit: drop useless xstrdup of commit message
Clarify the ownership rule for commit->buffer field, which some
callers incorrectly accessed without making sure the data is
available there.
Will merge to 'next'.
* pw/git-p4-on-cygwin (2013-01-26) 21 commits
- git p4: introduce gitConfigBool
- git p4: avoid shell when calling git config
- git p4: avoid shell when invoking git config --get-all
- git p4: avoid shell when invoking git rev-list
- git p4: avoid shell when mapping users
- git p4: disable read-only attribute before deleting
- git p4 test: use test_chmod for cygwin
- git p4: cygwin p4 client does not mark read-only
- git p4 test: avoid wildcard * in windows
- git p4 test: use LineEnd unix in windows tests too
- git p4 test: newline handling
- git p4: scrub crlf for utf16 files on windows
- git p4: remove unreachable windows \r\n conversion code
- git p4 test: translate windows paths for cygwin
- git p4 test: start p4d inside its db dir
- git p4 test: use client_view in t9806
- git p4 test: avoid loop in client_view
- git p4 test: use client_view to build the initial client
- git p4: generate better error message for bad depot path
- git p4: remove unused imports
- git p4: temp branch name should use / even on windows
Improve "git p4" on Cygwin. The cover letter said it is not yet
ready for full Windows support so I won't move this to 'next' until
told by the author (the area maintainer) otherwise.
* ss/mergetools-tortoise (2013-01-26) 2 commits
- mergetools: allow passing pathnames with SP in them to TortoiseGitMerge
- mergetools: support TortoiseGitMerge
Update mergetools to work better with newer merge helper tortoise ships.
Will merge to 'next'.
* da/mergetool-docs (2013-01-27) 4 commits
- doc: generate a list of valid merge tools
- mergetool--lib: add functions for finding available tools
- mergetool--lib: improve the help text in guess_merge_tool()
- mergetool--lib: simplify command expressions
(this branch uses jk/mergetool.)
Build on top of the clean-up done by jk/mergetool and automatically
generate the list of mergetool and difftool backends the build
supports to be included in the documentation.
This may still need to be fixed up at minor details; I'd like to
see a review from John Keeping on these.
* nd/branch-error-cases (2013-01-27) 4 commits
- branch: mark more strings for translation
- branch: give a more helpful message on redundant arguments
- branch: reject -D/-d without branch name
- branch: no detached HEAD check when editing another branch's description
Fix various error messages and conditions in "git branch", e.g. we
advertised "branch -d/-D" to remove one or more branches but actually
implemented removal of zero or more branches---request to remove no
branches was not rejected.
Will merge to 'next', perhaps after rebasing on an older base
so that this can later be merged to the maintenance track.
--------------------------------------------------
[Stalled]
* mp/complete-paths (2013-01-11) 1 commit
- git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
Waiting for area-experts' help and review.
* jl/submodule-deinit (2012-12-04) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Expecting a reroll.
$gmane/212884
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
* nd/parse-pathspec (2013-01-11) 20 commits
. Convert more init_pathspec() to parse_pathspec()
. Convert add_files_to_cache to take struct pathspec
. Convert {read,fill}_directory to take struct pathspec
. Convert refresh_index to take struct pathspec
. Convert report_path_error to take struct pathspec
. checkout: convert read_tree_some to take struct pathspec
. Convert unmerge_cache to take struct pathspec
. Convert read_cache_preload() to take struct pathspec
. add: convert to use parse_pathspec
. archive: convert to use parse_pathspec
. ls-files: convert to use parse_pathspec
. rm: convert to use parse_pathspec
. checkout: convert to use parse_pathspec
. rerere: convert to use parse_pathspec
. status: convert to use parse_pathspec
. commit: convert to use parse_pathspec
. clean: convert to use parse_pathspec
. Export parse_pathspec() and convert some get_pathspec() calls
. Add parse_pathspec() that converts cmdline args to struct pathspec
. pathspec: save the non-wildcard length part
Uses the parsed pathspec structure in more places where we used to
use the raw "array of strings" pathspec.
Ejected from 'pu' for now; will take a look at the rerolled one
later ($gmane/213340).
--------------------------------------------------
[Cooking]
* jc/push-reject-reasons (2013-01-24) 4 commits
- push: finishing touches to explain REJECT_ALREADY_EXISTS better
- push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
- push: further simplify the logic to assign rejection reason
- push: further clean up fields of "struct ref"
Improve error and advice messages given locally when "git push"
refuses when it cannot compute fast-forwardness by separating these
cases from the normal "not a fast-forward; merge first and push
again" case.
Will merge to 'next'.
* as/test-cleanup (2013-01-24) 1 commit
- t7102 (reset): don't hardcode SHA-1 in expected outputs
Will merge to 'next'.
* jc/do-not-let-random-file-interfere-with-completion-tests (2013-01-24) 1 commit
- t9902: protect test from stray build artifacts
Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
Will merge to 'next'.
* jk/cvsimport-does-not-work-with-cvsps3 (2013-01-24) 1 commit
- git-cvsimport.txt: cvsps-2 is deprecated
Warn people that other tools are more recommendable over
cvsimport+cvsps2 combo when doing a one-shot import, and cvsimport
will not work with cvsps3.
Will merge to 'next'.
* jk/mergetool (2013-01-27) 8 commits
- mergetools: simplify how we handle "vim" and "defaults"
- mergetool--lib: don't call "exit" in setup_tool
- mergetool--lib: improve show_tool_help() output
- mergetools/vim: remove redundant diff command
- git-difftool: use git-mergetool--lib for "--tool-help"
- git-mergetool: don't hardcode 'mergetool' in show_tool_help
- git-mergetool: remove redundant assignment
- git-mergetool: move show_tool_help to mergetool--lib
(this branch is used by da/mergetool-docs.)
Cleans up mergetool/difftool combo.
Will merge to 'next'.
* jn/do-not-drop-username-when-reading-from-etc-mailname (2013-01-25) 1 commit
- ident: do not drop username when reading from /etc/mailname
We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part. This is to fix it.
Will merge to 'next'.
* mm/add-u-A-sans-pathspec (2013-01-25) 1 commit
- add: warn when -u or -A is used without pathspec
Forbid "git add -u" and "git add -A" without pathspec run from a
subdirectory, to train people to type "." (or ":/") to make the
choice of default does not matter.
Will merge to 'next'.
* bc/fix-array-syntax-for-3.0-in-completion-bash (2013-01-18) 1 commit
(merged to 'next' on 2013-01-25 at d113c1a)
+ git-completion.bash: replace zsh notation that breaks bash 3.X
Fix use of an array notation that older versions of bash do not
understand.
Will merge to 'master'.
* jc/help (2013-01-18) 1 commit
(merged to 'next' on 2013-01-25 at b2b087e)
+ help: include <common-cmds.h> only in one file
A header file that has the definition of a static array was
included in two places, wasting the space.
Will merge to 'master'.
* jc/hidden-refs (2013-01-18) 2 commits
- upload-pack: allow hiding ref hiearchies
- upload-pack: share more code
Allow the server side to unclutter the refs/ namespace it shows by
default, while still allowing requests for histories leading to the
tips of hidden refs by updated clients (which are not written yet).
* jk/update-install-for-p4 (2013-01-20) 1 commit
- INSTALL: git-p4 doesn't support Python 3
Will merge to 'next'.
* tb/t0050-maint (2013-01-21) 3 commits
(merged to 'next' on 2013-01-25 at 682b1e2)
+ t0050: Use TAB for indentation
+ t0050: honor CASE_INSENSITIVE_FS in add (with different case)
+ t0050: known breakage vanished in merge (case change)
Update tests that were expecting to fail due to a bug that was
fixed earlier.
Will merge to 'master'.
* nd/magic-pathspec-from-root (2013-01-21) 2 commits
(merged to 'next' on 2013-01-25 at b056b57)
+ grep: avoid accepting ambiguous revision
+ Update :/abc ambiguity check
When giving arguments without "--" disambiguation, object names
that come earlier on the command line must not be interpretable as
pathspecs and pathspecs that come later on the command line must
not be interpretable as object names. Tweak the disambiguation
rule so that ":/" (no other string before or after) is always
interpreted as a pathspec, to avoid having to say "git cmd -- :/".
Will merge to 'master'.
* ta/doc-no-small-caps (2013-01-22) 10 commits
- fixup! Change 'git' to 'Git' whenever the whole system is referred to #4
- Change 'git' to 'Git' whenever the whole system is referred to #4
- fixup! Change 'git' to 'Git' whenever the whole system is referred to #3
- Change 'git' to 'Git' whenever the whole system is referred to #3
- fixup! Change 'git' to 'Git' whenever the whole system is referred to #2
- Change 'git' to 'Git' whenever the whole system is referred to #2
- fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
- fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
- Change 'git' to 'Git' whenever the whole system is referred to #1
- Documentation: avoid poor-man's small caps
Update documentation to change "GIT" which was a poor-man's small
caps to "Git" which was the intended spelling. Also change "git"
spelled in all-lowercase to "Git" when it refers to the system as
the whole or the concept it embodies, as opposed to the command the
end users would type.
Will wait for a week or so (say, til end of January) for Thomas to
collect fix-ups, squash the result into two patches and then merge
to 'next'.
* rr/minimal-stat (2013-01-22) 1 commit
(merged to 'next' on 2013-01-25 at 11c4453)
+ Enable minimal stat checking
Some reimplementations of Git does not write all the stat info back
to the index due to their implementation limitations (e.g. jgit
running on Java). A configuration option can tell Git to ignore
changes to most of the stat fields and only pay attention to mtime
and size, which these implementations can reliably update. This
avoids excessive revalidation of contents.
Will merge to 'master'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
- simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
As this touches a fairly core part of the revision traversal
infrastructure, it is appreciated to have an extra set of eyes for
sanity check.
Will merge to 'next'.
* jk/remote-helpers-in-python-3 (2013-01-27) 9 commits
- git-remote-testpy: fix path hashing on Python 3
(merged to 'next' on 2013-01-25 at acf9419)
+ git-remote-testpy: call print as a function
+ git-remote-testpy: don't do unbuffered text I/O
+ git-remote-testpy: hash bytes explicitly
+ svn-fe: allow svnrdump_sim.py to run with Python 3
+ git_remote_helpers: use 2to3 if building with Python 3
+ git_remote_helpers: force rebuild if python version changes
+ git_remote_helpers: fix input when running under Python 3
+ git_remote_helpers: allow building with Python 3
Prepare remote-helper test written in Python to be run with Python3.
Waiting for the final review and Ack, perhaps from Michael.
* dl/am-hg-locale (2013-01-18) 1 commit
(merged to 'next' on 2013-01-25 at 3419019)
+ am: invoke perl's strftime in C locale
Datestamp recorded in "Hg" format patch was reformatted incorrectly
to an e-mail looking date using locale dependant strftime, causing
patch application to fail.
Will merge to 'master'.
* jk/config-parsing-cleanup (2013-01-23) 8 commits
- reflog: use parse_config_key in config callback
- help: use parse_config_key for man config
- submodule: simplify memory handling in config parsing
- submodule: use parse_config_key when parsing config
- userdiff: drop parse_driver function
- convert some config callbacks to parse_config_key
- archive-tar: use parse_config_key when parsing config
- config: add helper function for parsing key names
Configuration parsing for tar.* configuration variables were
broken. Introduce a new config-keyname parser API to make the
callers much less error prone.
Will merge to 'next'.
* mp/diff-algo-config (2013-01-16) 3 commits
- diff: Introduce --diff-algorithm command line option
- config: Introduce diff.algorithm variable
- git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
Looking better; may want tests to protect it from future breakages,
but otherwise it looks ready for 'next'.
Expecting a follow-up to add tests.
* jc/custom-comment-char (2013-01-16) 1 commit
(merged to 'next' on 2013-01-25 at 91d8a5d)
+ Allow custom "comment char"
An illustration to show codepaths that need to be touched to change
the hint lines in the edited text to begin with something other
than '#'.
This is half my work and half by Ralf Thielow. There may still be
leftover '#' lurking around, though. My "git grep" says C code
should be already fine, but git-rebase--interactive.sh could be
converted (it should not matter, as the file is not really a
free-form text).
I don't know how useful this will be in real life, though.
* nd/fetch-depth-is-broken (2013-01-11) 3 commits
(merged to 'next' on 2013-01-15 at 70a5ca7)
+ fetch: elaborate --depth action
+ upload-pack: fix off-by-one depth calculation in shallow clone
+ fetch: add --unshallow for turning shallow repo into complete one
"git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
Will cook in 'next'.
* jc/no-git-config-in-clone (2013-01-11) 1 commit
(merged to 'next' on 2013-01-15 at feeffe1)
+ clone: do not export and unexport GIT_CONFIG
We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
Will cook in 'next'.
* dg/subtree-fixes (2013-01-08) 7 commits
- contrib/subtree: mkdir the manual directory if needed
- contrib/subtree: honor $(DESTDIR)
- contrib/subtree: fix synopsis and command help
- contrib/subtree: better error handling for "add"
- contrib/subtree: add --unannotate option
- contrib/subtree: use %B for split Subject/Body
- t7900: remove test number comments
contrib/subtree updates; there are a few more from T. Zheng that
were posted separately, with an overlap.
Expecting a reroll.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0 ;-).
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* bc/append-signed-off-by (2013-01-27) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
- sequencer.c: rework search for start of footer to improve clarity
Rerolled. With help from Jonathan, I think this is getting closer.
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Duy Nguyen @ 2013-01-28 6:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <7vpq0pyfsq.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 1:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>>> Regardless the submodule odb issue, I think we should prefer
>>> reading local loose objects over alternate packed ones.
>>
>> I think I went from one problem to another and did not make it clear.
>> The reason behind this preference is security.
>
> Reading from ours first would not help you at all if you are lacking
> some that you do need from your local repository and the only
> solution is not to borrow from untrustworthy sources, I think.
>
> You borrow only from a trusted source in the first place, no?
Hmm.. yeah.
--
Duy
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Lars Hjemli @ 2013-01-28 7:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk3qywiqf.fsf@alter.siamese.dyndns.org>
On Sun, Jan 27, 2013 at 8:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>> The command also honours the option '--clean' which restricts the set of
>> repos to those which '--dirty' would skip, and '-x' which is used to
>> execute non-git commands.
>
> It might make sense to internally use RUN_GIT_CMD flag when the
> first word of the command line is 'git' as an optimization, but
> I am not sure it is a good idea to force the end users to think
> when to use -x and when not to is a good idea.
>
> In other words, I think
>
> git for-each-repo -d diff --name-only
> git for-each-repo -d -x ls '*.c'
>
> is less nice than letting the user say
>
> git for-each-repo -d git diff --name-only
> git for-each-repo -d ls '*.c'
>
The 'git-for-each-repo' command was made to allow any git command to
be executed in all discovered repositories, and I've used it that way
for two years (in the form of a shell-script called 'git-all'). During
this time, I've occasionally thought about forking non-git commands
but the itch hasn't been strong enough for me to scratch. The point
I'm trying to make is that to me, this command acts as a modifier for
other git commands[1]. Having the possibility to execute non-git
commands would be nice, but it is not the main objective of this
command.
[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).
>> Finally, the command to execute within each repo is optional. If none is
>> given, git-for-each-repo will just print the path to each repo found. And
>> since the command supports -z, this can be used for more advanced scripting
>> needs.
>
> It amounts to the same thing, but I would rather describe it as:
>
> To allow scripts to handle paths with shell-unsafe characters,
> support "-z" to show paths with NUL termination. Otherwise,
> such paths are shown with the usual c-quoting.
>
Much better, thanks.
> One more thing that nobody brought up during the previous reviews is
> if we want to support subset of repositories by allowing the
> standard pathspec match mechanism. For example,
>
> git for-each-repo -d git diff --name-only -- foo/ bar/b\*z
>
> might be a way to ask "please find repositories match the given
> pathspecs (i.e. foo/ bar/b\*z) and run the command in the ones that
> are dirty". We would need to think about how to mark the end of the
> command though---we could borrow \; from find(1), even though find
> is not the best example of the UI design. I.e.
>
> git for-each-repo -d git diff --name-only \; [--] foo/ bar/b\*z
>
> with or without "--".
I don't think this would be very nice to end users, and would prefer
--include and --exclude options (the latter is actually already a part
of git-all, added by one of my coworkers).
>> +NOTES
>> +-----
>> +
>> +For the purpose of `git-for-each-repo`, a dirty worktree is defined as a
>> +worktree with uncommitted changes.
>
> Is it a definition that is different from usual? If so why does it
> need to be inconsistent with the rest of the system?
I just wanted to clarify what condition --dirty and --clean will
check. In particular, the lack of checking for untracked files (which
could be added as yet another option).
>> +static void print_repo_path(const char *path, unsigned pretty)
>> +{
>> + if (path[0] == '.' && path[1] == '/')
>> + path += 2;
>> + if (pretty)
>> + color_fprintf_ln(stdout, color, "[%s]", path);
>
> This is shown before running a command in that repository. I am of
> two minds. It certainly is nice to be able to tell which repository
> each block of output lines comes from, and not requiring the command
> to do this themselves is a good default. However, I wonder if people
> would want to do something like this:
>
> git for-each-repo sh -c '
> git diff --name-only |
> sed -e "s|^|$path/|"
> '
>
> to get a consolidated view, in a way similar to how "submodule
> foreach" can be used. This unconditional output will get in the way
> for such a use case.
I guess -q/--quiet could be useful.
>> +static int walk(struct strbuf *path, int argc, const char **argv)
>> +{
>> + DIR *dir;
>> + struct dirent *ent;
>> + struct stat st;
>> + size_t len;
>> + int has_dotgit = 0;
>> + struct string_list list = STRING_LIST_INIT_DUP;
>> + struct string_list_item *item;
>> +
>> + dir = opendir(path->buf);
>> + if (!dir)
>> + return errno;
>> + strbuf_addstr(path, "/");
>> + len = path->len;
>> + while ((ent = readdir(dir))) {
>> + if (!strcmp(ent->d_name, ".") || !strcmp(ent->d_name, ".."))
>> + continue;
>> + if (!strcmp(ent->d_name, ".git")) {
>> + has_dotgit = 1;
>> + continue;
>> + }
>> + switch (DTYPE(ent)) {
>> + case DT_UNKNOWN:
>> + case DT_LNK:
>> + /* Use stat() to figure out if this path leads
>> + * to a directory - it's not important if it's
>> + * a symlink which gets us there.
>> + */
>> + strbuf_setlen(path, len);
>> + strbuf_addstr(path, ent->d_name);
>> + if (stat(path->buf, &st) || !S_ISDIR(st.st_mode))
>> + break;
>> + /* fallthrough */
>> + case DT_DIR:
>> + string_list_append(&list, ent->d_name);
>> + break;
>> + }
>> + }
>> + closedir(dir);
>> + strbuf_setlen(path, len);
>> + if (has_dotgit)
>> + handle_repo(path, argv);
>> + sort_string_list(&list);
>> + for_each_string_list_item(item, &list) {
>> + strbuf_setlen(path, len);
>> + strbuf_addstr(path, item->string);
>> + walk(path, argc, argv);
>> + }
>> + string_list_clear(&list, 0);
>> + return 0;
>> +}
>
> Is the "collect-first-and-then-sort" done so that the repositories
> are shown in a stable order regardless of the order in which
> readdir() returns he entries?
Yes (writing the testcases demonstrated a need for predictable output).
>> diff --git a/t/t6400-for-each-repo.sh b/t/t6400-for-each-repo.sh
>
> This command does not look like "6 - the revision tree commands" to
> me. "7 - the porcelainish commands concerning the working tree" or
> "9 - the git tools" may be a better match?
Ok, how about t9003?
>> new file mode 100755
>> index 0000000..af02c0c
>> --- /dev/null
>> +++ b/t/t6400-for-each-repo.sh
>> @@ -0,0 +1,150 @@
>> +#!/bin/sh
>> +#
>> +# Copyright (c) 2013 Lars Hjemli
>> +#
>> +
>> +test_description='Test the git-for-each-repo command'
>> +
>> +. ./test-lib.sh
>> +
>> +qname="with\"quote"
>> +qqname="\"with\\\"quote\""
>
> If Windows does not have problems with paths with dq in it, then
> this is fine, but I dunno. Otherwise, you may want to exclude the
> c-quote testing from the main part of the test, and have a single
> test that has prerequisite for filesystems that can do this at the
> end of the script.
I'll check my patch on msysgit before resending.
>> +test_expect_success "setup" '
>> + test_create_repo clean &&
>> + (cd clean && test_commit foo1) &&
>> + git init --separate-git-dir=.cleansub clean/gitfile &&
>> + (cd clean/gitfile && test_commit foo2 && echo bar >>foo2.t) &&
>> + test_create_repo dirty-idx &&
>> + (cd dirty-idx && test_commit foo3 && git rm foo3.t) &&
>> + test_create_repo dirty-wt &&
>> + (cd dirty-wt && mv .git .linkedgit && ln -s .linkedgit .git &&
>
> Some platforms are symlink-challenged. Can we do this test without
> "ln -s"? SYMLINKS prereq wouldn't be very useful for the setup
> step, as all the remaining tests won't work without setting up the
> test scenario.
I added this test to check the DT_UNKNOWN/DT_LINK case in walk() so
I'd rather not drop it, but it can be moved into a standalone,
SYMLINKS-enabled testcase.
Thanks for the review.
--
larsh
^ permalink raw reply
* Re: Port 22
From: Kevin @ 2013-01-28 8:06 UTC (permalink / raw)
To: Craig Christensen; +Cc: git
In-Reply-To: <55B0A474-AD5B-44B5-91E7-FA5253FA5682@gmail.com>
This is not really a git problem, but more of an ssh problem.
Are you in the position to change the port where the SSH daemon
listens on? Then you could use a different port which isn't blocked
(443 perhaps?).
On Sat, Jan 26, 2013 at 7:56 PM, Craig Christensen <cwcraigo@gmail.com> wrote:
> I am currently a student at Brigham Young University - Idaho and we are use Pagoda Box and Git for our Mobile Apps class. However, the school's network has blocked incoming trafic on port 22. I have been searching through all the tutorials and documents provided by Pagoda Box and Git but have not been able to find a solution to solve this problem. We can use sftp but we then have to manually deploy the latest using the admin panel. Can you help provide a simple solution?
>
> Thanks,
>
> Craig W Christensen
> cwcraigo@gmail.com
> chr07035@byui.edu--
> 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 v4 1/2] for-each-repo: new command used for multi-repo operations
From: Jonathan Nieder @ 2013-01-28 8:10 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <CAFXTnz6GTVgY4DK-FLELGF-Cb1=iNYyWcUsUiaUytGRx9Tr4Ow@mail.gmail.com>
Hi,
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. ;-)
[...]
>> One more thing that nobody brought up during the previous reviews is
>> if we want to support subset of repositories by allowing the
>> standard pathspec match mechanism. For example,
>>
>> git for-each-repo -d git diff --name-only -- foo/ bar/b\*z
>>
>> might be a way to ask "please find repositories match the given
>> pathspecs (i.e. foo/ bar/b\*z) and run the command in the ones that
>> are dirty". We would need to think about how to mark the end of the
>> command though---we could borrow \; from find(1), even though find
>> is not the best example of the UI design.
In most non-git commands, "--" represents an end-of-options marker,
allowing arbitrary options afterward without having to worry about
escaping minus signs. So in that spirit, if this weren't a git
command, I'd expect to be able to do
for-each-repo -- git diff -- '*.c'
and have the second '--' passed verbatim to "git diff".
Unfortunately in git (imitating commands like "grep", I suppose), "--"
means "paths start here". That means that with the git convention,
there is only one place to pass paths to a given command.
Tracing backwards: it would be really nice to be able to do
git for-each-repo git grep -e foo -- '*.c'
or
git -a grep -e foo -- '*.c'
For this practical reason, it seems that paths listed after the '--'
should go to the command being run. On the other hand, if I wanted to
limit my for-each-repo run to repositories in two subdirectories of
the cwd, I'd be tempted to try
git for-each-repo git grep -e foo -- src/ doc/
And if I wanted to limit to different file types in the repositories
under each directory, it would be tempting to use
git for-each-repo git grep -e foo -- 'src/*.c' 'doc/*.txt'
Is there a convention that would be usable today that is roughly
forward-compatible with that? (To throw an example out, requiring
that each pathspec passed to for-each-repo either starts with '*' or
contains no wildcards.)
Thanks,
Jonathan
^ 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