* Re: [PATCH 8/8] wrap_in_html(): process message in bulk rather than line-by-line
From: Michael Haggerty @ 2012-12-02 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeremy White, Johannes Schindelin, Jeff King
In-Reply-To: <7vpq2slsb4.fsf@alter.siamese.dyndns.org>
On 12/02/2012 10:25 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> Nevertheless, the old code was even *more* broken because it added a
>> "</pre>" regardless of whether the separator line had been seen,...
>
> OK. I'll rewrite the tail-end of the original log message to read:
>
> The old code would have created invalid output when there was no
> body, emitting a closing </pre> without a blank line nor an opening
> <pre> after the header. The new code simply returns in this
> situation without doing harm (even though either would not make much
> sense in the context of imap-send that is meant to send out patches).
>
> and squash this in.
ACK. Thanks.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIG{INT,QUIT} when launching editor
From: Junio C Hamano @ 2012-12-02 10:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Paul Fox, Krzysztof Mazur
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Since this can be thought of as "act more like system(3)", I wondered
> whether the signal-ignore logic should be moved into run-command, or
> even used by default for blocking calls to run_command (which are
> basically our version of system(3)). But it is detrimental in the common
> case that the child is not taking control of the terminal, and is just
> an implementation detail (e.g., we call "git update-ref" behind the
> scenes, but the user does not know or care). If they hit ^C during such
> a run and we are ignoring SIGINT, then either:
>
> 1. we will notice the child died by signal and report an
> error in the subprocess rather than just dying; the end result is
> similar, but the error is unnecessarily confusing
>
> 2. we do not bother to check the child's return code (because we do
> not care whether the child succeeded or not, like a "gc --auto");
> we end up totally ignoring the user's request to abort the
> operation
>
> So I do not think we care about this behavior except for launching the
> editor. And the signal-propagation behavior of 5/5 is really so weirdly
> editor-specific (because it is about behaving well whether the child
> blocks signals or not).
Nicely explained. Very much appreciated.
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Junio C Hamano @ 2012-12-02 9:31 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <CAMK1S_iBq1ReGkjuy2UBENSQXOWyKj2ZzSCcg7Z89FVtVL2wMw@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> If I could assume that a successful 'git gc' means an fsck is not
> needed, I'd save a lot of time. Hence my question.
When it does "repack -a", it at least scans the whole history so you
would be sure that all the commits and trees are readable for the
purpose of enumerating the objects referred by them (and a bit flip
in them will likely be noticed by zlib inflation).
But a "gc" does not necessarily run "repack -a" when it does not see
too many pack files, so it can end up scanning only the surface of
the history to collect the recently created loose objects into a
pack, and stop its traversal without going into existing packfiles.
^ permalink raw reply
* Re: [PATCH 8/8] wrap_in_html(): process message in bulk rather than line-by-line
From: Junio C Hamano @ 2012-12-02 9:25 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Jeremy White, Johannes Schindelin, Jeff King
In-Reply-To: <50B8B73A.4060801@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Nevertheless, the old code was even *more* broken because it added a
> "</pre>" regardless of whether the separator line had been seen,...
OK. I'll rewrite the tail-end of the original log message to read:
The old code would have created invalid output when there was no
body, emitting a closing </pre> without a blank line nor an opening
<pre> after the header. The new code simply returns in this
situation without doing harm (even though either would not make much
sense in the context of imap-send that is meant to send out patches).
and squash this in.
Thanks.
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Sitaram Chamarty @ 2012-12-02 8:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Git Mailing List
In-Reply-To: <CAJo=hJvHeA4g1fJZXm9VxpdvMFoHeEJW_r5YtXTDACEp09Xm_Q@mail.gmail.com>
On Sun, Dec 2, 2012 at 9:58 AM, Shawn Pearce <spearce@spearce.org> wrote:
> On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> Background: I have a situation where I have to fix up a few hundred
>> repos in terms of 'git gc' (the auto gc seems to have failed in many
>> cases; they have far more than 6700 loose objects). I also found some
>> corrupted objects in some cases that prevent the gc from completing.
>>
>> I am running "git gc" followed by "git fsck". The majority of the
>> repos I have worked through so far appear to be fine, but in the
>> larger repos (upwards of 2-3 GB) the git fsck is taking almost 5 times
>> longer than the 'gc'.
>>
>> If I could assume that a successful 'git gc' means an fsck is not
>> needed, I'd save a lot of time. Hence my question.
>
> Not really. For example fsck verifies that every blob when
> decompressed and fully inflated matches its SHA-1. gc only checks
OK that makes sense. After I posted I happened to check using strace
and kinda guessed this from what I saw, but it's nice to have
confirmation.
> connectivity of the commit and tree graph by making sure every object
> was accounted for. But when creating the output pack it only verifies
> a CRC-32 was correct when copying the bits from the source to the
> destination, it does not verify that the data decompresses and matches
> the SHA-1 it should match.
>
> So it depends on what level of check you need to feel safe.
Yup; thanks.
All the repos my internal client manages are mirrored in multiple
places, and they set (or were at least told to set, heh!)
receive.fsckObjects so the lesser check is fine in most cases.
--
Sitaram
^ permalink raw reply
* Re: [PATCH v2 1/4] t4014: more tests about appending s-o-b lines
From: Brandon Casey @ 2012-12-02 8:03 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Nguyễn Thái Ngọc Duy, git, Junio C Hamano
In-Reply-To: <50BAFE04.4080100@web.de>
On Sat, Dec 1, 2012 at 11:06 PM, Torsten Bögershausen <tboegi@web.de> wrote:
> On 22.11.12 17:38, Nguyễn Thái Ngọc Duy wrote:
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>> t/t4014-format-patch.sh | 145 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 145 insertions(+)
>> + echo -n subject | append_signoff >actual &&
>
>
> "echo -n" is not portable, and we use printf everywhere.
> I found one "echo -n" in line 996.
>
> Can we squeeze that in, before going to next?
I got it. I'll squash it into the next series.
-Brandon
^ permalink raw reply
* Re: [PATCH v2 1/4] t4014: more tests about appending s-o-b lines
From: Torsten Bögershausen @ 2012-12-02 7:06 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1353602289-9418-2-git-send-email-pclouds@gmail.com>
On 22.11.12 17:38, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> t/t4014-format-patch.sh | 145 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 145 insertions(+)
> + echo -n subject | append_signoff >actual &&
"echo -n" is not portable, and we use printf everywhere.
I found one "echo -n" in line 996.
Can we squeeze that in, before going to next?
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 6cfad13..f460930 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -993,7 +993,7 @@ EOF
'
test_expect_success 'signoff: commit with only subject that does not end with NL' '
- echo -n subject | append_signoff >actual &&
+ printf subject | append_signoff >actual &&
cat >expected <<\EOF &&
4:Subject: [PATCH] subject
8:
^ permalink raw reply related
* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Michael Haggerty @ 2012-12-02 6:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeremy White, Johannes Schindelin, Jeff King
In-Reply-To: <7v624lns00.fsf@alter.siamese.dyndns.org>
On 12/02/2012 02:48 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> On 11/29/2012 10:30 PM, Junio C Hamano wrote:
>>
>>>> A side effect of this change is that the memory for each message is
>>>> freed after it is used rather than leaked, though that detail is
>>>> unimportant given that imap-send is a top-level command.
>>>>
>>>> --
>>>
>>> ?
>>
>> If by "?" you are wondering where the memory leak was, it was:
>
> No, I was wondering if you meant to say "---" to mark te remainder
> of what you wrote does not exactly belong to the log message.
Oh. Yes, that was my intention.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Shawn Pearce @ 2012-12-02 4:28 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <CAMK1S_iBq1ReGkjuy2UBENSQXOWyKj2ZzSCcg7Z89FVtVL2wMw@mail.gmail.com>
On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> Background: I have a situation where I have to fix up a few hundred
> repos in terms of 'git gc' (the auto gc seems to have failed in many
> cases; they have far more than 6700 loose objects). I also found some
> corrupted objects in some cases that prevent the gc from completing.
>
> I am running "git gc" followed by "git fsck". The majority of the
> repos I have worked through so far appear to be fine, but in the
> larger repos (upwards of 2-3 GB) the git fsck is taking almost 5 times
> longer than the 'gc'.
>
> If I could assume that a successful 'git gc' means an fsck is not
> needed, I'd save a lot of time. Hence my question.
Not really. For example fsck verifies that every blob when
decompressed and fully inflated matches its SHA-1. gc only checks
connectivity of the commit and tree graph by making sure every object
was accounted for. But when creating the output pack it only verifies
a CRC-32 was correct when copying the bits from the source to the
destination, it does not verify that the data decompresses and matches
the SHA-1 it should match.
So it depends on what level of check you need to feel safe.
^ permalink raw reply
* [PATCH v6 0/4] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-02 3:17 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: <20121130032719.GE29257@odin.tremily.us>
From: "W. Trevor King" <wking@tremily.us>
On Thu, Nov 29, 2012 at 10:27:19PM -0500, W. Trevor King wrote:
> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:
> > I've always felt that the "origin" defaults are broken and are simply
> > being ignored because most users do not trip over them. But ISTR that
> > submodule commands use the remote indicated by the superproject's
> > current remote-tracking configuration, with a fallback to 'origin' if
> > there is none. Sort of a "best effort" algorithm, I think. Am I
> > remembering that wrong?
>
> The current code uses a bare "git-fetch". I'm not sure what that
> defaults to if you're on a detached head. If it bothers you, I'm fine
> adding the submodule.<name>.remote option in v6.
Here it is. Now the remote defaults to $(get_default_remote) with an
optional override via submodule.<name>.remote.
Changes since v5:
* New patch 1 for easy config variable setup.
* Minor tweaks and rewordings in patches 2 and 3 (v5 patches 1 and 2).
* New patch 4 adding submodule.<name>.remote.
I'm fine with squashing patches 1, 2, and 4 together, if people prefer
a more compact series.
W. Trevor King (4):
submodule: add get_submodule_config helper funtion
submodule update: add --remote for submodule's upstream changes
submodule add: If --branch is given, record it in .gitmodules
submodule update: add submodule.<name>.remote config option
Documentation/config.txt | 8 ++++-
Documentation/git-submodule.txt | 27 ++++++++++++++-
Documentation/gitmodules.txt | 5 +++
git-submodule.sh | 74 ++++++++++++++++++++++++++++++++++++++---
t/t7400-submodule-basic.sh | 1 +
t/t7406-submodule-update.sh | 49 +++++++++++++++++++++++++++
6 files changed, 158 insertions(+), 6 deletions(-)
--
1.8.0.4.gf74b0fc.dirty
^ permalink raw reply
* [PATCH v6 1/4] submodule: add get_submodule_config helper funtion
From: W. Trevor King @ 2012-12-02 3:17 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.1354417618.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Several submodule configuration variables
(e.g. fetchRecurseSubmodules) are read from .gitmodules with local
overrides from the usual git config files. This shell function mimics
that logic to help initialize configuration variables in
git-submodule.sh.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
git-submodule.sh | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..97ce5e4 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -152,6 +152,33 @@ die_if_unmatched ()
}
#
+# Print a submodule configuration setting
+#
+# $1 = submodule name
+# $2 = option name
+# $3 = default value
+#
+# Checks in the usual git-config places first (for overrides),
+# otherwise it falls back on .gitmodules. This allows you to
+# distribute project-wide defaults in .gitmodules, while still
+# customizing individual repositories if necessary. If the option is
+# not in .gitmodules either, print a default value.
+#
+get_submodule_config()
+{
+ name="$1"
+ option="$2"
+ default="$3"
+ value=$(git config submodule."$name"."$option")
+ if test -z "$value"
+ then
+ value=$(git config -f .gitmodules submodule."$name"."$option")
+ fi
+ printf '%s' "${value:-$default}"
+}
+
+
+#
# Map submodule path to submodule name
#
# $1 = path
--
1.8.0.4.gf74b0fc.dirty
^ permalink raw reply related
* [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-02 3:17 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.1354417618.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 | 7 ++++++-
Documentation/git-submodule.txt | 25 ++++++++++++++++++++++++-
Documentation/gitmodules.txt | 5 +++++
git-submodule.sh | 22 +++++++++++++++++++++-
t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++
5 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 11f320b..6f4663c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1998,7 +1998,12 @@ submodule.<name>.update::
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>.branch::
+ The remote branch name for a submodule, used by `git submodule
+ update --remote`. Set this option to override the value found in
+ the `.gitmodules` file. See linkgit:git-submodule[1] and
+ linkgit:gitmodules[5] for details.
submodule.<name>.fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..72dd52f 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,29 @@ 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 used
+ is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
+ The remote branch used defaults to `master`, but the branch name may
+ be overridden 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 97ce5e4..104b5de 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=
@@ -536,6 +538,9 @@ cmd_update()
-i|--init)
init=1
;;
+ --remote)
+ remote=1
+ ;;
-N|--no-fetch)
nofetch=1
;;
@@ -596,6 +601,7 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
+ branch=$(get_submodule_config "$name" branch master)
if ! test -z "$update"
then
update_module=$update
@@ -630,6 +636,20 @@ 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
+ remote_name=$(get_default_remote)
+ sha1=$(clear_local_git_env; cd "$sm_path" &&
+ git rev-parse --verify "${remote_name}/${branch}") ||
+ die "$(eval_gettext "Unable to find current ${remote_name}/${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.4.gf74b0fc.dirty
^ permalink raw reply related
* [PATCH v6 4/4] submodule update: add submodule.<name>.remote config option
From: W. Trevor King @ 2012-12-02 3:17 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.1354417618.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Don't force the user to clone from the tracked repository
(branch.<name>.remote) or `origin`. By setting
submodule.<name>.remote in .gitmodules or the usual git config files,
you can easily point a submodule at a different remote when using
`submodule update --remote`.
The configured remote name is also used in `submodule sync` to
determine which remote.<name>.url is updated with the submodule's
origin URL.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/config.txt | 7 ++++---
Documentation/git-submodule.txt | 10 +++++-----
git-submodule.sh | 27 +++++++++++++++++++++------
t/t7406-submodule-update.sh | 18 ++++++++++++++++++
4 files changed, 48 insertions(+), 14 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6f4663c..c54b9b4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1999,10 +1999,11 @@ submodule.<name>.update::
by 'git submodule init'; edit them to override the
URL and other values found in the `.gitmodules` file. See
+submodule.<name>.remote::
submodule.<name>.branch::
- The remote branch name for a submodule, used by `git submodule
- update --remote`. Set this option to override the value found in
- the `.gitmodules` file. See linkgit:git-submodule[1] and
+ The remote repository and branch names for a submodule, used by `git
+ submodule update --remote`. Set these options to override the value
+ 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 988bba9..1d8d5f1 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -242,11 +242,11 @@ OPTIONS
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 used
- is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
- The remote branch used defaults to `master`, but the branch name may
- be overridden by setting the `submodule.<name>.branch` option in
- either `.gitmodules` or `.git/config` (with `.git/config` taking
- precedence).
+ is branch's remote (`branch.<name>.remote`, defaulting to `origin`),
+ and the remote branch used defaults to `master`, but either may be
+ overridden by setting the `submodule.<name>.remote` or
+ `submodule.<name>.branch` option in `.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.
diff --git a/git-submodule.sh b/git-submodule.sh
index 27b02fe..3e39e29 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -179,6 +179,21 @@ get_submodule_config()
printf '%s' "${value:-$default}"
}
+#
+# Print the name of a submodule's configured remote
+#
+# $1 = submodule name
+#
+get_submodule_remote()
+{
+ name="$1"
+ remote=$(get_submodule_config "$name" remote)
+ if test -z "$remote"
+ then
+ remote=$(get_default_remote)
+ fi
+ printf '%s' "${remote}"
+}
#
# Map submodule path to submodule name
@@ -605,6 +620,7 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
+ remote_name=$(get_submodule_remote "$name")
branch=$(get_submodule_config "$name" branch master)
if ! test -z "$update"
then
@@ -645,10 +661,9 @@ Maybe you want to use 'update --init'?")"
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'")"
+ (clear_local_git_env; cd "$sm_path" && git-fetch "$remote_name") ||
+ die "$(eval_gettext "Unable to fetch '\$remote_name' in submodule path '\$sm_path'")"
fi
- remote_name=$(get_default_remote)
sha1=$(clear_local_git_env; cd "$sm_path" &&
git rev-parse --verify "${remote_name}/${branch}") ||
die "$(eval_gettext "Unable to find current ${remote_name}/${branch} revision in submodule path '\$sm_path'")"
@@ -669,8 +684,8 @@ Maybe you want to use 'update --init'?")"
# is not reachable from a ref.
(clear_local_git_env; cd "$sm_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 '\$sm_path'")"
+ test -z "$rev") || git-fetch "$remote_name")) ||
+ die "$(eval_gettext "Unable to fetch '\$remote_name' in submodule path '\$sm_path'")"
fi
# Is this something we just cloned?
@@ -1110,7 +1125,7 @@ cmd_sync()
(
clear_local_git_env
cd "$sm_path"
- remote=$(get_default_remote)
+ remote=$(get_submodule_remote "$name")
git config remote."$remote".url "$sub_origin_url"
)
fi
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index a567834..86c85f8 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -149,6 +149,24 @@ test_expect_success 'submodule update --remote should fetch upstream changes' '
)
'
+test_expect_success 'local config should override .gitmodules remote' '
+ (cd submodule &&
+ echo line5-master >> file &&
+ git add file &&
+ test_tick &&
+ git commit -m "upstream line5-master"
+ ) &&
+ (cd super/submodule &&
+ git remote rename origin test-remote
+ ) &&
+ (cd super &&
+ git config submodule.submodule.remote test-remote &&
+ 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 &&
--
1.8.0.4.gf74b0fc.dirty
^ permalink raw reply related
* [PATCH v6 3/4] submodule add: If --branch is given, record it in .gitmodules
From: W. Trevor King @ 2012-12-02 3:17 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.1354417618.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 72dd52f..988bba9 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 104b5de..27b02fe 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -395,6 +395,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.4.gf74b0fc.dirty
^ permalink raw reply related
* does a successful 'git gc' imply 'git fsck'
From: Sitaram Chamarty @ 2012-12-02 2:31 UTC (permalink / raw)
To: Git Mailing List
Hi,
Background: I have a situation where I have to fix up a few hundred
repos in terms of 'git gc' (the auto gc seems to have failed in many
cases; they have far more than 6700 loose objects). I also found some
corrupted objects in some cases that prevent the gc from completing.
I am running "git gc" followed by "git fsck". The majority of the
repos I have worked through so far appear to be fine, but in the
larger repos (upwards of 2-3 GB) the git fsck is taking almost 5 times
longer than the 'gc'.
If I could assume that a successful 'git gc' means an fsck is not
needed, I'd save a lot of time. Hence my question.
--
Sitaram
^ permalink raw reply
* Re: [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
From: Junio C Hamano @ 2012-12-02 2:27 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jeff King, git
In-Reply-To: <vpqvccnctvd.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> That "shell-style" contradicts with what fast-import.c says, though.
>> It claims to grok \octal and described as C-style.
>
> As Peff mentionned, my last version is better, although still a bit
> incomplete. My new version documents things that _must_ be escaped, but
> not what _can_.
Yeah, I agree.
^ permalink raw reply
* Re: [PATCH] t4049: avoid test failures on filemode challenged file systems (Windows)
From: Junio C Hamano @ 2012-12-02 2:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Antoine Pelisse
In-Reply-To: <50B86438.3010806@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 11/29/2012 21:48, schrieb Junio C Hamano:
>> I've tested this with the testpen set on vfat mounted on my Linux
>> box, ...
>> and it seems to work OK,
>
> Works well here on Windows, too.
Thanks for checking.
^ permalink raw reply
* Re: [PATCH 0/5] "diff --stat" counting fixes
From: Junio C Hamano @ 2012-12-02 2:23 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <CALWbr2xYrWkfSCUc7gocVGLQP_RHjWrMmFspPe5O_ekjisNqxw@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> I feel like (but I can obviously be wrong):
> 1. The info is redundant. When performing a merge, all diffs (without
> --staged flag) are unmerged
Yes, it is redundant. They are primarily meant as a warning to
anybody who runs "git diff --stat" while their index is not fully
merged so that they do not mistakenly think they are looking at
meaningful numbers. The number of added lines likely includes the
conflict markers you haven't dealt with ;-)
> 2. While status shows the line once, while diff shows the diff for the file
> once, while diff --shortstat counts the file once, diff --stat shows two
> lines for the file.
Yeah, don't use shortstat while your index is unmerged.
> 3. diff --numstat shows two lines for the same file. As a script
> writer (I guess that's what it's meant for), I would definitely expect
> uniqueness in third column/filenames.
Then your script wouldn't receive any hint in the output that you
are reading from a nonsense input. When you see the same filename
twice, you will know there is something strange (not just "I seem to
have more added lines than I thought I added -- Ah, I see added
files from both sides because I still have conflicts unresolved")
that gives you a chance to notice.
^ permalink raw reply
* Re: [PATCH] gitk: add a checkbox to control the visibility of tags
From: Junio C Hamano @ 2012-12-02 2:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Łukasz Stelmach
In-Reply-To: <1354309737-4280-1-git-send-email-stlman@poczta.fm>
Łukasz Stelmach <stlman@poczta.fm> writes:
> Enable hiding of tags displayed in the tree as yellow labels.
> If a repository is used together with a system like Gerrit
> there may be quite a lot of tags used to control building
> and there may be hardly any place left for commit subjects.
>
> Signed-off-by: Łukasz Stelmach <stlman@poczta.fm>
> ---
Paul, this patch is not done against your tree (does not have gitk
at the top-level), but other than that, the change mimics the way
existing hideremoes is implemented and looks reasonable to me.
We _may_ want to unify these two "hidestuff" into a list of patterns
that hides any ref that match one of the patterns in the list, e.g.
set hidestuff {refs/heads/*/* refs/tags/* refs/remotes/*}
may hide all tags, all remote-tracking branches and local branches
that have a slash in their names.
But that is an independent change that can come later.
> gitk-git/gitk | 23 +++++++++++++++--------
> 1 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index d93bd99..274b46b 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -1754,7 +1754,7 @@ proc readrefs {} {
> global tagids idtags headids idheads tagobjid
> global otherrefids idotherrefs mainhead mainheadid
> global selecthead selectheadid
> - global hideremotes
> + global hideremotes hidetags
>
> foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
> catch {unset $v}
> @@ -1776,6 +1776,7 @@ proc readrefs {} {
> set headids($name) $id
> lappend idheads($id) $name
> } elseif {[string match "tags/*" $name]} {
> + if {$hidetags} continue
> # this lets refs/tags/foo^{} overwrite refs/tags/foo,
> # which is what we want since the former is the commit ID
> set name [string range $name 5 end]
> @@ -2702,7 +2703,7 @@ proc savestuff {w} {
> global cmitmode wrapcomment datetimeformat limitdiffs
> global colors uicolor bgcolor fgcolor diffcolors diffcontext selectbgcolor
> global autoselect autosellen extdifftool perfile_attrs markbgcolor use_ttk
> - global hideremotes want_ttk
> + global hideremotes hidetags want_ttk
>
> if {$stuffsaved} return
> if {![winfo viewable .]} return
> @@ -2725,6 +2726,7 @@ proc savestuff {w} {
> puts $f [list set autosellen $autosellen]
> puts $f [list set showneartags $showneartags]
> puts $f [list set hideremotes $hideremotes]
> + puts $f [list set hidetags $hidetags]
> puts $f [list set showlocalchanges $showlocalchanges]
> puts $f [list set datetimeformat $datetimeformat]
> puts $f [list set limitdiffs $limitdiffs]
> @@ -10864,7 +10866,7 @@ proc create_prefs_page {w} {
> proc prefspage_general {notebook} {
> global NS maxwidth maxgraphpct showneartags showlocalchanges
> global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
> - global hideremotes want_ttk have_ttk
> + global hideremotes hidetags want_ttk have_ttk
>
> set page [create_prefs_page $notebook.general]
>
> @@ -10887,6 +10889,9 @@ proc prefspage_general {notebook} {
> ${NS}::checkbutton $page.hideremotes -text [mc "Hide remote refs"] \
> -variable hideremotes
> grid x $page.hideremotes -sticky w
> + ${NS}::checkbutton $page.hidetags -text [mc "Hide tag labels"] \
> + -variable hidetags
> + grid x $page.hidetags -sticky w
>
> ${NS}::label $page.ddisp -text [mc "Diff display options"]
> grid $page.ddisp - -sticky w -pady 10
> @@ -10988,7 +10993,7 @@ proc doprefs {} {
> global oldprefs prefstop showneartags showlocalchanges
> global uicolor bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
> global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
> - global hideremotes want_ttk have_ttk
> + global hideremotes hidetags want_ttk have_ttk
>
> set top .gitkprefs
> set prefstop $top
> @@ -10997,7 +11002,7 @@ proc doprefs {} {
> return
> }
> foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
> - limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
> + limitdiffs tabstop perfile_attrs hideremotes hidetags want_ttk} {
> set oldprefs($v) [set $v]
> }
> ttk_toplevel $top
> @@ -11117,7 +11122,7 @@ proc prefscan {} {
> global oldprefs prefstop
>
> foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
> - limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
> + limitdiffs tabstop perfile_attrs hideremotes hidetags want_ttk} {
> global $v
> set $v $oldprefs($v)
> }
> @@ -11131,7 +11136,7 @@ proc prefsok {} {
> global oldprefs prefstop showneartags showlocalchanges
> global fontpref mainfont textfont uifont
> global limitdiffs treediffs perfile_attrs
> - global hideremotes
> + global hideremotes hidetags
>
> catch {destroy $prefstop}
> unset prefstop
> @@ -11177,7 +11182,8 @@ proc prefsok {} {
> $limitdiffs != $oldprefs(limitdiffs)} {
> reselectline
> }
> - if {$hideremotes != $oldprefs(hideremotes)} {
> + if {$hideremotes != $oldprefs(hideremotes) ||
> + $hidetags != $oldprefs(hidetags)} {
> rereadrefs
> }
> }
> @@ -11601,6 +11607,7 @@ set cmitmode "patch"
> set wrapcomment "none"
> set showneartags 1
> set hideremotes 0
> +set hidetags 0
> set maxrefs 20
> set maxlinelen 200
> set showlocalchanges 1
^ permalink raw reply
* Re: [PATCH v7 p2 1/2] fast-export: don't handle uninteresting refs
From: Junio C Hamano @ 2012-12-02 2:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Max Horn, git, Jeff King
In-Reply-To: <CAMP44s08Jfu08oeABHcy=xPtn=LZfKTdbaRZuDbf7g+RiP7xAA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Thu, Nov 29, 2012 at 2:16 AM, Max Horn <postbox@quendi.de> wrote:
>>
>> On 28.11.2012, at 23:23, Felipe Contreras wrote:
>>
>>> They have been marked as UNINTERESTING for a reason, lets respect that.
>>>
>>> Currently the first ref is handled properly, but not the rest:
>>>
>>> % git fast-export master ^uninteresting ^foo ^bar
>>
>> All these refs are assumed to point to the same object, right? I think it would be better if the commit message stated that explicitly. To make up for the lost space, you could then get rid of one of the four refs, I think three are sufficient to drive the message home ;-).
>
> Yeah, they point to the same object.
Do you want me to amend the log message of that commit to clarify
this?
>> <snip>
>>
> ...
> It's actually revs.cmdline, I typed the wrong one.
> ...
> So I think it's good.
Wait.
I at least read two points above you said what you wrote in the
commit was not corrrect and misleading to later readers. And then I
hear "it's good". Which one?
Are you merely saying that it is easily fixable to become good? If
so, what do you want to do with these not-so-good part?
If you want to ask me to amend, that is fine, but do so in a more
explicit way, not in a message at the tail of long thread that is
not even CC'ed to me.
Of course, a proper re-roll like everybody else does is just fine.
Thanks.
^ permalink raw reply
* Re: [PATCH] submodule: add 'deinit' command
From: Junio C Hamano @ 2012-12-02 2:00 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, W. Trevor King, Git, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BA3412.60309@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> With "git submodule init" the user is able to tell git he cares about one
> or more submodules and wants to have it populated on the next call to "git
> submodule update". But currently there is no easy way he could tell git he
> does not care about a submodule anymore and wants to get rid of his local
> work tree (except he knows a lot about submodule internals and removes the
> "submodule.$name.url" setting from .git/config himself).
>
> Help those users by providing a 'deinit' command. This removes the url
> setting from .git/config either for the given submodule(s) or for all
> those which have been initialized if none were given. Complain only when
> for a submodule given on the command line the url setting can't be found
> in .git/config.
>
> Add tests and link the man pages of "git submodule deinit" and "git rm" to
> assist the user in deciding whether removing or unregistering the submodule
> is the right thing to do for him.
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
I fully agree with your analysis on the reason why the "url" element
is special and has to be copied to $GIT_DIR/config, but when you
deinit (or uninit) a submodule to say you are no longer interested
in it and do not want it populated in the context of the
superproject, I am not sure if removing only submodule.$name.url (so
that when you later decide to "init" it again, you will keep the
values for submodule.$name.update and other things from the previous
life) is the sane thing to do, or it is better to remove
submodule.$name.* altogether as if an earlier "init" has never
happened. Would it be worth analyzing the pros-and-cons here?
> Am 01.12.2012 16:56, schrieb Jens Lehmann:
>> Am 01.12.2012 00:52, schrieb Phil Hord:
>>> If I never 'submodule init' a submodule, it does not get visited by
>>> 'git submodule foreach', among others. I think some people use this
>>> behavior explicitly.
>>>
>>> On the other hand, I've also notice that a submodule which I have
>>> removed does not get de-inited later one. It causes my 'git submodule
>>> foreach' to emit errors. :-(
>>
>> I'm currently hacking on "git submodule deinit" which removes the 'url'
>> setting from git/config. This should do the trick for you, right?
>
> And here we go ...
>
>
> Documentation/git-rm.txt | 4 ++++
> Documentation/git-submodule.txt | 11 +++++++++
> git-submodule.sh | 50 ++++++++++++++++++++++++++++++++++++++++-
> t/t7400-submodule-basic.sh | 11 +++++++++
> 4 files changed, 75 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
> index 262436b..ec42bf5 100644
> --- a/Documentation/git-rm.txt
> +++ b/Documentation/git-rm.txt
> @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.
> Ignored files are deemed expendable and won't stop a submodule's work
> tree from being removed.
>
> +If you only want to remove the local checkout of a submodule from your
> +work tree without committing that use `git submodule deinit` instead
> +(see linkgit:git-submodule[1]).
> +
> EXAMPLES
> --------
> `git rm Documentation/\*.txt`::
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index b1de3ba..fba77f6 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -13,6 +13,7 @@ SYNOPSIS
> [--reference <repository>] [--] <repository> [<path>]
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] init [--] [<path>...]
> +'git submodule' [--quiet] deinit [--] [<path>...]
> 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
> [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
> @@ -134,6 +135,16 @@ init::
> the explicit 'init' step if you do not intend to customize
> any submodule locations.
>
> +deinit::
> + Unregister the submodules, i.e. remove the `submodule.$name.url`
> + setting from .git/config. Further calls to `git submodule update`,
> + `git submodule foreach` and `git submodule sync` will skip any
> + unregistered submodules until they are initialized again, so use
> + this command if you don't want to have a local checkout of the
> + submodule in your work tree anymore. If you really want to remove
> + a submodule from the repository and commit that use
> + linkgit:git-rm[1] instead.
> +
> update::
> Update the registered submodules, i.e. clone missing submodules and
> checkout the commit specified in the index of the containing repository.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2365149..4059a2e 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -8,6 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
> USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
> or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
> or: $dashless [--quiet] init [--] [<path>...]
> + or: $dashless [--quiet] deinit [--] [<path>...]
> 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>
> @@ -516,6 +517,53 @@ cmd_init()
> }
>
> #
> +# Unregister submodules from .git/config
> +#
> +# $@ = requested paths (default to all)
> +#
> +cmd_deinit()
> +{
> + # parse $args after "submodule ... init".
> + while test $# -ne 0
> + do
> + case "$1" in
> + -q|--quiet)
> + GIT_QUIET=1
> + ;;
> + --)
> + shift
> + break
> + ;;
> + -*)
> + usage
> + ;;
> + *)
> + break
> + ;;
> + esac
> + shift
> + done
> +
> + module_list "$@" |
> + while read mode sha1 stage sm_path
> + do
> + die_if_unmatched "$mode"
> + name=$(module_name "$sm_path") || exit
> + url=$(git config submodule."$name".url)
> + if test -z "$url"
> + then
> + # Only mention uninitialized submodules when its
> + # path have been specified
> + test "$#" != "0" &&
> + say "$(eval_gettext "No url found for submodule path '\$sm_path' in .git/config")"
> + continue
> + fi
> + git config --unset submodule."$name".url &&
> + say "$(eval_gettext "Submodule '\$name' (\$url) unregistered")"
> + done
> +}
> +
> +#
> # Update each submodule path to correct revision, using clone and checkout as needed
> #
> # $@ = requested paths (default to all)
> @@ -1108,7 +1156,7 @@ cmd_sync()
> while test $# != 0 && test -z "$command"
> do
> case "$1" in
> - add | foreach | init | update | status | summary | sync)
> + add | foreach | init | deinit | update | status | summary | sync)
> command=$1
> ;;
> -q|--quiet)
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index de7d453..803bda7 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -756,4 +756,15 @@ test_expect_success 'submodule add with an existing name fails unless forced' '
> )
> '
>
> +test_expect_success 'submodule deinit should unregister submodule url from .git/config' '
> + url=$(git config submodule.example.url) &&
> + git submodule deinit &&
> + test -z "$(git config submodule.example.url)"
> +'
> +
> +test_expect_success 'submodule deinit complains only when explicitly used on an uninitialized submodule' '
> + git submodule deinit &&
> + test_must_fail git submodule deinit example
> +'
> +
> test_done
^ permalink raw reply
* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Junio C Hamano @ 2012-12-02 1:48 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Jeremy White, Johannes Schindelin, Jeff King
In-Reply-To: <50B8B66F.3090300@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 11/29/2012 10:30 PM, Junio C Hamano wrote:
>
>>> A side effect of this change is that the memory for each message is
>>> freed after it is used rather than leaked, though that detail is
>>> unimportant given that imap-send is a top-level command.
>>>
>>> --
>>
>> ?
>
> If by "?" you are wondering where the memory leak was, it was:
No, I was wondering if you meant to say "---" to mark te remainder
of what you wrote does not exactly belong to the log message.
>>> For some reason, there is a bunch of infrastructure in this file for
>>> dealing with IMAP flags, although there is nothing in the code that
>>> actually allows any flags to be set. If there is no plan to add
>>> support for flags in the future, a bunch of code could be ripped out
>>> and "struct msg_data" could be completely replaced with strbuf.
>>
>> Yeah, after all these years we have kept the unused flags field
>> there and nobody needed anything out of it. I am OK with a removal
>> if it is done at the very end of the series.
>
> I don't think the removal of flags needs to be part of the same series.
Oh, I did not think so, either.
> I suggest a separate patch series dedicated to deleting *all* the extra
> imap infrastructure at once. That being said, I'm not committing to do
> so. (We could add it to an "straightforward projects for aspiring git
> developers" list, if we had such a thing.)
A "low-hanging fruit and/or janitorial work" stack may be worth
having.
^ permalink raw reply
* Re: Inconsistency in messages about --set-upstream from git pull and git branch
From: Carlos Martín Nieto @ 2012-12-02 1:29 UTC (permalink / raw)
To: danr; +Cc: git
In-Reply-To: <CAN2DD_Hc4ZoQZefUirSZF=PZY5654yqrQfk5g1VzBLixEC=T-g@mail.gmail.com>
Dan Rosén <danr@student.chalmers.se> writes:
>
> git branch --set-upstream master origin/<branch>
>
This has been fixed already in 1.8.0.1
cmn
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-01 18:16 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BA4695.7030008@web.de>
[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]
On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote:
> Am 01.12.2012 18:49, schrieb W. Trevor King:
> > I think removing `init` will cause some compatibility issues anyway,
> > so I was re-imaging how you do it. I don't think update='none' and
> > "don't populate my submodule" are distinct ideas, while a locally
> > configured url="somwhere" and "please populate my submodule" are (with
> > the blank-url case defaulting to the superproject itself).
>
> Why would we want to remove "init"? It still has to copy the "url"
> setting (and it would be a compatibility nightmare if we would change
> that, imagine different git versions used on the same work tree).
In my init-less rewrite, it doesn't have to copy the url setting.
People using older versions of Git would need to run `init` using
their old version. Having the url defined in .git/config won't break
my init-less submodule commands, it just means that the value in
.gitmodules will be masked.
> >> What real world problems do we have with the current init/sync that
> >> this approach would solve?
> >
> > I don't have any, but in my `update --remote` series I'm adding two
> > new config options that are handled differently (define in
> > .gitmodules, override in superproject .git/config) than existing
> > submodules options.
>
> No, they're not. They are just handled differently than "url" and
> "update", but will behave just like "fetchRecurseSubmodules" and
> "ignore" do since day one. And as I explained in another mail I
> think "url" is special and "update" should be change to behave like
> the other two some day.
I somehow missed those earlier. Thanks for correcting my tunnel
vision. This makes me much happier about postponing the init-removal.
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: Jens Lehmann @ 2012-12-01 18:04 UTC (permalink / raw)
To: W. Trevor King
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121201174920.GE4823@odin.tremily.us>
Am 01.12.2012 18:49, schrieb W. Trevor King:
> I think removing `init` will cause some compatibility issues anyway,
> so I was re-imaging how you do it. I don't think update='none' and
> "don't populate my submodule" are distinct ideas, while a locally
> configured url="somwhere" and "please populate my submodule" are (with
> the blank-url case defaulting to the superproject itself).
Why would we want to remove "init"? It still has to copy the "url"
setting (and it would be a compatibility nightmare if we would change
that, imagine different git versions used on the same work tree).
>> What real world problems do we have with the current init/sync that
>> this approach would solve?
>
> I don't have any, but in my `update --remote` series I'm adding two
> new config options that are handled differently (define in
> .gitmodules, override in superproject .git/config) than existing
> submodules options.
No, they're not. They are just handled differently than "url" and
"update", but will behave just like "fetchRecurseSubmodules" and
"ignore" do since day one. And as I explained in another mail I
think "url" is special and "update" should be change to behave like
the other two some day.
^ 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