* Re: [PATCH 7/9] pretty: support padding placeholders, %< %> and %><
From: Jeff King @ 2012-10-24 8:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1348391433-11300-8-git-send-email-pclouds@gmail.com>
On Sun, Sep 23, 2012 at 04:10:31PM +0700, Nguyen Thai Ngoc Duy wrote:
> + else {
> + int sb_len = sb->len, offset;
> + switch (c->flush_type) {
> + case flush_left:
> + offset = padding - len;
> + break;
> + case flush_right:
> + offset = 0;
> + break;
> + case flush_both:
> + offset = (padding - len) / 2;
> + break;
> + case no_flush: /* to make gcc happy */
> + break;
> + }
> + /*
> + * we calculate padding in columns, now
> + * convert it back to chars
> + */
> + padding = padding - len + local_sb.len;
> + strbuf_grow(sb, padding);
> + strbuf_setlen(sb, sb_len + padding);
> + memset(sb->buf + sb_len, ' ', sb->len - sb_len);
> + memcpy(sb->buf + sb_len + offset, local_sb.buf,
> + local_sb.len);
> + }
gcc complains (rightly, I think) that offset can be used uninitialized
in the final line (looks like it is from the no_flush case). If it is a
"can never happen" case that is there to appease gcc in the switch
statement, should we drop a die("BUG: XXX") there? If so, what would the
XXX be?
-Peff
^ permalink raw reply
* Re: [PATCH] git-status: show short sequencer state
From: Matthieu Moy @ 2012-10-24 8:15 UTC (permalink / raw)
To: Phil Hord
Cc: phil.hord@gmail.com, Junio C Hamano, konglu@minatec.inpg.fr,
Kong Lucien, git@vger.kernel.org, Duperray Valentin, Jonas Franck,
Nguy Thomas, Nguyen Huynh Khoi Nguyen
In-Reply-To: <5086DBDB.9070606@cisco.com>
Phil Hord <hordp@cisco.com> writes:
>>> + if (state->substate==WT_SUBSTATE_NOMINAL)
>>> status_printf_ln(s, color,
>>> _("The current patch is empty."));
>> This looks weird. First, spaces around == (here and below). Then, the
>> logic is unintuitive. The "if" suggests everything is allright, and the
>> message below is very specific. This at least deserves a comment.
>
> Yes, I agree. It was less clear but more reasonable before I tried to
> clear it up some. It's driven by the short-token printer. The state is
> "you're in a 'git am' but I do not see any conflicted files. Therefore,
> your patch must be empty."
This was my guess, but I wouldn't have needed to guess if there was a
comment in the code ;-).
> I'll try to make this more explicit. Currently the short-status
> version will say either "am" or "am \n conflicted" when a 'git am' is in
> progress. The logical path to follow if I re-add 'git-am-empty' state
> tracker is for this to now show either "am \n am-is-empty" or "am \n
> conflicted". But I think I should suppress the "am-is-empty" report in
> that case. What do you think
I don't think you should remove it from the output (no strong opinion).
My point was just that the code looked weird.
>>> +static void wt_print_token(struct wt_status *s, const char *color, const char *token)
>>> +{
>>> + color_fprintf(s->fp, color, "%s", token);
>>> + fputc(s->null_termination ? '\0' : '\n', s->fp);
>>> +}
>> The output format seems to be meant only for machine-consumption. Is
>> there any case when we'd want color? [...]
> > [...]I thought I might be going back there, or that I might combine this
> > with full 'git status' again somehow, and colors seemed appropriate
> > still.
> > [...]
> > So I can remove this color decorator until someone finds a need for
> > it.
I'm fine with both options, with a slight preference for removing them.
> My own use-case involves $PS1.
That makes sense (indeed, the implementation of status hints was
slightly inspired from what the bash prompt in
contrib/completion/git-prompt.sh does). The next step could be to use
your porcelain there instead of checking manually file existance.
You may want to add a short note about this motivation in the commit
message.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Krzysztof Mazur @ 2012-10-24 8:03 UTC (permalink / raw)
To: gitster, git; +Cc: Krzysztof Mazur
The git-send-email always use RFC2047 subject quoting for files
with "broken" encoding - non-ASCII files without Content-Transfer-Encoding,
even for ASCII subjects. Now for ASCII subjects the RFC2047 quoting will be
skipped.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
git-send-email.perl | 3 ++-
t/t9001-send-email.sh | 17 +++++++++++++++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index adcb4e3..efeae4c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1327,7 +1327,8 @@ foreach my $t (@files) {
$body_encoding = $auto_8bit_encoding;
}
- if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
+ if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
+ ($subject =~ /[^[:ascii:]]/)) {
$subject = quote_rfc2047($subject, $auto_8bit_encoding);
}
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 89fceda..6c6af7d 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1143,6 +1143,23 @@ EOF
'
test_expect_success $PREREQ 'setup expect' '
+cat >expected <<EOF
+Subject: subject goes here
+EOF
+'
+
+test_expect_success $PREREQ 'ASCII subject is not RFC2047 quoted' '
+ clean_fake_sendmail &&
+ echo bogus |
+ git send-email --from=author@example.com --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --8bit-encoding=UTF-8 \
+ email-using-8bit >stdout &&
+ grep "Subject" msgtxt1 >actual &&
+ test_cmp expected actual
+'
+
+test_expect_success $PREREQ 'setup expect' '
cat >content-type-decl <<EOF
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
--
1.8.0.3.gf4c35fc
^ permalink raw reply related
* Re: L10n regression in 1.8.0.rc2: diffstat summary (git diff --stat, git format-patch)
From: Peter Krefting @ 2012-10-24 7:54 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Jiang Xin
In-Reply-To: <alpine.DEB.2.00.1210200035220.15821@ds9.cixit.se>
> I'll see if I can come up with a patch that cater for both use-cases.
I see that I forgot to Cc you; please see the patch series starting
with the Subject "[RFC PATCH 0/2] Localize log output", which I posted
here yesterday.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] git-submodule: wrap branch option with "<>" in usage strings.
From: Jeff King @ 2012-10-24 7:34 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <6332cbbfccd24f9d1ed37de424372ca354e9a4da.1351026021.git.wking@tremily.us>
On Tue, Oct 23, 2012 at 05:00:21PM -0400, W. Trevor King wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> Use "-b <branch>" instead of "-b branch". This brings the usage
> strings in line with other options, e.g. "--reference <repository>".
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
Thanks. Looks obviously correct to me.
-Peff
^ permalink raw reply
* Re: Large number of object files
From: Jeff King @ 2012-10-24 7:11 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Uri Moszkowicz, git
In-Reply-To: <CACsJy8CcMBJLV=urVoWOQABQzQkC6y35spPF+_3fW6dtJjHtvg@mail.gmail.com>
On Wed, Oct 24, 2012 at 01:59:16PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Oct 24, 2012 at 12:21 PM, Uri Moszkowicz <uri@4refs.com> wrote:
> > Continuing to work on improving clone times, using "git gc
> > --aggressive" has resulted in a large number of tags combining into a
> > single file but now I have a large number of files in the objects
> > directory - 131k for a ~2.7GB repository.
>
> Can you paste "git count-objects -v"? I'm curious why gc keeps so many
> loose objects around.
Presumably ejected from the pack because they are now unreachable.
That's a rather large number, but if there was recent ref maintenance
(e.g., deleting branches or tags), it is not impossible.
> > Any way to reduce the number of these files to speed up clones?
>
> An easy way to get rid of them is to clone the non-local way.
> Everything will be sent over a pack, the result would be a single pack
> in new repo. Try "git clone file:///path/to/source/repo new-repo".
If you have git v1.7.12 or greater, you can also use the "--no-local"
option to clone. But as you mentioned, pruning is probably the most
sensible thing (and for a non-local clone, those objects should not
impact performance at all, as we will never even look at unreferenced
objects).
-Peff
^ permalink raw reply
* [PATCHv2 1/8] t1300: style updates
From: Jeff King @ 2012-10-24 7:07 UTC (permalink / raw)
To: Johannes Sixt
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano
In-Reply-To: <20121024063712.GA17789@sigill.intra.peff.net>
On Wed, Oct 24, 2012 at 02:37:12AM -0400, Jeff King wrote:
> > Here's a case you forgot to update to test_cmp.
> [...]
> > And while you are here, you might want to remove this extra space. ;)
> >
> > Otherwise, looks fine.
>
> Thanks, I'll fix up both.
Here's an updated version of patch 1 that I'm planning on queuing. It's
rather tedious to read, but if anybody feels like giving it one more
run-through, let me know if you see any problems.
I won't bother re-posting the other patches, as they are unchanged on
top.
-- >8 --
Subject: [PATCH] t1300: style updates
The t1300 test script is quite old, and does not use our
modern techniques or styles. This patch updates it in the
following ways:
1. Use test_cmp instead of cmp (to make failures easier to
debug).
2. Use test_cmp instead of 'test $(command) = expected'.
This makes failures much easier to debug, and also
makes sure that $(command) exits appropriately.
3. Use test_must_fail (easier to read, and checks more
rigorously for signal death).
4. Write tests with the usual style of:
test_expect_success 'test name' '
test commands &&
...
'
rather than one-liners, or using backslash-continuation.
This is purely a style fixup.
There are still a few command happening outside of
test_expect invocations, but they are all innoccuous system
commands like "cat" and "cp". In an ideal world, each test
would be self sufficient and all commands would happen
inside test_expect, but it is not immediately obvious how
the grouping should work (some of the commands impact the
subsequent tests, and some of them are setting up and
modifying state that many tests depend on). This patch just
picks the low-hanging style fruit, and we can do more fixes
on top later.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t1300-repo-config.sh | 301 +++++++++++++++++++++++++++++--------------------
1 file changed, 178 insertions(+), 123 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index e127f35..feb7430 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -55,11 +55,13 @@ test_expect_success 'replace with non-match' \
test_cmp expect .git/config
'
-test_expect_success 'replace with non-match' \
- 'git config core.penguin kingpin !blue'
+test_expect_success 'replace with non-match' '
+ git config core.penguin kingpin !blue
+'
-test_expect_success 'replace with non-match (actually matching)' \
- 'git config core.penguin "very blue" !kingpin'
+test_expect_success 'replace with non-match (actually matching)' '
+ git config core.penguin "very blue" !kingpin
+'
cat > expect << EOF
[core]
@@ -108,8 +110,9 @@ EOF
lines
EOF
-test_expect_success 'unset with cont. lines' \
- 'git config --unset beta.baz'
+test_expect_success 'unset with cont. lines' '
+ git config --unset beta.baz
+'
cat > expect <<\EOF
[alpha]
@@ -133,8 +136,9 @@ cp .git/config .git/config2
cp .git/config .git/config2
-test_expect_success 'multiple unset' \
- 'git config --unset-all beta.haha'
+test_expect_success 'multiple unset' '
+ git config --unset-all beta.haha
+'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -145,7 +149,9 @@ EOF
[nextSection] noNewline = ouch
EOF
-test_expect_success 'multiple unset is correct' 'test_cmp expect .git/config'
+test_expect_success 'multiple unset is correct' '
+ test_cmp expect .git/config
+'
cp .git/config2 .git/config
@@ -156,8 +162,9 @@ rm .git/config2
rm .git/config2
-test_expect_success '--replace-all' \
- 'git config --replace-all beta.haha gamma'
+test_expect_success '--replace-all' '
+ git config --replace-all beta.haha gamma
+'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -169,7 +176,9 @@ EOF
[nextSection] noNewline = ouch
EOF
-test_expect_success 'all replaced' 'test_cmp expect .git/config'
+test_expect_success 'all replaced' '
+ test_cmp expect .git/config
+'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -200,7 +209,11 @@ test_expect_success 'really really mean test' '
test_cmp expect .git/config
'
-test_expect_success 'get value' 'test alpha = $(git config beta.haha)'
+test_expect_success 'get value' '
+ echo alpha >expect &&
+ git config beta.haha >actual &&
+ test_cmp expect actual
+'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -231,18 +244,23 @@ test_expect_success 'ambiguous get' '
test_cmp expect .git/config
'
-test_expect_success 'non-match' \
- 'git config --get nextsection.nonewline !for'
+test_expect_success 'non-match' '
+ git config --get nextsection.nonewline !for
+'
-test_expect_success 'non-match value' \
- 'test wow = $(git config --get nextsection.nonewline !for)'
+test_expect_success 'non-match value' '
+ echo wow >expect &&
+ git config --get nextsection.nonewline !for >actual &&
+ test_cmp expect actual
+'
test_expect_success 'ambiguous get' '
test_must_fail git config --get nextsection.nonewline
'
-test_expect_success 'get multivar' \
- 'git config --get-all nextsection.nonewline'
+test_expect_success 'get multivar' '
+ git config --get-all nextsection.nonewline
+'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -290,8 +308,9 @@ test_expect_success 'correct key' 'git config 123456.a123 987'
test_expect_success 'correct key' 'git config 123456.a123 987'
-test_expect_success 'hierarchical section' \
- 'git config Version.1.2.3eX.Alpha beta'
+test_expect_success 'hierarchical section' '
+ git config Version.1.2.3eX.Alpha beta
+'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -307,7 +326,9 @@ EOF
Alpha = beta
EOF
-test_expect_success 'hierarchical section value' 'test_cmp expect .git/config'
+test_expect_success 'hierarchical section value' '
+ test_cmp expect .git/config
+'
cat > expect << EOF
beta.noindent=sillyValue
@@ -316,9 +337,10 @@ EOF
version.1.2.3eX.alpha=beta
EOF
-test_expect_success 'working --list' \
- 'git config --list > output && cmp output expect'
-
+test_expect_success 'working --list' '
+ git config --list > output &&
+ test_cmp expect output
+'
cat > expect << EOF
EOF
@@ -332,8 +354,10 @@ EOF
nextsection.nonewline wow2 for me
EOF
-test_expect_success '--get-regexp' \
- 'git config --get-regexp in > output && cmp output expect'
+test_expect_success '--get-regexp' '
+ git config --get-regexp in >output &&
+ test_cmp expect output
+'
cat > expect << EOF
wow2 for me
@@ -353,41 +377,48 @@ echo false > expect
variable =
EOF
-test_expect_success 'get variable with no value' \
- 'git config --get novalue.variable ^$'
+test_expect_success 'get variable with no value' '
+ git config --get novalue.variable ^$
+'
-test_expect_success 'get variable with empty value' \
- 'git config --get emptyvalue.variable ^$'
+test_expect_success 'get variable with empty value' '
+ git config --get emptyvalue.variable ^$
+'
echo novalue.variable > expect
-test_expect_success 'get-regexp variable with no value' \
- 'git config --get-regexp novalue > output &&
- cmp output expect'
+test_expect_success 'get-regexp variable with no value' '
+ git config --get-regexp novalue > output &&
+ test_cmp expect output
+'
echo 'novalue.variable true' > expect
-test_expect_success 'get-regexp --bool variable with no value' \
- 'git config --bool --get-regexp novalue > output &&
- cmp output expect'
+test_expect_success 'get-regexp --bool variable with no value' '
+ git config --bool --get-regexp novalue > output &&
+ test_cmp expect output
+'
echo 'emptyvalue.variable ' > expect
-test_expect_success 'get-regexp variable with empty value' \
- 'git config --get-regexp emptyvalue > output &&
- cmp output expect'
+test_expect_success 'get-regexp variable with empty value' '
+ git config --get-regexp emptyvalue > output &&
+ test_cmp expect output
+'
echo true > expect
-test_expect_success 'get bool variable with no value' \
- 'git config --bool novalue.variable > output &&
- cmp output expect'
+test_expect_success 'get bool variable with no value' '
+ git config --bool novalue.variable > output &&
+ test_cmp expect output
+'
echo false > expect
-test_expect_success 'get bool variable with empty value' \
- 'git config --bool emptyvalue.variable > output &&
- cmp output expect'
+test_expect_success 'get bool variable with empty value' '
+ git config --bool emptyvalue.variable > output &&
+ test_cmp expect output
+'
test_expect_success 'no arguments, but no crash' '
test_must_fail git config >output 2>&1 &&
@@ -427,8 +458,9 @@ test_expect_success 'new variable inserts into proper section' '
test_cmp expect .git/config
'
-test_expect_success 'alternative GIT_CONFIG (non-existing file should fail)' \
- 'test_must_fail git config --file non-existing-config -l'
+test_expect_success 'alternative GIT_CONFIG (non-existing file should fail)' '
+ test_must_fail git config --file non-existing-config -l
+'
cat > other-config << EOF
[ein]
@@ -444,8 +476,10 @@ test_expect_success 'alternative GIT_CONFIG' '
test_cmp expect output
'
-test_expect_success 'alternative GIT_CONFIG (--file)' \
- 'git config --file other-config -l > output && cmp output expect'
+test_expect_success 'alternative GIT_CONFIG (--file)' '
+ git config --file other-config -l > output &&
+ test_cmp expect output
+'
test_expect_success 'refer config from subdirectory' '
mkdir x &&
@@ -489,8 +523,9 @@ EOF
weird
EOF
-test_expect_success "rename section" \
- "git config --rename-section branch.eins branch.zwei"
+test_expect_success 'rename section' '
+ git config --rename-section branch.eins branch.zwei
+'
cat > expect << EOF
# Hallo
@@ -503,17 +538,22 @@ test_expect_success "rename succeeded" "test_cmp expect .git/config"
weird
EOF
-test_expect_success "rename succeeded" "test_cmp expect .git/config"
+test_expect_success 'rename succeeded' '
+ test_cmp expect .git/config
+'
-test_expect_success "rename non-existing section" '
+test_expect_success 'rename non-existing section' '
test_must_fail git config --rename-section \
branch."world domination" branch.drei
'
-test_expect_success "rename succeeded" "test_cmp expect .git/config"
+test_expect_success 'rename succeeded' '
+ test_cmp expect .git/config
+'
-test_expect_success "rename another section" \
- 'git config --rename-section branch."1 234 blabl/a" branch.drei'
+test_expect_success 'rename another section' '
+ git config --rename-section branch."1 234 blabl/a" branch.drei
+'
cat > expect << EOF
# Hallo
@@ -526,14 +566,17 @@ EOF
weird
EOF
-test_expect_success "rename succeeded" "test_cmp expect .git/config"
+test_expect_success 'rename succeeded' '
+ test_cmp expect .git/config
+'
cat >> .git/config << EOF
[branch "vier"] z = 1
EOF
-test_expect_success "rename a section with a var on the same line" \
- 'git config --rename-section branch.vier branch.zwei'
+test_expect_success 'rename a section with a var on the same line' '
+ git config --rename-section branch.vier branch.zwei
+'
cat > expect << EOF
# Hallo
@@ -548,7 +591,9 @@ EOF
z = 1
EOF
-test_expect_success "rename succeeded" "test_cmp expect .git/config"
+test_expect_success 'rename succeeded' '
+ test_cmp expect .git/config
+'
test_expect_success 'renaming empty section name is rejected' '
test_must_fail git config --rename-section branch.zwei ""
@@ -562,7 +607,9 @@ EOF
[branch "zwei"] a = 1 [branch "vier"]
EOF
-test_expect_success "remove section" "git config --remove-section branch.zwei"
+test_expect_success 'remove section' '
+ git config --remove-section branch.zwei
+'
cat > expect << EOF
# Hallo
@@ -571,8 +618,9 @@ EOF
weird
EOF
-test_expect_success "section was removed properly" \
- "test_cmp expect .git/config"
+test_expect_success 'section was removed properly' '
+ test_cmp expect .git/config
+'
cat > expect << EOF
[gitcvs]
@@ -583,7 +631,6 @@ test_expect_success 'section ending' '
EOF
test_expect_success 'section ending' '
-
rm -f .git/config &&
git config gitcvs.enabled true &&
git config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite &&
@@ -593,30 +640,25 @@ test_expect_success 'invalid unit' '
'
test_expect_success numbers '
-
git config kilo.gram 1k &&
git config mega.ton 1m &&
- k=$(git config --int --get kilo.gram) &&
- test z1024 = "z$k" &&
- m=$(git config --int --get mega.ton) &&
- test z1048576 = "z$m"
+ echo 1024 >expect &&
+ echo 1048576 >>expect &&
+ git config --int --get kilo.gram >actual &&
+ git config --int --get mega.ton >>actual &&
+ test_cmp expect actual
'
-cat > expect <<EOF
-fatal: bad config value for 'aninvalid.unit' in .git/config
-EOF
-
test_expect_success 'invalid unit' '
-
git config aninvalid.unit "1auto" &&
- s=$(git config aninvalid.unit) &&
- test "z1auto" = "z$s" &&
- if git config --int --get aninvalid.unit 2>actual
- then
- echo config should have failed
- false
- fi &&
- cmp actual expect
+ echo 1auto >expect &&
+ git config aninvalid.unit >actual &&
+ test_cmp expect actual &&
+ cat > expect <<-\EOF
+ fatal: bad config value for '\''aninvalid.unit'\'' in .git/config
+ EOF
+ test_must_fail git config --int --get aninvalid.unit 2>actual &&
+ test_cmp actual expect
'
cat > expect << EOF
@@ -646,7 +688,7 @@ test_expect_success bool '
git config --bool --get bool.true$i >>result
git config --bool --get bool.false$i >>result
done &&
- cmp expect result'
+ test_cmp expect result'
test_expect_success 'invalid bool (--get)' '
@@ -680,7 +722,7 @@ test_expect_success 'set --bool' '
git config --bool bool.false2 "" &&
git config --bool bool.false3 nO &&
git config --bool bool.false4 FALSE &&
- cmp expect .git/config'
+ test_cmp expect .git/config'
cat > expect <<\EOF
[int]
@@ -695,39 +737,37 @@ cat >expect <<\EOF
git config --int int.val1 01 &&
git config --int int.val2 -1 &&
git config --int int.val3 5m &&
- cmp expect .git/config'
+ test_cmp expect .git/config
+'
-cat >expect <<\EOF
-[bool]
- true1 = true
+test_expect_success 'get --bool-or-int' '
+ cat >.git/config <<-\EOF &&
+ [bool]
+ true1
true2 = true
- false1 = false
- false2 = false
-[int]
+ false = false
+ [int]
int1 = 0
int2 = 1
int3 = -1
-EOF
-
-test_expect_success 'get --bool-or-int' '
- rm -f .git/config &&
- (
- echo "[bool]"
- echo true1
- echo true2 = true
- echo false = false
- echo "[int]"
- echo int1 = 0
- echo int2 = 1
- echo int3 = -1
- ) >>.git/config &&
- test $(git config --bool-or-int bool.true1) = true &&
- test $(git config --bool-or-int bool.true2) = true &&
- test $(git config --bool-or-int bool.false) = false &&
- test $(git config --bool-or-int int.int1) = 0 &&
- test $(git config --bool-or-int int.int2) = 1 &&
- test $(git config --bool-or-int int.int3) = -1
-
+ EOF
+ cat >expect <<-\EOF &&
+ true
+ true
+ false
+ 0
+ 1
+ -1
+ EOF
+ {
+ git config --bool-or-int bool.true1 &&
+ git config --bool-or-int bool.true2 &&
+ git config --bool-or-int bool.false &&
+ git config --bool-or-int int.int1 &&
+ git config --bool-or-int int.int2 &&
+ git config --bool-or-int int.int3
+ } >actual &&
+ test_cmp expect actual
'
cat >expect <<\EOF
@@ -844,7 +884,7 @@ test_expect_success 'value continued on next line' '
test_expect_success 'value continued on next line' '
git config --list > result &&
- cmp result expect
+ test_cmp result expect
'
cat > .git/config <<\EOF
@@ -880,11 +920,12 @@ test_expect_success SYMLINKS 'symlinked configuration' '
test_expect_success 'inner whitespace kept verbatim' '
git config section.val "foo bar" &&
- test "z$(git config section.val)" = "zfoo bar"
+ echo "foo bar" >expect &&
+ git config section.val >actual &&
+ test_cmp expect actual
'
test_expect_success SYMLINKS 'symlinked configuration' '
-
ln -s notyet myconfig &&
GIT_CONFIG=myconfig git config test.frotz nitfol &&
test -h myconfig &&
@@ -893,9 +934,15 @@ test_expect_success SYMLINKS 'symlinked configuration' '
GIT_CONFIG=myconfig git config test.xyzzy rezrov &&
test -h myconfig &&
test -f notyet &&
- test "z$(GIT_CONFIG=notyet git config test.frotz)" = znitfol &&
- test "z$(GIT_CONFIG=notyet git config test.xyzzy)" = zrezrov
-
+ cat >expect <<-\EOF &&
+ nitfol
+ rezrov
+ EOF
+ {
+ GIT_CONFIG=notyet git config test.frotz &&
+ GIT_CONFIG=notyet git config test.xyzzy
+ } >actual &&
+ test_cmp expect actual
'
test_expect_success 'nonexistent configuration' '
@@ -927,12 +974,20 @@ test_expect_success 'git -c "key=value" support' '
git commit -m 'initial commit' &&
git config branch.master.mergeoptions 'echo \"' &&
test_must_fail git merge master
- "
+"
test_expect_success 'git -c "key=value" support' '
- test "z$(git -c core.name=value config core.name)" = zvalue &&
- test "z$(git -c foo.CamelCase=value config foo.camelcase)" = zvalue &&
- test "z$(git -c foo.flag config --bool foo.flag)" = ztrue &&
+ cat >expect <<-\EOF &&
+ value
+ value
+ true
+ EOF
+ {
+ git -c core.name=value config core.name &&
+ git -c foo.CamelCase=value config foo.camelcase &&
+ git -c foo.flag config --bool foo.flag
+ } >actual &&
+ test_cmp expect actual &&
test_must_fail git -c name=value config core.name
'
--
1.8.0.3.g3456896
^ permalink raw reply related
* Re: Large number of object files
From: Nguyen Thai Ngoc Duy @ 2012-10-24 6:59 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5AS1=Cf--0=1Xynxf1J-22fxBq05XjNGMcUep+ndAOO7ig@mail.gmail.com>
On Wed, Oct 24, 2012 at 12:21 PM, Uri Moszkowicz <uri@4refs.com> wrote:
> Continuing to work on improving clone times, using "git gc
> --aggressive" has resulted in a large number of tags combining into a
> single file but now I have a large number of files in the objects
> directory - 131k for a ~2.7GB repository.
Can you paste "git count-objects -v"? I'm curious why gc keeps so many
loose objects around.
> Any way to reduce the number of these files to speed up clones?
An easy way to get rid of them is to clone the non-local way.
Everything will be sent over a pack, the result would be a single pack
in new repo. Try "git clone file:///path/to/source/repo new-repo". You
can also try "git prune" on the existing repo (read its man page
before use).
--
Duy
^ permalink raw reply
* Re: [PATCH 1/8] t1300: style updates
From: Jeff King @ 2012-10-24 6:37 UTC (permalink / raw)
To: Johannes Sixt
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano
In-Reply-To: <50878BAB.60809@viscovery.net>
On Wed, Oct 24, 2012 at 08:33:15AM +0200, Johannes Sixt wrote:
> Am 10/24/2012 0:35, schrieb Jeff King:
> > -test_expect_success 'non-match value' \
> > - 'test wow = $(git config --get nextsection.nonewline !for)'
> > +test_expect_success 'non-match value' '
> > + test wow = $(git config --get nextsection.nonewline !for)
> > +'
>
> Here's a case you forgot to update to test_cmp.
Thanks. I noticed I left quite a few of those in (the other changes I
did mechanically, but I only fixed up the "test" ones in nearby spots).
> > +test_expect_success 'get-regexp variable with no value' '
> > + git config --get-regexp novalue > output &&
> > + test_cmp expect output'
>
> And while you are here, you might want to remove this extra space. ;)
>
> Otherwise, looks fine.
Thanks, I'll fix up both.
-Peff
^ permalink raw reply
* Re: [PATCH 8/8] git-config: use git_config_with_options
From: Johannes Sixt @ 2012-10-24 6:33 UTC (permalink / raw)
To: Jeff King
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano
In-Reply-To: <20121023224119.GH17392@sigill.intra.peff.net>
All looked sane. Thanks for a pleasant read!
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/8] t1300: style updates
From: Johannes Sixt @ 2012-10-24 6:33 UTC (permalink / raw)
To: Jeff King
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano
In-Reply-To: <20121023223554.GA17392@sigill.intra.peff.net>
Am 10/24/2012 0:35, schrieb Jeff King:
> -test_expect_success 'non-match value' \
> - 'test wow = $(git config --get nextsection.nonewline !for)'
> +test_expect_success 'non-match value' '
> + test wow = $(git config --get nextsection.nonewline !for)
> +'
Here's a case you forgot to update to test_cmp.
> +test_expect_success 'get-regexp variable with no value' '
> + git config --get-regexp novalue > output &&
> + test_cmp expect output'
And while you are here, you might want to remove this extra space. ;)
Otherwise, looks fine.
-- Hannes
^ permalink raw reply
* Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
From: Johannes Sixt @ 2012-10-24 6:02 UTC (permalink / raw)
To: Jeff King
Cc: Marc Gauthier, Thomas Gleixner, Al Viro, Chris Metcalf, LKML,
linux-arch@vger.kernel.org, Linus Torvalds, Catalin Marinas,
git@vger.kernel.org, Junio C Hamano
In-Reply-To: <20121023222318.GA3055@sigill.intra.peff.net>
Am 10/24/2012 0:23, schrieb Jeff King:
> For the fold-on-rebase idea, I'd think you would want something similar,
> like setting rebase.foldNotes to "foo" to say "refs/notes/foo contains
> pseudo-headers that should be folded in like a signed-off-by".
If you are rebasing anyway, you can already use interactive rebase's
--autosquash option:
# a late ACK came in:
git commit --allow-empty -m'squash! tile: support GENERIC_
Acked-by: A U Thor <author@example.com>'
git rebase -i --keep-empty --autosquash $forkpoint
Requires git 1.7.11 for --keep-empty and requires to edit out the
'squash!...' headers when the editor appears during the rebase.
-- Hannes
^ permalink raw reply
* Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
From: Ingo Molnar @ 2012-10-24 6:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Jeff King, Al Viro, Chris Metcalf, LKML,
linux-arch, Catalin Marinas, git, Junio C Hamano
In-Reply-To: <CA+55aFyYD2jvD3+TSe=GhBgg5UQt2RNFdYf6HGiKRX-xWzFmdw@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >>
> >> It is spelled:
> >>
> >> git notes add -m <comment> SHA1
> >
> > Cool!
>
> Don't use them for anything global.
>
> Use them for local codeflow, but don't expect them to be
> distributed. It's a separate "flow", and while it *can* be
> distributed, it's not going to be for the kernel, for example.
> So no, don't start using this to ack things, because the acks
> *will* get lost.
I'd also add a small meta argument: that it would be actively
wrong to *allow* 'belated' acks to be added. In practice acks
are most useful *before* a commit gets created and they often
have a mostly buerocratic role afterwards.
So we should encourage timely acks (which actually help
development), and accept ack-less patches as long as they are
correct and create no problems. More utility, less buerocracy.
Incorrect, ack-less patches causing problems will get all the
flames they deserve.
Thanks,
Ingo
^ permalink raw reply
* Large number of object files
From: Uri Moszkowicz @ 2012-10-24 5:21 UTC (permalink / raw)
To: git
Continuing to work on improving clone times, using "git gc
--aggressive" has resulted in a large number of tags combining into a
single file but now I have a large number of files in the objects
directory - 131k for a ~2.7GB repository. Any way to reduce the number
of these files to speed up clones?
^ permalink raw reply
* Re: Long clone time after "done."
From: Nguyen Thai Ngoc Duy @ 2012-10-24 4:29 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5AQBbnFqT5xrFuPOEsJevwDE=jUgBVFZ5KqTZk5zv5+NOw@mail.gmail.com>
On Wed, Oct 24, 2012 at 1:30 AM, Uri Moszkowicz <uri@4refs.com> wrote:
> I have a large repository which I ran "git gc --aggressive" on that
> I'm trying to clone on a local file system. I would expect it to
> complete very quickly with hard links but it's taking about 6min to
> complete with no checkout (git clone -n). I see the message "Clining
> into 'repos'... done." appear after a few seconds but then Git just
> hangs there for another 6min. Any idea what it's doing at this point
> and how I can speed it up?
"done." is printed by clone_local(), which is called in cmd_clone().
After that there are just a few more calls. Maybe you could add a few
printf in between these calls, see which one takes most time?
--
Duy
^ permalink raw reply
* Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
From: Linus Torvalds @ 2012-10-24 2:14 UTC (permalink / raw)
To: Al Viro
Cc: Thomas Gleixner, Jeff King, Chris Metcalf, LKML, linux-arch,
Catalin Marinas, git, Junio C Hamano
In-Reply-To: <20121024015613.GB2616@ZenIV.linux.org.uk>
On Wed, Oct 24, 2012 at 4:56 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> How about git commit --allow-empty, with
> "belated ACK for <commit>
Don't bother. It's not that important, and it's just distracting.
It's not like this is vital information. If you pushed it out without
the ack, it's out without the ack. Big deal.
Linus
^ permalink raw reply
* RE: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
From: Marc Gauthier @ 2012-10-23 22:06 UTC (permalink / raw)
To: Jeff King, Thomas Gleixner
Cc: Al Viro, Chris Metcalf, LKML, linux-arch@vger.kernel.org,
Linus Torvalds, Catalin Marinas, git@vger.kernel.org,
Junio C Hamano
In-Reply-To: <20121023214717.GA29306@sigill.intra.peff.net>
Jeff King wrote:
> On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote:
> > > The resulting notes are stored in a separate
> > > revision-controlled branch
> >
> > Which branch(es) is/are that ? What are the semantics of that?
[...]
Nice feature.
Can a later commit be eventually be made to reference some set
of notes added so far, so they become part of the whole history
signed by the HEAD SHA1? hence pulled/pushed automatically as
well. Otherwise do you not end up with a forever growing separate
tree of notes that loses some of the properties of being behind
the head SHA1 (and perhaps less scalable in manageability)?
Also that way notes are separate only temporarily.
As for automating the inclusion of notes in the flow, can that
be conditional on some pattern in the note, so that e.g. the
Acked-by's get included and folded in automatically, whereas
others do not, according to settings?
-Marc
^ permalink raw reply
* Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
From: Al Viro @ 2012-10-24 1:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Jeff King, Chris Metcalf, LKML, linux-arch,
Catalin Marinas, git, Junio C Hamano
In-Reply-To: <CA+55aFyYD2jvD3+TSe=GhBgg5UQt2RNFdYf6HGiKRX-xWzFmdw@mail.gmail.com>
On Wed, Oct 24, 2012 at 04:02:49AM +0300, Linus Torvalds wrote:
> On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >>
> >> It is spelled:
> >>
> >> git notes add -m <comment> SHA1
> >
> > Cool!
>
> Don't use them for anything global.
>
> Use them for local codeflow, but don't expect them to be distributed.
> It's a separate "flow", and while it *can* be distributed, it's not
> going to be for the kernel, for example. So no, don't start using this
> to ack things, because the acks *will* get lost.
How about git commit --allow-empty, with
"belated ACK for <commit>
Acked-by: <...>
" as commit message? I mean, that ought to work and propagate sanely,
but I'm really not sure if that's something in a good taste and should
be allowed as a common practice...
^ permalink raw reply
* Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
From: Linus Torvalds @ 2012-10-24 1:02 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Jeff King, Al Viro, Chris Metcalf, LKML, linux-arch,
Catalin Marinas, git, Junio C Hamano
In-Reply-To: <alpine.LFD.2.02.1210232307480.2756@ionos>
On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> It is spelled:
>>
>> git notes add -m <comment> SHA1
>
> Cool!
Don't use them for anything global.
Use them for local codeflow, but don't expect them to be distributed.
It's a separate "flow", and while it *can* be distributed, it's not
going to be for the kernel, for example. So no, don't start using this
to ack things, because the acks *will* get lost.
Linus
^ permalink raw reply
* Re: The config include mechanism doesn't allow for overwriting
From: Jeff King @ 2012-10-24 0:51 UTC (permalink / raw)
To: John Szakmeister
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Junio C Hamano
In-Reply-To: <CAEBDL5V0Ffyp306rVo-USCBy_AXXMHXN1yrWmkF1BhzFaq60nA@mail.gmail.com>
On Tue, Oct 23, 2012 at 08:46:47PM -0400, John Szakmeister wrote:
> On Tue, Oct 23, 2012 at 10:13 AM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
> [snip]
> > And git config --get foo.bar will give you:
> >
> > $ git config -f /tmp/test --get foo.bar
> > one
> > error: More than one value for the key foo.bar: two
> > error: More than one value for the key foo.bar: three
> >
> > I think that it would be better if the config mechanism just silently
> > overwrote keys that clobbered earlier keys like your patch does.
> >
> > But in addition can we simplify things for the consumers of
> > "git-{config,var} -l" by only printing:
> >
> > foo.bar=three
> >
> > Or are there too many variables like "include.path" that can
> > legitimately appear more than once.
>
> I frequently use pushurl in my remotes to push my master branch both
> to the original repo and my forked version. I find it very helpful in
> my workflow, and would hate to lose that. That said, I do like the
> idea of having a config file and the ability to override some of the
> variables.
No, that won't go anywhere. We really do have two classes of variables:
things that are expected to be single values, and things that are
expected to be lists.
From the perspective of the config code, we don't know or care which is
which, and just feed all entries sequentially to a C callback. In
practice, the callbacks do one of two things:
1. Append the values into a list.
2. Overwrite, and end up with the final value seen.
The trouble is that git-config has to print the values in a reasonable
way, so it asks the caller to give a hint about which it wants (--get
versus --get-all). But in the single-value case did not behave like the
C callbacks, which is what my series fixes.
Using "git config -l" is more like asking the config machinery to just
feed us everything, which is what the C callbacks see. Which is more
flexible, but way less convenient for the caller. But it doesn't need to
be fixed, since the caller has all the information to implement whatever
semantics they like.
-Peff
^ permalink raw reply
* Re: The config include mechanism doesn't allow for overwriting
From: John Szakmeister @ 2012-10-24 0:46 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jeff King, Git Mailing List, Junio C Hamano
In-Reply-To: <CACBZZX5mOb7_i9r8AqNK5V3r-gVnzN+rkeY9xrhecGv1rS-anA@mail.gmail.com>
On Tue, Oct 23, 2012 at 10:13 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
[snip]
> And git config --get foo.bar will give you:
>
> $ git config -f /tmp/test --get foo.bar
> one
> error: More than one value for the key foo.bar: two
> error: More than one value for the key foo.bar: three
>
> I think that it would be better if the config mechanism just silently
> overwrote keys that clobbered earlier keys like your patch does.
>
> But in addition can we simplify things for the consumers of
> "git-{config,var} -l" by only printing:
>
> foo.bar=three
>
> Or are there too many variables like "include.path" that can
> legitimately appear more than once.
I frequently use pushurl in my remotes to push my master branch both
to the original repo and my forked version. I find it very helpful in
my workflow, and would hate to lose that. That said, I do like the
idea of having a config file and the ability to override some of the
variables.
-John
^ permalink raw reply
* git submodule sync --recursive
From: Phil Hord @ 2012-10-23 23:15 UTC (permalink / raw)
To: git; +Cc: phil.hord, Jens Lehmann
In-Reply-To: <507EF86C.4050807@web.de>
[PATCH 1/2] Teach --recursive to submodule sync
[PATCH 2/2] Add tests for submodule sync --recursive
This series implements and tests git submodule sync --recursive
^ permalink raw reply
* [PATCH 2/2] Add tests for submodule sync --recursive
From: Phil Hord @ 2012-10-23 23:15 UTC (permalink / raw)
To: git; +Cc: phil.hord, Jens Lehmann, Phil Hord
In-Reply-To: <1351034141-2641-1-git-send-email-hordp@cisco.com>
Signed-off-by: Phil Hord <hordp@cisco.com>
---
t/t7403-submodule-sync.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh
index 524d5c1..94e26c4 100755
--- a/t/t7403-submodule-sync.sh
+++ b/t/t7403-submodule-sync.sh
@@ -17,18 +17,25 @@ test_expect_success setup '
git commit -m upstream &&
git clone . super &&
git clone super submodule &&
+ (cd submodule &&
+ git submodule add ../submodule sub-submodule &&
+ test_tick &&
+ git commit -m "sub-submodule"
+ ) &&
(cd super &&
git submodule add ../submodule submodule &&
test_tick &&
git commit -m "submodule"
) &&
git clone super super-clone &&
- (cd super-clone && git submodule update --init) &&
+ (cd super-clone && git submodule update --init --recursive) &&
git clone super empty-clone &&
(cd empty-clone && git submodule init) &&
git clone super top-only-clone &&
git clone super relative-clone &&
- (cd relative-clone && git submodule update --init)
+ (cd relative-clone && git submodule update --init --recursive) &&
+ git clone super recursive-clone &&
+ (cd recursive-clone && git submodule update --init --recursive)
'
test_expect_success 'change submodule' '
@@ -46,6 +53,11 @@ test_expect_success 'change submodule url' '
git pull
) &&
mv submodule moved-submodule &&
+ (cd moved-submodule &&
+ git config -f .gitmodules submodule.sub-submodule.url ../moved-submodule &&
+ test_tick &&
+ git commit -a -m moved-sub-submodule
+ ) &&
(cd super &&
git config -f .gitmodules submodule.submodule.url ../moved-submodule &&
test_tick &&
@@ -61,6 +73,9 @@ test_expect_success '"git submodule sync" should update submodule URLs' '
test -d "$(cd super-clone/submodule &&
git config remote.origin.url
)" &&
+ test ! -d "$(cd super-clone/submodule/sub-submodule &&
+ git config remote.origin.url
+ )" &&
(cd super-clone/submodule &&
git checkout master &&
git pull
@@ -70,6 +85,25 @@ test_expect_success '"git submodule sync" should update submodule URLs' '
)
'
+test_expect_success '"git submodule sync --recursive" should update all submodule URLs' '
+ (cd super-clone &&
+ (cd submodule &&
+ git pull --no-recurse-submodules
+ ) &&
+ git submodule sync --recursive
+ ) &&
+ test -d "$(cd super-clone/submodule &&
+ git config remote.origin.url
+ )" &&
+ test -d "$(cd super-clone/submodule/sub-submodule &&
+ git config remote.origin.url
+ )" &&
+ (cd super-clone/submodule/sub-submodule &&
+ git checkout master &&
+ git pull
+ )
+'
+
test_expect_success '"git submodule sync" should update known submodule URLs' '
(cd empty-clone &&
git pull &&
@@ -107,6 +141,23 @@ test_expect_success '"git submodule sync" handles origin URL of the form foo/bar
#actual foo/submodule
test "$(git config remote.origin.url)" = "../foo/submodule"
)
+ (cd submodule/sub-submodule &&
+ test "$(git config remote.origin.url)" != "../../foo/submodule"
+ )
+ )
+'
+
+test_expect_success '"git submodule sync --recursive" propagates changes in origin' '
+ (cd recursive-clone &&
+ git remote set-url origin foo/bar &&
+ git submodule sync --recursive &&
+ (cd submodule &&
+ #actual foo/submodule
+ test "$(git config remote.origin.url)" = "../foo/submodule"
+ )
+ (cd submodule/sub-submodule &&
+ test "$(git config remote.origin.url)" = "../../foo/submodule"
+ )
)
'
--
1.8.0.2.gcde19fc.dirty
^ permalink raw reply related
* [PATCH 1/2] Teach --recursive to submodule sync
From: Phil Hord @ 2012-10-23 23:15 UTC (permalink / raw)
To: git; +Cc: phil.hord, Jens Lehmann, Phil Hord
In-Reply-To: <1351034141-2641-1-git-send-email-hordp@cisco.com>
The submodule sync command was somehow left out when
--recursive was added to the other submodule commands.
Teach sync to handle the --recursive switch by recursing
when we're in a submodule we are sync'ing.
Change the report during sync to show submodule-path
instead of submodule-name to be consistent with the other
submodule commands and to help recursed paths make sense.
Signed-off-by: Phil Hord <hordp@cisco.com>
---
git-submodule.sh | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..6dd2338 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -11,7 +11,7 @@ USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <r
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
- or: $dashless [--quiet] sync [--] [<path>...]"
+ or: $dashless [--quiet] sync [--recursive] [--] [<path>...]"
OPTIONS_SPEC=
. git-sh-setup
. git-sh-i18n
@@ -1008,7 +1008,9 @@ cmd_sync()
case "$1" in
-q|--quiet)
GIT_QUIET=1
- shift
+ ;;
+ --recursive)
+ recursive=1
;;
--)
shift
@@ -1021,6 +1023,8 @@ cmd_sync()
break
;;
esac
+ orig_flags="$orig_flags $(git rev-parse --sq-quote "$1")"
+ shift
done
cd_to_toplevel
module_list "$@" |
@@ -1051,7 +1055,7 @@ cmd_sync()
if git config "submodule.$name.url" >/dev/null 2>/dev/null
then
- say "$(eval_gettext "Synchronizing submodule url for '\$name'")"
+ say "$(eval_gettext "Synchronizing submodule url for '\$prefix\$sm_path'")"
git config submodule."$name".url "$super_config_url"
if test -e "$sm_path"/.git
@@ -1061,6 +1065,14 @@ cmd_sync()
cd "$sm_path"
remote=$(get_default_remote)
git config remote."$remote".url "$sub_origin_url"
+
+ if test -n "$recursive"
+ then
+ (
+ prefix="$prefix$sm_path/"
+ eval cmd_sync "$orig_args"
+ )
+ fi
)
fi
fi
--
1.8.0.2.gcde19fc.dirty
^ permalink raw reply related
* Re: Git submodule for a local branch?
From: W. Trevor King @ 2012-10-23 22:09 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git
In-Reply-To: <508704D5.9020902@web.de>
[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]
On Tue, Oct 23, 2012 at 10:57:57PM +0200, Jens Lehmann wrote:
> Am 22.10.2012 14:37, schrieb W. Trevor King:
> > but cloning a remote repository (vs. checking out a local branch)
> > seems to be baked into the submodule implementation. Should I be
> > thinking about generalizing git-submodule.sh, or am I looking under
> > the wrong rock? My ideal syntax would be something like
> >
> > $ git submodule add -b c --local dir-for-c/
>
> But then we'd have to be able to have two (or more) work trees using
> the same git directory, which current submodule code can't.
And that's the problem I'm trying to solve ;).
> > The motivation is that I have website that contains a bunch of
> > sub-sites, and the sub-sites share content. I have per-sub-site
> > branches (a, b, c) and want a master branch (index) that aggregates
> > them. Perhaps this is too much to wedge into a single repository?
>
> To me this sounds upside-down. I'd put the three sub-sites into
> different repositories and the shared content into a submodule that
> all three sub-sites use. At least that is how I do all my content
> sharing on the websites I have done ... does that make sense?
That makes sense, however the problem is not in the common content, it
is in the final index:
index
|-- sub-site a (branch of sub-site-x)
|-- sub-site b (branch of sub-site-x)
`-- sub-site c (branch of sub-site-x)
All of the sub-sites are branches of a single sub-site-x master:
o--o--o--o sub-site-x
\--o--o--o sub-site-1
\--o sub-site-2
\--o sub-site-3
So they all live in the same repository. My index repository will
have submodules for each of the sub-sites, and I'd like the index
branch to *also* live in same repository as the subsites. This last
bit is the sticky part.
For a proof-of-concept example (where I currently use public
repositories for the sub-site submodules), see
http://wking.github.com/swc-workshop/
which uses gh-pages as the index branch, and master, 2012-10-caltech,
and 2012-10-lbl for the sub-site branches.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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