* [PATCH] submodule update: document exisiting -r form for --rebase
From: W. Trevor King @ 2012-11-28 18:28 UTC (permalink / raw)
To: Git; +Cc: W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 3 ++-
git-submodule.sh | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..ec78fa7 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [-r|--rebase]
[--reference <repository>] [--merge] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
[commit] [--] [<path>...]
@@ -251,6 +251,7 @@ OPTIONS
If the key `submodule.$name.update` is set to `merge`, this option is
implicit.
+-r::
--rebase::
This option is only valid for the update command.
Rebase the current branch onto the commit recorded in the
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..f2e8026 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,7 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
- or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
+ or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [-r|--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>...]"
--
1.8.0.2.gcc766b6
^ permalink raw reply related
* [PATCH 6/5] t9001: check send-email behavior with implicit sender
From: Jeff King @ 2012-11-28 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <20121128182534.GA21020@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 01:25:35PM -0500, Jeff King wrote:
> Here are the cleanups and refactorings split out from my
> jk/send-email-sender-prompt series. They can go right on master and are
> independent of Felipe's fc/send-email-no-sender-prompt topic.
> [...]
> Dropped were:
> [...]
> - send-email prompting change; obsoleted by Felipe's patch
Here is one more patch pulling out the extra tests from my final commit.
It needs to go on top of the merge of Felipe's series and the one I just
sent. The former because of the new prompting behavior, and the latter
because of the AUTOIDENT prerequisites.
If it's simpler, my whole series can just go on top of Felipe's patch
(or vice versa).
-- >8 --
Subject: [PATCH] t9001: check send-email behavior with implicit sender
We allow send-email to use an implicitly-defined identity
for the sender (because there is still a confirmation step),
but we abort when we cannot generate such an identity. Let's
make sure that we test this.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t9001-send-email.sh | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index c5d66cf..27edfa8 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -201,6 +201,34 @@ test_expect_success $PREREQ 'Prompting works' '
grep "^To: to@example.com\$" msgtxt1
'
+test_expect_success $PREREQ,AUTOIDENT 'implicit ident is allowed' '
+ clean_fake_sendmail &&
+ (sane_unset GIT_AUTHOR_NAME &&
+ sane_unset GIT_AUTHOR_EMAIL &&
+ sane_unset GIT_COMMITTER_NAME &&
+ sane_unset GIT_COMMITTER_EMAIL &&
+ GIT_SEND_EMAIL_NOTTY=1 git send-email \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --to=to@example.com \
+ $patches \
+ </dev/null 2>errors
+ )
+'
+
+test_expect_success $PREREQ,!AUTOIDENT 'broken implicit ident aborts send-email' '
+ clean_fake_sendmail &&
+ (sane_unset GIT_AUTHOR_NAME &&
+ sane_unset GIT_AUTHOR_EMAIL &&
+ sane_unset GIT_COMMITTER_NAME &&
+ sane_unset GIT_COMMITTER_EMAIL &&
+ GIT_SEND_EMAIL_NOTTY=1 && export GIT_SEND_EMAIL_NOTTY &&
+ test_must_fail git send-email \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $patches </dev/null 2>errors &&
+ test_i18ngrep "tell me who you are" errors
+ )
+'
+
test_expect_success $PREREQ 'tocmd works' '
clean_fake_sendmail &&
cp $patches tocmd.patch &&
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* Re: [PATCH 6/5] t9001: check send-email behavior with implicit sender
From: Junio C Hamano @ 2012-11-28 18:55 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git
In-Reply-To: <20121128184229.GA3993@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 28, 2012 at 01:25:35PM -0500, Jeff King wrote:
>
>> Here are the cleanups and refactorings split out from my
>> jk/send-email-sender-prompt series. They can go right on master and are
>> independent of Felipe's fc/send-email-no-sender-prompt topic.
>> [...]
>> Dropped were:
>> [...]
>> - send-email prompting change; obsoleted by Felipe's patch
>
> Here is one more patch pulling out the extra tests from my final commit.
> It needs to go on top of the merge of Felipe's series and the one I just
> sent. The former because of the new prompting behavior, and the latter
> because of the AUTOIDENT prerequisites.
>
> If it's simpler, my whole series can just go on top of Felipe's patch
> (or vice versa).
>
> -- >8 --
> Subject: [PATCH] t9001: check send-email behavior with implicit sender
>
> We allow send-email to use an implicitly-defined identity
> for the sender (because there is still a confirmation step),
> but we abort when we cannot generate such an identity. Let's
> make sure that we test this.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> t/t9001-send-email.sh | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index c5d66cf..27edfa8 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -201,6 +201,34 @@ test_expect_success $PREREQ 'Prompting works' '
> grep "^To: to@example.com\$" msgtxt1
> '
>
> +test_expect_success $PREREQ,AUTOIDENT 'implicit ident is allowed' '
> + clean_fake_sendmail &&
> + (sane_unset GIT_AUTHOR_NAME &&
> + sane_unset GIT_AUTHOR_EMAIL &&
> + sane_unset GIT_COMMITTER_NAME &&
> + sane_unset GIT_COMMITTER_EMAIL &&
> + GIT_SEND_EMAIL_NOTTY=1 git send-email \
> + --smtp-server="$(pwd)/fake.sendmail" \
> + --to=to@example.com \
> + $patches \
> + </dev/null 2>errors
> + )
> +'
> +
> +test_expect_success $PREREQ,!AUTOIDENT 'broken implicit ident aborts send-email' '
> + clean_fake_sendmail &&
> + (sane_unset GIT_AUTHOR_NAME &&
> + sane_unset GIT_AUTHOR_EMAIL &&
> + sane_unset GIT_COMMITTER_NAME &&
> + sane_unset GIT_COMMITTER_EMAIL &&
> + GIT_SEND_EMAIL_NOTTY=1 && export GIT_SEND_EMAIL_NOTTY &&
> + test_must_fail git send-email \
> + --smtp-server="$(pwd)/fake.sendmail" \
> + $patches </dev/null 2>errors &&
> + test_i18ngrep "tell me who you are" errors
> + )
> +'
The difference between these two tests should solely come from
AUTOIDENT and nothing else, so it would be better to see their
command line arguments to match; the former is with --to and the
latter is without in this patch but I do not think you meant them to
differ that way.
> test_expect_success $PREREQ 'tocmd works' '
> clean_fake_sendmail &&
> cp $patches tocmd.patch &&
^ permalink raw reply
* Re: [PATCH] completion: add options --single-branch and --branch to "git clone"
From: Junio C Hamano @ 2012-11-28 18:57 UTC (permalink / raw)
To: Ralf Thielow; +Cc: git
In-Reply-To: <1354127222-5569-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow <ralf.thielow@gmail.com> writes:
> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
> ---
> contrib/completion/git-completion.bash | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 48c3abd..cda095d 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -989,6 +989,8 @@ _git_clone ()
> --upload-pack
> --template=
> --depth
> + --single-branch
> + --branch
> "
Hmph.... OK, will queue.
^ permalink raw reply
* Re: [PATCH] submodule update: document exisiting -r form for --rebase
From: Junio C Hamano @ 2012-11-28 19:02 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <0450c75cbab3119ea830e8e8e3484649062377d8.1354127227.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/git-submodule.txt | 3 ++-
> git-submodule.sh | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
Hmm, I wonder why I have this funny feeling that this was proposed
and rejected already...
As the command takes other options whose names begin with 'r', I
thought the longer term plan was to stop letting "--rebase" squat on
short and sweet "-r" and leaving it undocumented (even though the
short one was added by mistake) was meant to be the first step in
that process.
But maybe I am confusing an undocumented single-letter option from
some other subcommand. Anybody remembers?
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index b4683bb..ec78fa7 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -13,7 +13,7 @@ SYNOPSIS
> [--reference <repository>] [--] <repository> [<path>]
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] init [--] [<path>...]
> -'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
> +'git submodule' [--quiet] update [--init] [-N|--no-fetch] [-r|--rebase]
> [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
> [commit] [--] [<path>...]
> @@ -251,6 +251,7 @@ OPTIONS
> If the key `submodule.$name.update` is set to `merge`, this option is
> implicit.
>
> +-r::
> --rebase::
> This option is only valid for the update command.
> Rebase the current branch onto the commit recorded in the
> diff --git a/git-submodule.sh b/git-submodule.sh
> index ab6b110..f2e8026 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -8,7 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
> USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
> or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
> or: $dashless [--quiet] init [--] [<path>...]
> - or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> + or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [-r|--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>...]"
^ permalink raw reply
* Re: [PATCH] svnrdump_sim: start the script with /usr/bin/env python
From: Felipe Contreras @ 2012-11-28 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Christian Couder, git
In-Reply-To: <7vmwy1hdgx.fsf@alter.siamese.dyndns.org>
On Wed, Nov 28, 2012 at 5:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> On Wed, Nov 28, 2012 at 9:03 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> That works if somebody managed to export PYTHON_PATH, which very very
>>> often is not the case for me.
>>
>> Yeah, and even if PYTHON_PATH is used, in t9020-remote-svn.sh,
>> svnrdump.py is used as is.
>
> You need a fix for that; didn't I already say "you need a bit more
> than that"?
I disagree. Most of the contrib scripts are expected to be used as
they are. There's no step in the Makefile that will convert them, and
it's up to each distribution to decide what to do with them. This is
what Arch Linux does:
# more contrib stuff
cp -a ./contrib/* $pkgdir/usr/share/git/
# scripts are for python 2.x
sed -i 's|#![ ]*/usr/bin/env python|#!/usr/bin/env python2|' \
$(find "$pkgdir" -name '*.py') \
"$pkgdir"/usr/lib/git-core/git-p4 \
"$pkgdir"/usr/share/git/gitview/gitview
At some point we might decide to change this, but at the moment
contrib scripts are pretty much stand-alone.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: git fetch pack freezes
From: Shawn Pearce @ 2012-11-28 19:22 UTC (permalink / raw)
To: Ivan Kanis; +Cc: git
In-Reply-To: <87obihhc6q.fsf@visionobjects.com>
On Wed, Nov 28, 2012 at 9:25 AM, Ivan Kanis <ivan.kanis@googlemail.com> wrote:
> Shawn Pearce <spearce@spearce.org> wrote:
>
>> On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis <ivan.kanis@googlemail.com> wrote:
>>>
>>> On the server we are seeing the following error message:
>>
>> Upgrade your server.
>
> OK we'll look into it. I have a question: will a 1.8 server still serve
> 1.7 git client?
Yes.
>> So the stack frames are correct. Its just a problem that the parent
>> didn't identify the server crashing and closing its side of the pipe
>> on stdin to force it to EOF to prevent the child from getting hung
>> here in a read.
>
> It sounds like a bug on the client, doesn't it?
Yes.
^ permalink raw reply
* [PATCH v5 2/2] submodule add: If --branch is given, record it in .gitmodules
From: W. Trevor King @ 2012-11-28 19:30 UTC (permalink / raw)
To: Git
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <cover.1354130656.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This allows you to easily record a submodule.<name>.branch option in
.gitmodules when you add a new submodule. With this patch,
$ git submodule add -b <branch> <repository> [<path>]
$ git config -f .gitmodules submodule.<path>.branch <branch>
reduces to
$ git submodule add -b <branch> <repository> [<path>]
This means that future calls to
$ git submodule update --remote ...
will get updates from the same branch that you used to initialize the
submodule, which is usually what you want.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 2 ++
git-submodule.sh | 4 ++++
t/t7400-submodule-basic.sh | 1 +
3 files changed, 7 insertions(+)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 39aa02d..43e5b4b 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -208,6 +208,8 @@ OPTIONS
-b::
--branch::
Branch of repository to add as submodule.
+ The name of the branch is recorded as `submodule.<path>.branch` in
+ `.gitmodules` for `update --remote`.
-f::
--force::
diff --git a/git-submodule.sh b/git-submodule.sh
index b63d869..1f76893 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -368,6 +368,10 @@ Use -f if you really want to add it." >&2
git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
git config -f .gitmodules submodule."$sm_path".url "$repo" &&
+ if test -n "$branch"
+ then
+ git config -f .gitmodules submodule."$sm_path".branch "$branch"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..90e2915 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '
(
cd addtest &&
git submodule add -b initial "$submodurl" submod-branch &&
+ test "initial" = "$(git config -f .gitmodules submodule.submod-branch.branch)" &&
git submodule init
) &&
--
1.8.0.2.gad10246.dirty
^ permalink raw reply related
* [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-11-28 19:30 UTC (permalink / raw)
To: Git
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <20121128165334.GA20483@odin.tremily.us>
From: "W. Trevor King" <wking@tremily.us>
On Wed, Nov 28, 2012 at 11:53:34AM -0500, W. Trevor King wrote:
> I thought of a better idea on the train. How about adding `--remote`
> to `submodule update` that overrides the gitlinked SHA-1 with the
> SHA-1 for origin/$branch? All of the other checkout/merge/rebase
> functionality is untouched. The only thing that changes is where we
> look for the update. I'm working up the patch now, and will submit v5
> shortly.
Here it is.
Changes since v4:
* Remove `update --branch` in favor of the new `update --remote` logic
as mentioned above.
* Optional config overrides for submodule.<name>.branch (as suggested
by Jens)
* Save --branch as submodule.<name>.branch instead of requiring
--local-branch.
* Restructure doc edits.
I'm a lot happier with this two-patch proposal. The first patch
implements --remote and documents submodule.<name>.branch. The second
patch just gives you a convenient way to set it. I haven't heard from
anyone other than Heiko recently about the --branch/--remote-branch
choice, so I returned to the simpler --branch side effect storage from
v1. I'd be happy to submit v6 with explicit --remote-branch recording
if desired.
W. Trevor King (2):
submodule update: add --remote for submodule's upstream changes
submodule add: If --branch is given, record it in .gitmodules
Documentation/config.txt | 9 +++++----
Documentation/git-submodule.txt | 26 +++++++++++++++++++++++++-
Documentation/gitmodules.txt | 5 +++++
git-submodule.sh | 30 +++++++++++++++++++++++++++++-
t/t7400-submodule-basic.sh | 1 +
t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++
6 files changed, 96 insertions(+), 6 deletions(-)
--
1.8.0.2.gad10246.dirty
^ permalink raw reply
* [PATCH v5 1/2] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-11-28 19:30 UTC (permalink / raw)
To: Git
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <cover.1354130656.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1. This helps you keep up with
changes in the upstream superproject.
However, it's also useful to stay up to date with changes in the
upstream subproject. Previous workflows for incorporating such
changes include the ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates. When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch. If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`. You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).
Previous use of submodule.<name>.branch
=======================================
Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option. The foreach-pull
example above was described by Ævar in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same. The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls. The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`. Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.
Implementation details
======================
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. However, I didn't change the logic guarding the existing fetch:
if test -z "$nofetch"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
fi
There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository. If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/config.txt | 9 +++++----
Documentation/git-submodule.txt | 24 +++++++++++++++++++++++-
Documentation/gitmodules.txt | 5 +++++
git-submodule.sh | 26 +++++++++++++++++++++++++-
t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++
5 files changed, 89 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 11f320b..de39b1c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1994,10 +1994,11 @@ status.submodulesummary::
submodule.<name>.path::
submodule.<name>.url::
submodule.<name>.update::
- The path within this project, URL, and the updating strategy
- for a submodule. These variables are initially populated
- by 'git submodule init'; edit them to override the
- URL and other values found in the `.gitmodules` file. See
+submodule.<name>.branch::
+ The path within this project, URL, the updating strategy, and the
+ remote branch name for a submodule. These variables are initially
+ populated by 'git submodule init'; edit them to override the URL and
+ other values found in the `.gitmodules` file. See
linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
submodule.<name>.fetchRecurseSubmodules::
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..39aa02d 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
+'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [--rebase]
[--reference <repository>] [--merge] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
[commit] [--] [<path>...]
@@ -236,6 +236,28 @@ OPTIONS
(the default). This limit only applies to modified submodules. The
size is always limited to 1 for added/deleted/typechanged submodules.
+--remote::
+ This option is only valid for the update command.
+ Instead of using the superproject's recorded SHA-1 to update the
+ submodule, use the status of the submodule's remote tracking branch.
+ The remote tracking branch defaults to origin/master, but the branch
+ name may be overriden by setting the `submodule.<name>.branch`
+ option in either `.gitmodules` or `.git/config` (with `.git/config`
+ taking precedence).
++
+This works for any of the supported update procedures (`--checkout`,
+`--rebase`, etc.). The only change is the source of the target SHA-1.
+For example, `submodule update --remote --merge` will merge upstream
+submodule changes into the submodules, while `submodule update
+--merge` will merge superproject gitlink changes into the submodules.
++
+In order to ensure a current tracking branch state, `update --remote`
+fetches the submodule's remote repository before calculating the
+SHA-1. This makes `submodule update --remote --merge` similar to
+running `git pull` in the submodule. If you don't want to fetch (for
+something closer to `git merge`), you should use `submodule update
+--remote --no-fetch --merge`.
+
-N::
--no-fetch::
This option is only valid for the update command.
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 4effd78..4004fa6 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -47,6 +47,11 @@ submodule.<name>.update::
This config option is overridden if 'git submodule update' is given
the '--merge', '--rebase' or '--checkout' options.
+submodule.<name>.branch::
+ A remote branch name for tracking updates in the upstream submodule.
+ If the option is not specified, it defaults to 'master'. See the
+ `--remote` documentation in linkgit:git-submodule[1] for details.
+
submodule.<name>.fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
submodule. If this option is also present in the submodules entry in
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..b63d869 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,7 +8,8 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
- or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
+ or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
+ges
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
or: $dashless [--quiet] sync [--] [<path>...]"
@@ -26,6 +27,7 @@ cached=
recursive=
init=
files=
+remote=
nofetch=
update=
prefix=
@@ -509,6 +511,9 @@ cmd_update()
-i|--init)
init=1
;;
+ --remote)
+ remote=1
+ ;;
-N|--no-fetch)
nofetch=1
;;
@@ -569,6 +574,12 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
+ branch=$(git config submodule."$name".branch)
+ if test -z "$branch"
+ then # fall back on .gitmodules
+ branch=$(git config -f .gitmodules submodule."$name".branch)
+ fi
+ branch="${branch:-master}"
if ! test -z "$update"
then
update_module=$update
@@ -603,6 +614,19 @@ Maybe you want to use 'update --init'?")"
die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
fi
+ if test -n "$remote"
+ then
+ if test -z "$nofetch"
+ then
+ # Fetch remote before determining tracking $sha1
+ (clear_local_git_env; cd "$sm_path" && git-fetch) ||
+ die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
+ fi
+ sha1=$(clear_local_git_env; cd "$sm_path" &&
+ git rev-parse --verify origin/"$branch") ||
+ die "$(eval_gettext "Unable to find current origin/$branch revision in submodule path '\$sm_path'")"
+ fi
+
if test "$subsha1" != "$sha1" -o -n "$force"
then
subforce=$force
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 1542653..a567834 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -135,6 +135,37 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '
)
'
+test_expect_success 'submodule update --remote should fetch upstream changes' '
+ (cd submodule &&
+ echo line4 >> file &&
+ git add file &&
+ test_tick &&
+ git commit -m "upstream line4"
+ ) &&
+ (cd super &&
+ git submodule update --remote --force submodule &&
+ cd submodule &&
+ test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline)"
+ )
+'
+
+test_expect_success 'local config should override .gitmodules branch' '
+ (cd submodule &&
+ git checkout -b test-branch &&
+ echo line5 >> file &&
+ git add file &&
+ test_tick &&
+ git commit -m "upstream line5" &&
+ git checkout master
+ ) &&
+ (cd super &&
+ git config submodule.submodule.branch test-branch &&
+ git submodule update --remote --force submodule &&
+ cd submodule &&
+ test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline test-branch)"
+ )
+'
+
test_expect_success 'submodule update --rebase staying on master' '
(cd super/submodule &&
git checkout master
--
1.8.0.2.gad10246.dirty
^ permalink raw reply related
* Re: [PATCH] svnrdump_sim: start the script with /usr/bin/env python
From: Junio C Hamano @ 2012-11-28 19:33 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Christian Couder, Christian Couder, git
In-Reply-To: <CAMP44s3YfLrL+74j5DOVVATK8GWEo1qHnmJDW5dLWJRxK_CVLQ@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Wed, Nov 28, 2012 at 5:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> You need a fix for that; didn't I already say "you need a bit more
>> than that"?
>
> I disagree. Most of the contrib scripts are expected to be used as
> they are.
You are only looking at one of the uses for this script, when there
are two.
You are correct that distros may install with whatever tweaks of
their own, and to help their tweak process (like the one that
specifically notices "/usr/bin/env python" as you wrote), changing
the "#!/usr/bin/python" to match others would be a good change.
But that change alone is not sufficient for this one, which is used
from t/ script. You cannot treat this one like import-zips and
hg-to-git that we do not use in-tree. Somewhere before t9020 uses
it, it needs the treatment similar to the rewriting that is done for
git-p4.py to git-p4.
^ permalink raw reply
* Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: W. Trevor King @ 2012-11-28 19:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann, Nahor
In-Reply-To: <7vzk2oo2d2.fsf@alter.siamese.dyndns.org>
On Wed, Nov 28, 2012 at 11:02:45AM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
>
> > From: "W. Trevor King" <wking@tremily.us>
> >
> > Signed-off-by: W. Trevor King <wking@tremily.us>
> > ---
> > Documentation/git-submodule.txt | 3 ++-
> > git-submodule.sh | 2 +-
> > 2 files changed, 3 insertions(+), 2 deletions(-)
>
> Hmm, I wonder why I have this funny feeling that this was proposed
> and rejected already...
>
> As the command takes other options whose names begin with 'r', I
> thought the longer term plan was to stop letting "--rebase" squat on
> short and sweet "-r" and leaving it undocumented (even though the
> short one was added by mistake) was meant to be the first step in
> that process.
>
> But maybe I am confusing an undocumented single-letter option from
> some other subcommand. Anybody remembers?
Perhaps you are remembering:
On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote:
> Ah, this reminds me of another thing I noticed when I saw that
> patch. The change seems to think "branch" is the _only_ thing the
> user might want to record per submodule upon "git submodule add".
> As an interface to muck with an uninterpreted random configuration,
> it squats on a good option name for setting one single and arbitrary
> variable---quite a selfish change that is not acceptable.
>
> Calling the option "--record-branch-for-submodule" or something more
> specific might alleviate the problem, but then it would become even
> less useful as a short-hand for "config submodule.$name.branch", I
> would suspect.
With this recent patch, I'm just documenting someone else's squatting
;). But yes, the reason I noticed was because I was tempted to make
the same mistake again :p. In my defense, I think `update --remote`
is a good deal more general than my earlier `add --record`.
Cheers,
Trevor
--
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
^ permalink raw reply
* What's cooking in git.git (Nov 2012, #09; Wed, 28)
From: Junio C Hamano @ 2012-11-28 19:54 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'.
Hopefully 1.8.1-rc0 preview will be tagged this weekend. Many
topics are marked to be cooked in 'next' during the feature freeze,
but some topics in flight should be in 'master' before -rc1 happens.
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/append-signed-off-by (2012-11-26) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- 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
- sequencer.c: remove broken support for rfc2822 continuation in footer
Will merge to 'next'.
* er/doc-add-new-commands (2012-11-26) 1 commit
- Documentation: how to add a new command
Will merge to 'next'.
* fc/send-email-no-sender-prompt (2012-11-26) 1 commit
- send-email: avoid questions when user has an ident
(this branch is used by jk/send-email-sender-prompt.)
Will merge to 'next'.
* jl/submodule-rm (2012-11-23) 1 commit
(merged to 'next' on 2012-11-28 at 0e4115f)
+ Teach rm to remove submodules when given with a trailing '/'
Finishing touches to the topic already in 'master'.
Will merge to 'master'.
* km/send-email-remove-cruft-in-address (2012-11-26) 5 commits
- git-send-email: allow edit invalid email address
- git-send-email: ask what to do with an invalid email address
- git-send-email: remove invalid addresses earlier
- git-send-email: fix fallback code in extract_valid_address()
- git-send-email: remove garbage after email address
Will merge to 'next'.
* mh/unify-xml-in-imap-send-and-http-push (2012-11-26) 8 commits
- wrap_in_html(): process message in bulk rather than line-by-line
- wrap_in_html(): use strbuf_addstr_xml_quoted()
- imap-send: change msg_data from storing (char *, len) to storing strbuf
- imap-send: correctly report errors reading from stdin
- imap-send: store all_msgs as a strbuf
- lf_to_crlf(): NUL-terminate msg_data::data
- xml_entities(): use function strbuf_addstr_xml_quoted()
- Add new function strbuf_add_xml_quoted()
* pw/p4-various-fixes (2012-11-26) 6 commits
- git p4: remove unneeded cmd initialization
- git p4: fix labelDetails typo in exception
- git p4 test: display unresolvable host error
- git p4: catch p4 errors when streaming file contents
- git p4: handle servers without move support
- git p4: catch p4 describe errors
Will merge to 'next'.
* rr/t4041-cleanup (2012-11-27) 4 commits
- t4041 (diff-submodule-option): modernize style
- t4041 (diff-submodule-option): rewrite add_file() routine
- t4041 (diff-submodule-option): parse digests sensibly
- t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs
As a clean-up, it still misses some.
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* jc/doc-push-satellite (2012-11-27) 1 commit
- Documentation/git-push.txt: clarify the "push from satellite" workflow
Will merge to 'next'.
* jk/fsck-dot-in-trees (2012-11-28) 1 commit
- fsck: warn about '.' and '..' in trees
Will merge to 'next'.
* lt/diff-stat-show-0-lines (2012-11-27) 6 commits
- diff --shortstat: do not count "unmerged" entries
- diff --stat: do not count "unmerged" entries
- diff --stat: move the "total count" logic to the last loop
- diff --stat: use "file" temporary variable to refer to data->files[i]
- diff --stat: status of unmodified pair in diff-q is not zero
- test: add failing tests for "diff --stat" to t4049
Will merge to 'next'.
* mh/doc-remote-helpers (2012-11-27) 6 commits
- git-remote-helpers.txt: clarify options & ref list attributes
- git-remote-helpers.txt: clarify command <-> capability correspondences
- git-remote-helpers.txt: rearrange description of capabilities
- git-remote-helpers.txt: minor grammar fix
- git-remote-helpers.txt: document missing capabilities
- git-remote-helpers.txt: document invocation before input format
Need comment and Ack from people who have worked on remote-helpers
before this goes forward.
* mh/pthreads-autoconf (2012-11-27) 1 commit
- configure.ac: fix pthreads detection on Mac OS X
Will merge to 'next'.
* mk/complete-tcsh (2012-11-27) 1 commit
- Support for git aliasing for tcsh completion
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* pf/editor-ignore-sigint (2012-11-11) 5 commits
- launch_editor: propagate SIGINT from editor to git
- run-command: do not warn about child death by SIGINT
- run-command: drop silent_exec_failure arg from wait_or_whine
- launch_editor: ignore SIGINT while the editor has control
- launch_editor: refactor to use start/finish_command
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Some people raised issues with emacsclient, which are addressed by this
re-roll. It should probably also handle SIGQUIT, and there were a
handful of other review comments.
Expecting a re-roll.
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* 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.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Is this still in "Needs review" state? Are people involved in the
remote interface happy with this change?
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* 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/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-11-26) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
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.
Waiting for comments.
* 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 re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* mh/ceiling (2012-10-29) 8 commits
(merged to 'next' on 2012-11-26 at d1ce76a)
+ string_list_longest_prefix(): remove function
+ setup_git_directory_gently_1(): resolve symlinks in ceiling paths
+ longest_ancestor_length(): require prefix list entries to be normalized
+ longest_ancestor_length(): take a string_list argument for prefixes
+ longest_ancestor_length(): use string_list_split()
+ Introduce new function real_path_if_valid()
+ real_path_internal(): add comment explaining use of cwd
+ Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
Resurrected from Stalled; the earlier performance fear was
unwarranted.
Will cook in 'next'.
* jk/send-email-sender-prompt (2012-11-28) 7 commits
- t9001: check send-email behavior with implicit sender
- Merge branch 'fc/send-email-no-sender-prompt' into jk/send-email-sender-prompt
- t: add tests for "git var"
- ident: keep separate "explicit" flags for author and committer
- ident: make user_ident_explicitly_given static
- t7502: factor out autoident prerequisite
- test-lib: allow negation of prerequisites
(this branch uses fc/send-email-no-sender-prompt.)
Resurrected only the internal clean-up part.
Will merge to 'next'.
* fc/fast-export-fixes (2012-11-27) 25 commits
- fast-export: trivial cleanups
- fast-export: refactor get_tags_and_duplicates()
- fast-export: make extra_refs global
- transport-helper: fix push without marks
- transport-helper: fix pushing with straight refspec
- transport-helper: fix push without refspec
- transport-helper: trivial code shuffle
- [squash] earlier breakages in t5800 fixed by the previous
- fast-export: don't handle uninteresting refs
- transport-helper: update remote helper namespace
- [squash] previous breaks t5800
- fast-export: make sure updated refs get updated
- fast-export: fix comparison in tests
- fast-export: trivial cleanup
- remote-testgit: implement the "done" feature manually
- remote-testgit: report success after an import
- remote-testgit: exercise more features
- remote-testgit: cleanup tests
- remote-testgit: remove irrelevant test
- remote-testgit: remove non-local functionality
- Add new simplified git-remote-testgit
- Rename git-remote-testgit to git-remote-testpy
- remote-helpers: fix failure message
- remote-testgit: fix direction of marks
- fast-export: avoid importing blob marks
It needs a bit of re-roll or reorder to keep things bisectable, at
least, and with log message here and there to justify non-trivial
bits with something better than unsubstantiated "this is trivial"
claim. Overall, the series looked OK.
* pp/gitweb-config-underscore (2012-11-21) 1 commit
- gitweb: make remote_heads config setting work
The key "gitweb.remote_heads" is not legal git config; this maps it to
"gitweb.remoteheads".
Will merge to 'next'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Will cook in 'next'.
* nd/pathspec-wildcard (2012-11-26) 4 commits
- tree_entry_interesting: do basedir compare on wildcard patterns when possible
- pathspec: apply "*.c" optimization from exclude
- pathspec: do exact comparison on the leading non-wildcard part
- pathspec: save the non-wildcard length part
Will merge to 'next'.
* mm/status-push-pull-advise (2012-11-16) 1 commit
(merged to 'next' on 2012-11-26 at ed40d5e)
+ status: add advice on how to push/pull to tracking branch
Will merge to 'master' in the seventh batch.
* fc/zsh-completion (2012-11-19) 2 commits
(merged to 'next' on 2012-11-26 at 48ebdc9)
+ completion: start moving to the new zsh completion
+ completion: add new zsh completion
Will merge to 'master' in the seventh batch.
* nd/wildmatch (2012-11-20) 14 commits
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* fc/completion-test-simplification (2012-11-16) 6 commits
- completion: simplify __gitcomp() test helper
- completion: refactor __gitcomp related tests
- completion: consolidate test_completion*() tests
- completion: simplify tests using test_completion_long()
- completion: standardize final space marker in tests
- completion: add comment for test_completion()
Clean up completion tests. Use of conslidated helper may make
instrumenting one particular test during debugging of the test
itself, but I think that issue should be addressed in some other
way (e.g. making sure individual tests in 9902 can be skipped).
Will merge to 'next'.
* jk/pickaxe-textconv (2012-10-28) 2 commits
(merged to 'next' on 2012-11-26 at 2c5b5c9)
+ pickaxe: use textconv for -S counting
+ pickaxe: hoist empty needle check
Use textconv filters when searching with "log -S".
Will merge to 'master' in the seventh batch.
* fc/remote-bzr (2012-11-28) 10 commits
- (fixup) test-bzr.sh: fix multi-line string assignment
- remote-bzr: detect local repositories
- remote-bzr: add support for older versions of bzr
- remote-bzr: add support to push special modes
- remote-bzr: add support for fecthing special modes
- remote-bzr: add simple tests
- remote-bzr: update working tree
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- Add new remote-bzr transport helper
New remote helper for bzr (v3). With minor fixes this may be ready
for 'next'.
* fc/remote-hg (2012-11-27) 22 commits
(merged to 'next' on 2012-11-28 at f805784)
+ remote-hg: fix for older versions of python
+ remote-hg: fix for files with spaces
(merged to 'next' on 2012-11-18 at 4a4f2e4)
+ remote-hg: avoid bad refs
+ remote-hg: try the 'tip' if no checkout present
+ remote-hg: fix compatibility with older versions of hg
+ remote-hg: add missing config for basic tests
+ remote-hg: the author email can be null
+ remote-hg: add option to not track branches
+ remote-hg: add extra author test
+ remote-hg: add tests to compare with hg-git
+ remote-hg: add bidirectional tests
+ test-lib: avoid full path to store test results
+ remote-hg: add basic tests
+ remote-hg: fake bookmark when there's none
+ remote-hg: add compat for hg-git author fixes
+ remote-hg: add support for hg-git compat mode
+ remote-hg: match hg merge behavior
+ remote-hg: make sure the encoding is correct
+ remote-hg: add support to push URLs
+ remote-hg: add support for remote pushing
+ remote-hg: add support for pushing
+ Add new remote-hg transport helper
New remote helper for hg.
Will merge to 'master'.
* cr/push-force-tag-update (2012-11-26) 7 commits
- push: clarify rejection of update to non-commit-ish
- push: require force for annotated tags
- push: require force for refs under refs/tags/
- push: flag updates that require force
- push: keep track of "update" state separately
- push: add advice for rejected tag reference
- push: return reject reasons via a mask
Require "-f" for push to update a tag, even if it is a fast-forward.
With a minor tweak, I think this is getting ready for 'next'.
--------------------------------------------------
[Discarded]
* nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
. Unify appending signoff in format-patch, commit and sequencer
I am not sure if the logic to refrain from adding a sign-off based
on the existing run of sign-offs is done correctly in this change.
Brandon's series attempts the same thing and seemed to be more
cleanly done.
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
. pretty: support %>> that steal trailing spaces
. pretty: support truncating in %>, %< and %><
. pretty: support padding placeholders, %< %> and %><
. pretty: two phase conversion for non utf-8 commits
. utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
. utf8.c: move display_mode_esc_sequence_len() for use by other functions
. pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
. pretty: split parsing %C into a separate function
. pretty: share code between format_decoration and show_decorations
This causes warnings with -Wuninitialized, so I've ejected it from pu
for the time being.
^ permalink raw reply
* Re: [PATCH 6/5] t9001: check send-email behavior with implicit sender
From: Jeff King @ 2012-11-28 20:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <7vk3t5v9q1.fsf@alter.siamese.dyndns.org>
On Wed, Nov 28, 2012 at 10:55:02AM -0800, Junio C Hamano wrote:
> > +test_expect_success $PREREQ,AUTOIDENT 'implicit ident is allowed' '
> > + clean_fake_sendmail &&
> > + (sane_unset GIT_AUTHOR_NAME &&
> > + sane_unset GIT_AUTHOR_EMAIL &&
> > + sane_unset GIT_COMMITTER_NAME &&
> > + sane_unset GIT_COMMITTER_EMAIL &&
> > + GIT_SEND_EMAIL_NOTTY=1 git send-email \
> > + --smtp-server="$(pwd)/fake.sendmail" \
> > + --to=to@example.com \
> > + $patches \
> > + </dev/null 2>errors
> > + )
> > +'
> > +
> > +test_expect_success $PREREQ,!AUTOIDENT 'broken implicit ident aborts send-email' '
> > + clean_fake_sendmail &&
> > + (sane_unset GIT_AUTHOR_NAME &&
> > + sane_unset GIT_AUTHOR_EMAIL &&
> > + sane_unset GIT_COMMITTER_NAME &&
> > + sane_unset GIT_COMMITTER_EMAIL &&
> > + GIT_SEND_EMAIL_NOTTY=1 && export GIT_SEND_EMAIL_NOTTY &&
> > + test_must_fail git send-email \
> > + --smtp-server="$(pwd)/fake.sendmail" \
> > + $patches </dev/null 2>errors &&
> > + test_i18ngrep "tell me who you are" errors
> > + )
> > +'
>
> The difference between these two tests should solely come from
> AUTOIDENT and nothing else, so it would be better to see their
> command line arguments to match; the former is with --to and the
> latter is without in this patch but I do not think you meant them to
> differ that way.
Yeah, that makes sense. The top one originally was testing that we
still prompted in the autoident case, and so had some echos piped into
send-email. I simplified it to use --to, but I agree it is even better
to show that the commands are identical.
Here's a cleaned up version that makes it more obvious the commands are
the same (it also fixes a few minor whitespace problems on the
indentation, which you can see from the quoting above).
-- >8 --
Subject: [PATCH] t9001: check send-email behavior with implicit sender
We allow send-email to use an implicitly-defined identity
for the sender (because there is still a confirmation step),
but we abort when we cannot generate such an identity. Let's
make sure that we test this.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t9001-send-email.sh | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index c5d66cf..97d6f4c 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -201,6 +201,34 @@ test_expect_success $PREREQ 'Prompting works' '
grep "^To: to@example.com\$" msgtxt1
'
+test_expect_success $PREREQ,AUTOIDENT 'implicit ident is allowed' '
+ clean_fake_sendmail &&
+ (sane_unset GIT_AUTHOR_NAME &&
+ sane_unset GIT_AUTHOR_EMAIL &&
+ sane_unset GIT_COMMITTER_NAME &&
+ sane_unset GIT_COMMITTER_EMAIL &&
+ GIT_SEND_EMAIL_NOTTY=1 git send-email \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --to=to@example.com \
+ $patches </dev/null 2>errors
+ )
+'
+
+test_expect_success $PREREQ,!AUTOIDENT 'broken implicit ident aborts send-email' '
+ clean_fake_sendmail &&
+ (sane_unset GIT_AUTHOR_NAME &&
+ sane_unset GIT_AUTHOR_EMAIL &&
+ sane_unset GIT_COMMITTER_NAME &&
+ sane_unset GIT_COMMITTER_EMAIL &&
+ GIT_SEND_EMAIL_NOTTY=1 && export GIT_SEND_EMAIL_NOTTY &&
+ test_must_fail git send-email \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --to=to@example.com \
+ $patches </dev/null 2>errors &&
+ test_i18ngrep "tell me who you are" errors
+ )
+'
+
test_expect_success $PREREQ 'tocmd works' '
clean_fake_sendmail &&
cp $patches tocmd.patch &&
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: Junio C Hamano @ 2012-11-28 20:08 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann, Nahor
In-Reply-To: <20121128194216.GA22202@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
>> As the command takes other options whose names begin with 'r', I
>> thought the longer term plan was to stop letting "--rebase" squat on
>> short and sweet "-r" and leaving it undocumented (even though the
>> short one was added by mistake) was meant to be the first step in
>> that process.
>>
>> But maybe I am confusing an undocumented single-letter option from
>> some other subcommand. Anybody remembers?
>
> Perhaps you are remembering:
>
> On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote:
>> Ah, this reminds me of another thing I noticed when I saw that
>> ...
No. The discussion might or might not be the "-r" option to
"submodule update", but even if it were so, I wasn't refering to
that exchange but something more in the further past.
^ permalink raw reply
* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Simon Oosthoek @ 2012-11-28 20:08 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: git
In-Reply-To: <CAA01CspHAHN7se2oJ2WgcmpuRfoa+9Sx9sUvaPEmQ-Y+kDwHhA@mail.gmail.com>
On 28/11/12 19:02, Piotr Krukowiecki wrote:
> Is your setting?:
> PROMPT_COMMAND=__git_ps1
>
>
> That's right
>
>
> I believe you need to give 2 parameters in order to use it in
> PROMPT_COMMAND mode.
>
>
> Are you sure? git-prompt.sh says:
>
> # 3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
> # To customize the prompt, provide start/end arguments
> # PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'
>
> I interpret this as: if you don't want to customize the prompt, the
> simple "PROMPT_COMMAND=__git_ps1" is enough.
>
I'm sure, although you're right this documentation is wrong...
I guess it must have slipped by when the final changes were made to the
code. (The requirement to have 2 arguments for PROMPT_COMMAND mode were
one of the last changes before being accepted into the release process.)
I've been too busy with other stuff to take another look at this in the
meantime.
perhaps the point should read like this:
# 3a) In ~/.bashrc set PROMPT_COMMAND
# To customize the prompt, provide start/end arguments
# PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'
Which would not be confusing at all, I think...
>
>
> These last 2 lines say: if 2 arguments are given, use pcmode.
> Otherwise you get command-subtitution mode, which gives weird
> effects when being called from PROMPT_COMMAND.
>
>
> Still, it seems to work with above "patch"..
It only works in your specific case, since you're expecting the branch
info before the rest of your prompt. The output comes from the part of
the code that is meant for substitution mode ;-)
Cheers
Simon
^ permalink raw reply
* Re: [PATCH 6/5] t9001: check send-email behavior with implicit sender
From: Jeff King @ 2012-11-28 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <20121128200626.GA4292@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 03:06:26PM -0500, Jeff King wrote:
> Here's a cleaned up version that makes it more obvious the commands are
> the same (it also fixes a few minor whitespace problems on the
> indentation, which you can see from the quoting above).
I wondered how painful it would be to actually run the command and then
conditionally check the results inside the test. I ended up with this:
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index c5d66cf..9c8fac1 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -201,6 +201,30 @@ test_expect_success $PREREQ 'Prompting works' '
grep "^To: to@example.com\$" msgtxt1
'
+test_expect_success $PREREQ 'handle implicit ident' '
+ clean_fake_sendmail &&
+ (
+ sane_unset GIT_AUTHOR_NAME &&
+ sane_unset GIT_AUTHOR_EMAIL &&
+ sane_unset GIT_COMMITTER_NAME &&
+ sane_unset GIT_COMMITTER_EMAIL &&
+ GIT_SEND_EMAIL_NOTTY=1 && export GIT_SEND_EMAIL_NOTTY &&
+ {
+ git send-email \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --to=to@example.com \
+ $patches </dev/null 2>errors;
+ exit_code=$?
+ } &&
+ if test_have_prereq AUTOIDENT; then
+ test $exit_code = 0
+ else
+ test $exit_code != 0 &&
+ test_i18ngrep "tell me who you are" errors
+ fi
+ )
+'
+
test_expect_success $PREREQ 'tocmd works' '
clean_fake_sendmail &&
cp $patches tocmd.patch &&
which does work, though it is less nice that the protections and nice
syntax of "test_must_fail" must be abandoned (unless we want to do
something horrible like 'test_must_fail sh -c "exit $exit_code"'.
I could go either way.
-Peff
^ permalink raw reply related
* Re: git config key bug or by design?
From: Jeff King @ 2012-11-28 20:21 UTC (permalink / raw)
To: Peter van der Does; +Cc: git
In-Reply-To: <20121128071147.188a869e@Indy>
On Wed, Nov 28, 2012 at 07:11:47AM -0500, Peter van der Does wrote:
> I am writing a tool, it needs to store branch names in a separate config
> file.
>
> It's clear git doesn't respect those values, hence my question. I
> understand how to work around the problem, I would just prefix the key.
> I was just wondering if it was by design, which I guess it is as the
> parsing of the file will die if the key starts with a non-alpha
> character.
In that case, I would definitely say to use some prefix section like
"section.$branchname.key". That is how git stores per-branch information
(e.g., branch.master.merge), and it was always designed to let there be
arbitrary data in the "middle" section, whereas the section and key are
restricted and case-insensitive.
So no, I do not recall "cannot start with number" as a specific design
decision, but it is definitely a design decision that the section name
would not allow arbitrary content.
-Peff
^ permalink raw reply
* Re: [PATCH v6 07/16] remote-hg: add support for hg-git compat mode
From: W. Trevor King @ 2012-11-28 20:23 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier,
Johannes Schindelin, Ilari Liusvaara, Daniel Barkalow,
Michael J Gruber
In-Reply-To: <1351995218-19889-8-git-send-email-felipe.contreras@gmail.com>
I'm not sure if this is the most recent patch iteration for this
feature, but I just saw this typo in `pu`.
On Sun, Nov 04, 2012 at 03:13:29AM +0100, Felipe Contreras wrote:
> +# Commits are modified to preserve hg information and allow biridectionality.
^^^^^^^^
s/biridectionality/bidirectionality/
Cheers,
Trevor
--
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
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #09; Wed, 28)
From: Jeff King @ 2012-11-28 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v38ztv6z0.fsf@alter.siamese.dyndns.org>
On Wed, Nov 28, 2012 at 11:54:27AM -0800, Junio C Hamano wrote:
> * jk/fsck-dot-in-trees (2012-11-28) 1 commit
> - fsck: warn about '.' and '..' in trees
>
> Will merge to 'next'.
Do you have an opinion on warning about '.git', as well? It probably
would make more sense as a patch on top, but I thought I'd ask before
this got merged to next.
> * pf/editor-ignore-sigint (2012-11-11) 5 commits
> - launch_editor: propagate SIGINT from editor to git
> - run-command: do not warn about child death by SIGINT
> - run-command: drop silent_exec_failure arg from wait_or_whine
> - launch_editor: ignore SIGINT while the editor has control
> - launch_editor: refactor to use start/finish_command
>
> Avoid confusing cases where the user hits Ctrl-C while in the editor
> session, not realizing git will receive the signal. Since most editors
> will take over the terminal and will block SIGINT, this is not likely
> to confuse anyone.
>
> Some people raised issues with emacsclient, which are addressed by this
> re-roll. It should probably also handle SIGQUIT, and there were a
> handful of other review comments.
>
> Expecting a re-roll.
I'm slowly going through my post-travel/vacation/illness backlog. I hope
to re-roll this one today or tomorrow.
> * jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
> - config: exit on error accessing any config file
> - doc: advertise GIT_CONFIG_NOSYSTEM
> - config: treat user and xdg config permission problems as errors
> - config, gitignore: failure to access with ENOTDIR is ok
>
> An RFC to deal with a situation where .config/git is a file and we
> notice .config/git/config is not readable due to ENOTDIR, not
> ENOENT; I think a bit more refactored approach to consistently
> address permission errors across config, exclude and attrs is
> desirable. Don't we also need a check for an opposite situation
> where we open .config/git/config or .gitattributes for reading but
> they turn out to be directories?
I am not sure about the refactored approach you mention. We
fundamentally need to treat in-tree attributes and exclude files more
leniently, because we may find arbitrary paths in the tree. Whereas if
something in $GIT_DIR is inaccessible, it's probably a serious problem.
So I think we have to manually use access_or_{warn,die} from each
callsite.
As far as the opposite situation, I do not know if it is worth worrying
about. If $GIT_DIR/config or $HOME/.config/git/config is a directory,
that is an error and we should flag it[1]. In-tree is more hazy, but I
think complaining is still the right thing. You cannot expect to store
arbitrary crap at .gitattributes inside your tree. If you have crap in a
file at such a path, we would read it and complain when its syntax is
not that of a .gitattributes file. We should similarly complain when it
is a directory.
-Peff
[1] We might want to eventually allow "config directories" where we
would read all files in lexical order or something. So it is
tempting to think of ignoring such entries as a
forward-compatibility thing. But ignoring is the wrong thing; you
probably would not want an old version of git to _ignore_ your
config; it is better if it says "I am too old to understand your
config format".
^ permalink raw reply
* Re: [PATCH 6/5] t9001: check send-email behavior with implicit sender
From: Junio C Hamano @ 2012-11-28 20:42 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git
In-Reply-To: <20121128201713.GA9249@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 28, 2012 at 03:06:26PM -0500, Jeff King wrote:
>
>> Here's a cleaned up version that makes it more obvious the commands are
>> the same (it also fixes a few minor whitespace problems on the
>> indentation, which you can see from the quoting above).
>
> I wondered how painful it would be to actually run the command and then
> conditionally check the results inside the test. I ended up with this:
> ...
> which does work, though it is less nice that the protections and nice
> syntax of "test_must_fail" must be abandoned (unless we want to do
> something horrible like 'test_must_fail sh -c "exit $exit_code"'.
> I could go either way.
A change along that line did cross my mind, and I agree that it does
clarify that we are testing the same command produces an expected
result, the expectation may be different depending on external
conditions, and we can figure out what the expected values are
before running the test. I do not think we use such a pattern in
very many places, though.
The differences in "expected results" are generally not limited to
the final outcome in $? (e.g. your "else" side not just checks $?
indicates an error, but makes sure that we got an expected error
message), which means that the if statement at the end has to be
there in some form anyway, which in turn means that a new test
helper function to abstract this pattern out further would not
buy us very much (either it would be too complex and bug prone to
implement, or it would be too simplistic and limited).
I'd prefer to leave these as two separate tests for now like your
previous patch. People interested in consolidating/simplifying can
first audit the existing tests to find other instances of this
pattern to see if it is worth doing, and then come up with an
abstraction to be shared among them.
Thanks.
^ permalink raw reply
* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Junio C Hamano @ 2012-11-28 20:47 UTC (permalink / raw)
To: Simon Oosthoek; +Cc: Piotr Krukowiecki, git
In-Reply-To: <50B66F41.1030305@xs4all.nl>
Simon Oosthoek <s.oosthoek@xs4all.nl> writes:
> perhaps the point should read like this:
> # 3a) In ~/.bashrc set PROMPT_COMMAND
> # To customize the prompt, provide start/end arguments
> # PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'
>
> Which would not be confusing at all, I think...
It says "to customize", so a user who just wants the default (which
does not exist but the comment does not say so) would be left
without instruction, no?
In $HOME/.bashrc, PROMPT_COMMAND can be set to
'__git_ps1 <pre> <post>', where <pre> and <post>
are strings you would put in $PS1 before and after
the status string generated by git-prompt machinery.
e.g.
PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'
or something?
^ permalink raw reply
* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Simon Oosthoek @ 2012-11-28 20:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Piotr Krukowiecki, git
In-Reply-To: <7vlidltpyj.fsf@alter.siamese.dyndns.org>
On 28/11/12 21:47, Junio C Hamano wrote:
> Simon Oosthoek <s.oosthoek@xs4all.nl> writes:
>
>> perhaps the point should read like this:
>> # 3a) In ~/.bashrc set PROMPT_COMMAND
>> # To customize the prompt, provide start/end arguments
>> # PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'
>>
>> Which would not be confusing at all, I think...
>
> It says "to customize", so a user who just wants the default (which
> does not exist but the comment does not say so) would be left
> without instruction, no?
>
> In $HOME/.bashrc, PROMPT_COMMAND can be set to
> '__git_ps1 <pre> <post>', where <pre> and <post>
> are strings you would put in $PS1 before and after
> the status string generated by git-prompt machinery.
> e.g.
> PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'
>
> or something?
>
Looks better than my suggestion :-)
thanks
/Simon
^ permalink raw reply
* Re: git-svn: What is --follow-parent / --no-follow-parent for?
From: Eric Wong @ 2012-11-28 21:20 UTC (permalink / raw)
To: Sebastian Leske; +Cc: git
In-Reply-To: <20121120073153.GA340@localhost>
Sebastian Leske <Sebastian.Leske@sleske.name> wrote:
> However, this does not make sense to me: This sounds like there is no
> good reason *not* to enable this option. So why is it there? And in
> what situation might I want to use "--no-follow-parent"?
Speed. Following long/convoluted histories can take a long time.
Sometimes the user doesn't care about ancient history.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #09; Wed, 28)
From: Junio C Hamano @ 2012-11-28 21:25 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121128203826.GA9383@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 28, 2012 at 11:54:27AM -0800, Junio C Hamano wrote:
>
>> * jk/fsck-dot-in-trees (2012-11-28) 1 commit
>> - fsck: warn about '.' and '..' in trees
>>
>> Will merge to 'next'.
>
> Do you have an opinion on warning about '.git', as well? It probably
> would make more sense as a patch on top, but I thought I'd ask before
> this got merged to next.
Yeah, it would make sense to reject what we would not record
ourselves when the tools are used in a sane manner.
>> * pf/editor-ignore-sigint (2012-11-11) 5 commits
>> - launch_editor: propagate SIGINT from editor to git
>> - run-command: do not warn about child death by SIGINT
>> - run-command: drop silent_exec_failure arg from wait_or_whine
>> - launch_editor: ignore SIGINT while the editor has control
>> - launch_editor: refactor to use start/finish_command
>>
>> Avoid confusing cases where the user hits Ctrl-C while in the editor
>> session, not realizing git will receive the signal. Since most editors
>> will take over the terminal and will block SIGINT, this is not likely
>> to confuse anyone.
>>
>> Some people raised issues with emacsclient, which are addressed by this
>> re-roll. It should probably also handle SIGQUIT, and there were a
>> handful of other review comments.
>>
>> Expecting a re-roll.
>
> I'm slowly going through my post-travel/vacation/illness backlog. I hope
> to re-roll this one today or tomorrow.
Thanks.
>> * jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
>> - config: exit on error accessing any config file
>> - doc: advertise GIT_CONFIG_NOSYSTEM
>> - config: treat user and xdg config permission problems as errors
>> - config, gitignore: failure to access with ENOTDIR is ok
>>
>> An RFC to deal with a situation where .config/git is a file and we
>> notice .config/git/config is not readable due to ENOTDIR, not
>> ENOENT; I think a bit more refactored approach to consistently
>> address permission errors across config, exclude and attrs is
>> desirable. Don't we also need a check for an opposite situation
>> where we open .config/git/config or .gitattributes for reading but
>> they turn out to be directories?
>
> I am not sure about the refactored approach you mention. We
> fundamentally need to treat in-tree attributes and exclude files more
> leniently, because we may find arbitrary paths in the tree.
OK.
> As far as the opposite situation, I do not know if it is worth worrying
> about. If $GIT_DIR/config or $HOME/.config/git/config is a directory,
> that is an error and we should flag it[1]. In-tree is more hazy, but I
> think complaining is still the right thing. You cannot expect to store
> arbitrary crap at .gitattributes inside your tree. If you have crap in a
> file at such a path, we would read it and complain when its syntax is
> not that of a .gitattributes file. We should similarly complain when it
> is a directory.
Yeah, OK.
^ 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