* [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 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 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 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
* 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
* 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: [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 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: 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 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: 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 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: [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 v6 2/8] push: add advice for rejected tag reference
From: Junio C Hamano @ 2012-12-02 10:42 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <1354239700-3325-3-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> static void advise_pull_before_push(void)
> {
> if (!advice_push_non_ff_current || !advice_push_nonfastforward)
> @@ -241,6 +245,11 @@ static void advise_checkout_pull_push(void)
> advise(_(message_advice_checkout_pull_push));
> }
>
> +static void advise_ref_already_exists(void)
> +{
> + advise(_(message_advice_ref_already_exists));
> +}
> +
> static int push_with_options(struct transport *transport, int flags)
> {
> int err;
> @@ -272,6 +281,8 @@ static int push_with_options(struct transport *transport, int flags)
> advise_use_upstream();
> else
> advise_checkout_pull_push();
> + } else if (reject_reasons & REJECT_ALREADY_EXISTS) {
> + advise_ref_already_exists();
> }
The existing advise_* functions that are called from this function
honor the advice.* configuration, and advise_ref_already_exists()
would want to follow suit here (it is OK to do so as a follow-up
patch without further rerolling the entire series).
Thanks.
^ permalink raw reply
* Re: [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
From: Junio C Hamano @ 2012-12-02 10:42 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, peff
In-Reply-To: <1352815447-8824-2-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> @@ -1538,13 +1563,7 @@ static sig_handler_t timer_fn = SIG_DFL;
> static unsigned __stdcall ticktack(void *dummy)
> {
> while (WaitForSingleObject(timer_event, timer_interval) == WAIT_TIMEOUT) {
> - if (timer_fn == SIG_DFL) {
> - if (isatty(STDERR_FILENO))
> - fputs("Alarm clock\n", stderr);
> - exit(128 + SIGALRM);
> - }
> - if (timer_fn != SIG_IGN)
> - timer_fn(SIGALRM);
> + mingw_raise(SIGALRM);
> if (one_shot)
> break;
> }
This hunk seems to have been based on a slightly newer codebase than
what I have, and I had to wiggle the patch a bit to make the series
apply. Please double check the result when I push out the 'pu'
branch.
Thanks.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* [PATCH] t9402: sed -i is not portable
From: Torsten Bögershausen @ 2012-12-02 12:22 UTC (permalink / raw)
To: git, mmogilvi_git; +Cc: tboegi
On some systems sed allows the usage of e.g.
sed -i -e "s/line1/line2/" afile
to edit the file "in place".
Other systems don't allow that: one observed behaviour is that
sed -i -e "s/line1/line2/" afile
creates a backup file called afile-e, which breaks the test.
As sed -i is not part of POSIX, avoid it.
Use test_cmp, makes the test easier to debug.
Chain all shell commands with && to detect all kinds of failure.
While at it, Use TAB to indent.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
Note: this should go on top of pu
t/t9402-git-cvsserver-refs.sh | 764 +++++++++++++++++++++---------------------
1 file changed, 383 insertions(+), 381 deletions(-)
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index 858ef0f..39c6b01 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -10,59 +10,58 @@ tags, branches and other git refspecs'
#########
check_start_tree() {
- rm -f "$WORKDIR/check.list"
- echo "start $1" >> "${WORKDIR}/check.log"
+ rm -f "$WORKDIR/check.list"
+ echo "start $1" >> "${WORKDIR}/check.log"
}
check_file() {
- sandbox="$1"
- file="$2"
- ver="$3"
- GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
+ sandbox="$1"
+ file="$2"
+ ver="$3"
+ GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
> "$WORKDIR/check.got" 2> "$WORKDIR/check.stderr"
- test_cmp "$WORKDIR/check.got" "$sandbox/$file"
- stat=$?
- echo "check_file $sandbox $file $ver : $stat" >> "$WORKDIR/check.log"
- echo "$file" >> "$WORKDIR/check.list"
- return $stat
+ test_cmp "$WORKDIR/check.got" "$sandbox/$file"
+ stat=$?
+ echo "check_file $sandbox $file $ver : $stat" >> "$WORKDIR/check.log"
+ echo "$file" >> "$WORKDIR/check.list"
+ return $stat
}
check_end_tree() {
- sandbox="$1"
- expectCount=$(wc -l < "$WORKDIR/check.list")
- cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
- test x"$cvsCount" = x"$expectCount"
- stat=$?
- echo "check_end $sandbox : $stat cvs=$cvsCount expect=$expectCount" \
- >> "$WORKDIR/check.log"
- return $stat
+ sandbox="$1" &&
+ wc -l < "$WORKDIR/check.list" > expected &&
+ find "$sandbox" -type f | grep -v "/CVS" > "$WORKDIR/check.cvsCount" &&
+ wc -l < "$WORKDIR/check.cvsCount" >actual &&
+ test_cmp expected actual &&
+ rm expected actual &&
+ sort < "$WORKDIR/check.list" > expected &&
+ sort < "$WORKDIR/check.cvsCount" | sed -e "s%cvswork/%%" >actual &&
+ test_cmp expected actual &&
+ rm expected actual
}
check_end_full_tree() {
- sandbox="$1"
- ver="$2"
- expectCount=$(wc -l < "$WORKDIR/check.list")
- cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
- gitCount=$(git ls-tree -r "$2" | wc -l)
- test x"$cvsCount" = x"$expectCount" -a x"$gitCount" = x"$expectCount"
- stat=$?
- echo "check_end $sandbox : $stat cvs=$cvsCount git=$gitCount expect=$expectCount" \
- >> "$WORKDIR/check.log"
- return $stat
+ sandbox="$1" &&
+ sort < "$WORKDIR/check.list" >expected &&
+ find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
+ test_cmp expected act1 &&
+ git ls-tree -r "$2" | sed -e "s/^.*blob [0-9a-fA-F]*[ ]*//" | sort > act2 &&
+ test_cmp expected act2 &&
+ rm expected act1 act2
}
#########
check_diff() {
- diffFile="$1"
- vOld="$2"
- vNew="$3"
- rm -rf diffSandbox
- git clone -q -n . diffSandbox &&
- ( cd diffSandbox &&
- git checkout "$vOld" &&
- git apply -p0 --index <"../$diffFile" &&
- git diff --exit-code "$vNew" ) > check_diff_apply.out 2>&1
+ diffFile="$1"
+ vOld="$2"
+ vNew="$3"
+ rm -rf diffSandbox
+ git clone -q -n . diffSandbox &&
+ ( cd diffSandbox &&
+ git checkout "$vOld" &&
+ git apply -p0 --index <"../$diffFile" &&
+ git diff --exit-code "$vNew" ) > check_diff_apply.out 2>&1
}
#########
@@ -70,17 +69,17 @@ check_diff() {
cvs >/dev/null 2>&1
if test $? -ne 1
then
- skip_all='skipping git-cvsserver tests, cvs not found'
- test_done
+ skip_all='skipping git-cvsserver tests, cvs not found'
+ test_done
fi
if ! test_have_prereq PERL
then
- skip_all='skipping git-cvsserver tests, perl not available'
- test_done
+ skip_all='skipping git-cvsserver tests, perl not available'
+ test_done
fi
"$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
- skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
- test_done
+ skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
+ test_done
}
unset GIT_DIR GIT_CONFIG
@@ -94,465 +93,468 @@ export CVSROOT CVS_SERVER
rm -rf "$CVSWORK" "$SERVERDIR"
test_expect_success 'setup v1, b1' '
- echo "Simple text file" > textfile.c &&
- echo "t2" > t2 &&
- mkdir adir &&
- echo "adir/afile line1" > adir/afile &&
- echo "adir/afile line2" >> adir/afile &&
- echo "adir/afile line3" >> adir/afile &&
- echo "adir/afile line4" >> adir/afile &&
- echo "adir/a2file" >> adir/a2file &&
- mkdir adir/bdir &&
- echo "adir/bdir/bfile line 1" > adir/bdir/bfile &&
- echo "adir/bdir/bfile line 2" >> adir/bdir/bfile &&
- echo "adir/bdir/b2file" > adir/bdir/b2file &&
- git add textfile.c t2 adir &&
- git commit -q -m "First Commit (v1)" &&
- git tag v1 &&
- git branch b1 &&
- git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
- GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
- GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
+ echo "Simple text file" > textfile.c &&
+ echo "t2" > t2 &&
+ mkdir adir &&
+ echo "adir/afile line1" > adir/afile &&
+ echo "adir/afile line2" >> adir/afile &&
+ echo "adir/afile line3" >> adir/afile &&
+ echo "adir/afile line4" >> adir/afile &&
+ echo "adir/a2file" >> adir/a2file &&
+ mkdir adir/bdir &&
+ echo "adir/bdir/bfile line 1" > adir/bdir/bfile &&
+ echo "adir/bdir/bfile line 2" >> adir/bdir/bfile &&
+ echo "adir/bdir/b2file" > adir/bdir/b2file &&
+ git add textfile.c t2 adir &&
+ git commit -q -m "First Commit (v1)" &&
+ git tag v1 &&
+ git branch b1 &&
+ git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
'
rm -rf cvswork
test_expect_success 'cvs co v1' '
- cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
rm -rf cvswork
test_expect_success 'cvs co b1' '
- cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs co b1 [cvswork3]' '
- cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
- check_start_tree cvswork3 &&
- check_file cvswork3 textfile.c v1 &&
- check_file cvswork3 t2 v1 &&
- check_file cvswork3 adir/afile v1 &&
- check_file cvswork3 adir/a2file v1 &&
- check_file cvswork3 adir/bdir/bfile v1 &&
- check_file cvswork3 adir/bdir/b2file v1 &&
- check_end_full_tree cvswork3 v1
+ cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
+ check_start_tree cvswork3 &&
+ check_file cvswork3 textfile.c v1 &&
+ check_file cvswork3 t2 v1 &&
+ check_file cvswork3 adir/afile v1 &&
+ check_file cvswork3 adir/a2file v1 &&
+ check_file cvswork3 adir/bdir/bfile v1 &&
+ check_file cvswork3 adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork3 v1
'
test_expect_success 'edit cvswork3 and save diff' '
- ( cd cvswork3 &&
- sed -i -e "s/line1/line1 - data/" adir/afile &&
- echo "afile5" > adir/afile5 &&
- rm t2 &&
- cvs -f add adir/afile5 &&
- cvs -f rm t2 &&
- test_must_fail cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
- )
+ ( cd cvswork3 &&
+ sed -e "s/line1/line1 - data/" adir/afile >adir/afileNEW &&
+ mv -f adir/afileNEW adir/afile &&
+ echo "afile5" > adir/afile5 &&
+ rm t2 &&
+ cvs -f add adir/afile5 &&
+ cvs -f rm t2 &&
+ test_must_fail cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
+ )
'
test_expect_success 'setup v1.2 on b1' '
- git checkout b1 &&
- echo "new v1.2" > t3 &&
- rm t2 &&
- sed -i -e "s/line3/line3 - more data/" adir/afile &&
- rm adir/a2file &&
- echo "a3file" >> adir/a3file &&
- echo "bfile line 3" >> adir/bdir/bfile &&
- rm adir/bdir/b2file &&
- echo "b3file" > adir/bdir/b3file &&
- mkdir cdir &&
- echo "cdir/cfile" > cdir/cfile &&
- git add -A cdir adir t3 t2 &&
- git commit -q -m 'v1.2' &&
- git tag v1.2 &&
- git push --tags gitcvs.git b1:b1
+ git checkout b1 &&
+ echo "new v1.2" > t3 &&
+ rm t2 &&
+ sed -e "s/line3/line3 - more data/" adir/afile >adir/afileNEW &&
+ mv -f adir/afileNEW adir/afile &&
+ rm adir/a2file &&
+ echo "a3file" >> adir/a3file &&
+ echo "bfile line 3" >> adir/bdir/bfile &&
+ rm adir/bdir/b2file &&
+ echo "b3file" > adir/bdir/b3file &&
+ mkdir cdir &&
+ echo "cdir/cfile" > cdir/cfile &&
+ git add -A cdir adir t3 t2 &&
+ git commit -q -m 'v1.2' &&
+ git tag v1.2 &&
+ git push --tags gitcvs.git b1:b1
'
test_expect_success 'cvs -f up (on b1 adir)' '
- ( cd cvswork/adir &&
- cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_end_tree cvswork
+ ( cd cvswork/adir &&
+ cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs up (on b1 /)' '
- ( cd cvswork &&
- cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_tree cvswork
'
# Make sure "CVS/Tag" files didn't get messed up:
test_expect_success 'cvs up (on b1 /) (again; check CVS/Tag files)' '
- ( cd cvswork &&
- cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_tree cvswork
'
# update to another version:
test_expect_success 'cvs up -r v1' '
- ( cd cvswork &&
- cvs -f up -r v1 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up -r v1 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs up' '
- ( cd cvswork &&
- cvs -f up ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs up (again; check CVS/Tag files)' '
- ( cd cvswork &&
- cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'setup simple b2' '
- git branch b2 v1 &&
- git push --tags gitcvs.git b2:b2
+ git branch b2 v1 &&
+ git push --tags gitcvs.git b2:b2
'
test_expect_success 'cvs co b2 [into cvswork2]' '
- cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'root dir edit [cvswork2]' '
- ( cd cvswork2 &&
- echo "Line 2" >> textfile.c &&
- test_must_fail cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
- cvs -f commit -m "edit textfile.c" textfile.c
- ) >cvsEdit1.log 2>&1
+ ( cd cvswork2 &&
+ echo "Line 2" >> textfile.c &&
+ test_must_fail cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
+ cvs -f commit -m "edit textfile.c" textfile.c
+ ) >cvsEdit1.log 2>&1
'
test_expect_success 'root dir rm file [cvswork2]' '
- ( cd cvswork2 &&
- cvs -f rm -f t2 &&
- cvs -f diff -u > ../cvsEdit2-empty.diff &&
- test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
- cvs -f commit -m "rm t2"
- ) > cvsEdit2.log 2>&1
+ ( cd cvswork2 &&
+ cvs -f rm -f t2 &&
+ cvs -f diff -u > ../cvsEdit2-empty.diff &&
+ test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
+ cvs -f commit -m "rm t2"
+ ) > cvsEdit2.log 2>&1
'
test_expect_success 'subdir edit/add/rm files [cvswork2' '
- ( cd cvswork2 &&
- sed -i -e "s/line 1/line 1 (v2)/" adir/bdir/bfile &&
- rm adir/bdir/b2file &&
- cd adir &&
- cvs -f rm bdir/b2file &&
- echo "4th file" > bdir/b4file &&
- cvs -f add bdir/b4file &&
- test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
- git fetch gitcvs.git b2:b2 &&
- ( cd .. &&
+ ( cd cvswork2 &&
+ sed -e "s/line 1/line 1 (v2)/" adir/bdir/bfile >adir/bdir/bfileNEW &&
+ mv -f adir/bdir/bfileNEW adir/bdir/bfile &&
+ rm adir/bdir/b2file &&
+ cd adir &&
+ cvs -f rm bdir/b2file &&
+ echo "4th file" > bdir/b4file &&
+ cvs -f add bdir/b4file &&
+ test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
+ git fetch gitcvs.git b2:b2 &&
+ ( cd .. &&
test_must_fail cvs -f diff -u -N -r v1.2 >"$WORKDIR/cvsEdit3-v1.2.diff" &&
test_must_fail cvs -f diff -u -N -r v1.2 -r v1 >"$WORKDIR/cvsEdit3-v1.2-v1.diff"
- ) &&
- cvs -f commit -m "various add/rm/edit"
- ) >cvs.log 2>&1
+ ) &&
+ cvs -f commit -m "various add/rm/edit"
+ ) >cvs.log 2>&1
'
test_expect_success 'validate result of edits [cvswork2]' '
- git fetch gitcvs.git b2:b2 &&
- git tag v2 b2 &&
- git push --tags gitcvs.git b2:b2 &&
- check_start_tree cvswork2 &&
- check_file cvswork2 textfile.c v2 &&
- check_file cvswork2 adir/afile v2 &&
- check_file cvswork2 adir/a2file v2 &&
- check_file cvswork2 adir/bdir/bfile v2 &&
- check_file cvswork2 adir/bdir/b4file v2 &&
- check_end_full_tree cvswork2 v2
+ git fetch gitcvs.git b2:b2 &&
+ git tag v2 b2 &&
+ git push --tags gitcvs.git b2:b2 &&
+ check_start_tree cvswork2 &&
+ check_file cvswork2 textfile.c v2 &&
+ check_file cvswork2 adir/afile v2 &&
+ check_file cvswork2 adir/a2file v2 &&
+ check_file cvswork2 adir/bdir/bfile v2 &&
+ check_file cvswork2 adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork2 v2
'
test_expect_success 'validate basic diffs saved during above cvswork2 edits' '
- test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
- test ! -s cvsEdit2-empty.diff &&
- test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
- test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
- rm -rf diffSandbox &&
- git clone -q -n . diffSandbox &&
- ( cd diffSandbox &&
- git checkout v1 &&
- git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
- git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
- git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
- git diff --exit-code v2 ) >"check_diff_apply.out" 2>&1
+ test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
+ test ! -s cvsEdit2-empty.diff &&
+ test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
+ test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
+ rm -rf diffSandbox &&
+ git clone -q -n . diffSandbox &&
+ ( cd diffSandbox &&
+ git checkout v1 &&
+ git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
+ git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
+ git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
+ git diff --exit-code v2 ) >"check_diff_apply.out" 2>&1
'
test_expect_success 'validate v1.2 diff saved during last cvswork2 edit' '
- test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
- check_diff cvsEdit3-v1.2.diff v1.2 v2
+ test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
+ check_diff cvsEdit3-v1.2.diff v1.2 v2
'
test_expect_success 'validate v1.2 v1 diff saved during last cvswork2 edit' '
- test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
- check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
+ test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
+ check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
'
test_expect_success 'cvs up [cvswork2]' '
- ( cd cvswork2 &&
- cvs -f up ) >cvs.log 2>&1 &&
- check_start_tree cvswork2 &&
- check_file cvswork2 textfile.c v2 &&
- check_file cvswork2 adir/afile v2 &&
- check_file cvswork2 adir/a2file v2 &&
- check_file cvswork2 adir/bdir/bfile v2 &&
- check_file cvswork2 adir/bdir/b4file v2 &&
- check_end_full_tree cvswork2 v2
+ ( cd cvswork2 &&
+ cvs -f up ) >cvs.log 2>&1 &&
+ check_start_tree cvswork2 &&
+ check_file cvswork2 textfile.c v2 &&
+ check_file cvswork2 adir/afile v2 &&
+ check_file cvswork2 adir/a2file v2 &&
+ check_file cvswork2 adir/bdir/bfile v2 &&
+ check_file cvswork2 adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork2 v2
'
test_expect_success 'cvs up -r b2 [back to cvswork]' '
- ( cd cvswork &&
- cvs -f up -r b2 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v2 &&
- check_file cvswork adir/afile v2 &&
- check_file cvswork adir/a2file v2 &&
- check_file cvswork adir/bdir/bfile v2 &&
- check_file cvswork adir/bdir/b4file v2 &&
- check_end_full_tree cvswork v2
+ ( cd cvswork &&
+ cvs -f up -r b2 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v2 &&
+ check_file cvswork adir/afile v2 &&
+ check_file cvswork adir/a2file v2 &&
+ check_file cvswork adir/bdir/bfile v2 &&
+ check_file cvswork adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork v2
'
test_expect_success 'cvs up -r b1' '
- ( cd cvswork &&
- cvs -f up -r b1 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_full_tree cvswork v1.2
+ ( cd cvswork &&
+ cvs -f up -r b1 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_full_tree cvswork v1.2
'
test_expect_success 'cvs up -A' '
- ( cd cvswork &&
- cvs -f up -A ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_full_tree cvswork v1
+ ( cd cvswork &&
+ cvs -f up -A ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork v1
'
test_expect_success 'cvs up (check CVS/Tag files)' '
- ( cd cvswork &&
- cvs -f up ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_full_tree cvswork v1
+ ( cd cvswork &&
+ cvs -f up ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork v1
'
# This is not really legal CVS, but it seems to work anyway:
test_expect_success 'cvs up -r heads/b1' '
- ( cd cvswork &&
- cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_full_tree cvswork v1.2
+ ( cd cvswork &&
+ cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_full_tree cvswork v1.2
'
# But this should work even if CVS client checks -r more carefully:
test_expect_success 'cvs up -r heads_-s-b2 (cvsserver escape mechanism)' '
- ( cd cvswork &&
- cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v2 &&
- check_file cvswork adir/afile v2 &&
- check_file cvswork adir/a2file v2 &&
- check_file cvswork adir/bdir/bfile v2 &&
- check_file cvswork adir/bdir/b4file v2 &&
- check_end_full_tree cvswork v2
+ ( cd cvswork &&
+ cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v2 &&
+ check_file cvswork adir/afile v2 &&
+ check_file cvswork adir/a2file v2 &&
+ check_file cvswork adir/bdir/bfile v2 &&
+ check_file cvswork adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork v2
'
v1hash=$(git rev-parse v1)
test_expect_success 'cvs up -r $(git rev-parse v1)' '
- test -n "$v1hash" &&
- ( cd cvswork &&
- cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_full_tree cvswork v1
+ test -n "$v1hash" &&
+ ( cd cvswork &&
+ cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork v1
'
test_expect_success 'cvs diff -r v1 -u' '
- ( cd cvswork &&
- cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
- test ! -s cvsDiff.out &&
- test ! -s cvs.log
+ ( cd cvswork &&
+ cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
+ test ! -s cvsDiff.out &&
+ test ! -s cvs.log
'
test_expect_success 'cvs diff -N -r v2 -u' '
- ( cd cvswork &&
- test_must_fail cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
- test ! -s cvs.log &&
- test -s cvsDiff.out &&
- check_diff cvsDiff.out v2 v1 > check_diff.out 2>&1
+ ( cd cvswork &&
+ test_must_fail cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
+ test ! -s cvs.log &&
+ test -s cvsDiff.out &&
+ check_diff cvsDiff.out v2 v1 > check_diff.out 2>&1
'
test_expect_success 'cvs diff -N -r v2 -r v1.2' '
- ( cd cvswork &&
- test_must_fail cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
- test ! -s cvs.log &&
- test -s cvsDiff.out &&
- check_diff cvsDiff.out v2 v1.2 > check_diff.out 2>&1
+ ( cd cvswork &&
+ test_must_fail cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
+ test ! -s cvs.log &&
+ test -s cvsDiff.out &&
+ check_diff cvsDiff.out v2 v1.2 > check_diff.out 2>&1
'
test_expect_success 'apply early [cvswork3] diff to b3' '
- git clone -q . gitwork3 &&
- ( cd gitwork3 &&
- git checkout -b b3 v1 &&
- git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
- git commit -m "cvswork3 edits applied" ) &&
- git fetch gitwork3 b3:b3 &&
- git tag v3 b3
+ git clone -q . gitwork3 &&
+ ( cd gitwork3 &&
+ git checkout -b b3 v1 &&
+ git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
+ git commit -m "cvswork3 edits applied" ) &&
+ git fetch gitwork3 b3:b3 &&
+ git tag v3 b3
'
test_expect_success 'check [cvswork3] diff' '
- ( cd cvswork3 &&
- test_must_fail cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
- test ! -s cvs.log &&
- test -s cvsDiff.out &&
- test $(grep Index: cvsDiff.out | wc -l) = 3 &&
- test_cmp cvsDiff.out cvswork3edit.diff &&
- check_diff cvsDiff.out v1 v3 > check_diff.out 2>&1
+ ( cd cvswork3 &&
+ test_must_fail cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
+ test ! -s cvs.log &&
+ test -s cvsDiff.out &&
+ test $(grep Index: cvsDiff.out | wc -l) = 3 &&
+ test_cmp cvsDiff.out cvswork3edit.diff &&
+ check_diff cvsDiff.out v1 v3 > check_diff.out 2>&1
'
test_expect_success 'merge early [cvswork3] b3 with b1' '
- ( cd gitwork3 &&
- git merge "message" HEAD b1 )
- git fetch gitwork3 b3:b3 &&
- git tag v3merged b3 &&
- git push --tags gitcvs.git b3:b3
+ ( cd gitwork3 &&
+ git merge "message" HEAD b1 )
+ git fetch gitwork3 b3:b3 &&
+ git tag v3merged b3 &&
+ git push --tags gitcvs.git b3:b3
'
# This test would fail if cvsserver properly created a ".#afile"* file
# for the merge.
# TODO: Validate that the .# file was saved properly, and then
-# delete/ignore it when checking the tree.
+# delete/ignore it when checking the tree.
test_expect_success 'cvs up dirty [cvswork3]' '
- ( cd cvswork3 &&
- cvs -f up &&
- test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsDiff.out" ) >cvs.log 2>&1 &&
- test -s cvsDiff.out &&
- test $(grep Index: cvsDiff.out | wc -l) = 2
- check_start_tree cvswork3 &&
- check_file cvswork3 textfile.c v3merged &&
- check_file cvswork3 t3 v3merged &&
- check_file cvswork3 adir/afile v3merged &&
- check_file cvswork3 adir/a3file v3merged &&
- check_file cvswork3 adir/afile5 v3merged &&
- check_file cvswork3 adir/bdir/bfile v3merged &&
- check_file cvswork3 adir/bdir/b3file v3merged &&
- check_file cvswork3 cdir/cfile v3merged &&
- check_end_full_tree cvswork3 v3merged
+ ( cd cvswork3 &&
+ cvs -f up &&
+ test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsDiff.out" ) >cvs.log 2>&1 &&
+ test -s cvsDiff.out &&
+ test $(grep Index: cvsDiff.out | wc -l) = 2
+ check_start_tree cvswork3 &&
+ check_file cvswork3 textfile.c v3merged &&
+ check_file cvswork3 t3 v3merged &&
+ check_file cvswork3 adir/afile v3merged &&
+ check_file cvswork3 adir/a3file v3merged &&
+ check_file cvswork3 adir/afile5 v3merged &&
+ check_file cvswork3 adir/bdir/bfile v3merged &&
+ check_file cvswork3 adir/bdir/b3file v3merged &&
+ check_file cvswork3 cdir/cfile v3merged &&
+ check_end_full_tree cvswork3 v3merged
'
# TODO: test cvs status
test_expect_success 'cvs commit [cvswork3' '
- ( cd cvswork3 &&
- cvs -f commit -m "dirty sandbox after auto-merge"
- ) > cvs.log 2>&1 &&
- check_start_tree cvswork3 &&
- check_file cvswork3 textfile.c v3merged &&
- check_file cvswork3 t3 v3merged &&
- check_file cvswork3 adir/afile v3merged &&
- check_file cvswork3 adir/a3file v3merged &&
- check_file cvswork3 adir/afile5 v3merged &&
- check_file cvswork3 adir/bdir/bfile v3merged &&
- check_file cvswork3 adir/bdir/b3file v3merged &&
- check_file cvswork3 cdir/cfile v3merged &&
- check_end_full_tree cvswork3 v3merged &&
- git fetch gitcvs.git b3:b4 &&
- git tag v4.1 b4 &&
- git diff --exit-code v4.1 v3merged > check_diff_apply.out 2>&1
+ ( cd cvswork3 &&
+ cvs -f commit -m "dirty sandbox after auto-merge"
+ ) > cvs.log 2>&1 &&
+ check_start_tree cvswork3 &&
+ check_file cvswork3 textfile.c v3merged &&
+ check_file cvswork3 t3 v3merged &&
+ check_file cvswork3 adir/afile v3merged &&
+ check_file cvswork3 adir/a3file v3merged &&
+ check_file cvswork3 adir/afile5 v3merged &&
+ check_file cvswork3 adir/bdir/bfile v3merged &&
+ check_file cvswork3 adir/bdir/b3file v3merged &&
+ check_file cvswork3 cdir/cfile v3merged &&
+ check_end_full_tree cvswork3 v3merged &&
+ git fetch gitcvs.git b3:b4 &&
+ git tag v4.1 b4 &&
+ git diff --exit-code v4.1 v3merged > check_diff_apply.out 2>&1
'
test_done
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [RFC] Add basic syntax check on shell scripts
From: Torsten Bögershausen @ 2012-12-02 13:17 UTC (permalink / raw)
To: git; +Cc: tboegi
The test suite needs to be run on different platforms.
As it may be difficult for contributors to catch syntax
which work on GNU/linux, but is unportable, make a quick check
for the most common problems.
"sed -i", "echo -n" or "array in shell scripts"
This list is not complete, and may need to be extended
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
We add 1 second test execution time
Is this a useful idea at all?
t/t99999-syntax-check.sh | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100755 t/t99999-syntax-check.sh
diff --git a/t/t99999-syntax-check.sh b/t/t99999-syntax-check.sh
new file mode 100755
index 0000000..c4a9289
--- /dev/null
+++ b/t/t99999-syntax-check.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+test_description='Basic check if shell syntax is portable'
+
+. ./test-lib.sh
+
+
+test_expect_success 'No arrays in shell scripts' '
+ >expected &&
+ (grep -i -n "^[ ]*declare[ ][ ]*" ../*.sh ../../git-* >actual 2>&1 || : ) &&
+ test_cmp expected actual &&
+ rm expected actual
+'
+
+test_expect_success 'No sed -i' '
+ >expected &&
+ (grep -n "^[ ]*sed[ ][ ]*\-i" ../*.sh ../../git-* >actual 2>&1 || : ) &&
+ test_cmp expected actual &&
+ rm expected actual
+'
+
+test_expect_success 'No echo -n' '
+ >expected &&
+ (grep -n "^[ ]*echo[ ][ ]*\-n" ../*.sh ../../git-* >actual 2>&1 || : ) &&
+ test_cmp expected actual &&
+ rm expected actual
+'
+test_done
--
1.8.0.197.g5a90748
^ permalink raw reply related
* Re: [RFC] Add basic syntax check on shell scripts
From: Stefano Lattarini @ 2012-12-02 14:30 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <201212021417.25525.tboegi@web.de>
On 12/02/2012 02:17 PM, Torsten Bögershausen wrote:
> The test suite needs to be run on different platforms.
> As it may be difficult for contributors to catch syntax
> which work on GNU/linux, but is unportable, make a quick check
> for the most common problems.
> "sed -i", "echo -n" or "array in shell scripts"
> This list is not complete, and may need to be extended
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> We add 1 second test execution time
> Is this a useful idea at all?
>
FWIW, I think such an idea is useful (and also easy to implement,
so another +1 from me).
> t/t99999-syntax-check.sh | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100755 t/t99999-syntax-check.sh
>
> diff --git a/t/t99999-syntax-check.sh b/t/t99999-syntax-check.sh
> new file mode 100755
> index 0000000..c4a9289
> --- /dev/null
> +++ b/t/t99999-syntax-check.sh
> @@ -0,0 +1,28 @@
> +#!/bin/sh
> +
> +test_description='Basic check if shell syntax is portable'
> +
> +. ./test-lib.sh
> +
> +
> +test_expect_success 'No arrays in shell scripts' '
> + >expected &&
> + (grep -i -n "^[ ]*declare[ ][ ]*" ../*.sh ../../git-* >actual 2>&1 || : ) &&
>
Here I'd simply use:
! grep -n "^declare[ ][ ]*" ../*.sh ../../*.sh
And similarly for the tests below.
In addition, the globs above still miss some files ('perf/perf-lib.sh'
and 'valgrind/analyze.sh', for example); so we might want to improve
it, using, say, "git ls-files" (or find(1), in case the test is to be
run also from distribution tarballs).
HTH,
Stefano
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-02 19:09 UTC (permalink / raw)
To: Jens Lehmann, Junio C Hamano
Cc: Phil Hord, Git, Heiko Voigt, Jeff King, Shawn Pearce, Nahor
In-Reply-To: <20121201181643.GF4823@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 5933 bytes --]
Before I get into the details, I'd like to point out that I actually
understand the purpose of `submodule init` now ;). To avoid further
confusion, my current one-line command summaries would be:
init: mark a submodule as active for future submodule operation
deinit: mark a submodule as inactive for future submodule operation
sync: update remote.<name>.origin in submodules to reflect changes
in .gitmodules or the superproject's remote URL.
I don't think we disagree on that, we just don't agree on how to
implement it.
Currently, Git uses submodule.<name>.url in the superproject's local
configuration as a marker for submodule activation. This is not (as
far as I know) discussed in the docs, which is why I initially
missunderstood the purpose of `init` to be “setup the superproject's
local configuration so we don't have to keep resolving the submodules
URL relative to the superproject's upstream URL”. With the proposed
`deinit` docs, this role for the submodule.<name>.url is mentioned,
but not in a place where casual users will be able to easily connect
it to the purpose of `init`.
I floated using submodule.<name>.update (with 'none' for inactive and
anything else for active) as an alternative marker:
On Sat, Dec 01, 2012 at 01:16:43PM -0500, W. Trevor King wrote:
> 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.
but that doesn't seem to be going over very well. Junio may have been
weighing in obliquely with:
On Sat, Dec 01, 2012 at 06:00:06PM -0800, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> > [snip v1 deinit commit message]
>
> 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?
Let me take another stab at presenting my argument in favor of a
different activity marker.
Proposal:
Add a new boolean option, submodule.<name>.active, to explicitly mark
submodules as active (with “active” defined as “to be returned by
module_list()”). Strip down `init` (and the --init part of `update
--init`) to just setting this option to true. `deinit` only sets this
option to false (but a `deinit --clean` could remove the whole
submodule.<name> section).
With this in place, extracting URLs for submodule operations be
similar to the extraction of other variables (.gitmodules defaults
with superproject-local .git/config overrides). This also makes it
easier to track maintenance updates in .gitmodules-defined URLs,
because you aren't forced to bake overrides into your local
.git/config
The upgrade path from earlier versions of Git is easy: if
submodule.<name>.active is unset, use the presence of
submodule.<name>.url to determine its initial value.
In the case where you check out an earlier superproject commit which
is missing a particular submodule (or remove a submodule without
deinit-ing), the presense of an active setting in .git/config should
not cause an error, which they currently seem to:
On Sat, Dec 01, 2012 at 11:37:14AM -0500, W. Trevor King wrote:
> On Sat, Dec 01, 2012 at 04:56:02PM +0100, Jens Lehmann wrote:
> > 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?
> >
> > Just removing that submodule automagically would not work that well, as
> > it would deinitialize a submodule when you switch to a branch where it
> > isn't present and you'd have to reinitialize it when you come back.
>
> I think this is another case where we should be looping through
> submodules based on the revision-specific .gitmodules content, and
> querying the local config only to determine if the user wants to
> update them (to drop into them with foreach, etc.).
Thoughts?
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: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes
From: Jens Lehmann @ 2012-12-02 19:32 UTC (permalink / raw)
To: W. Trevor King
Cc: Phil Hord, Git, Junio C Hamano, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121130032719.GE29257@odin.tremily.us>
Am 30.11.2012 04:27, schrieb W. Trevor King:
> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:
>> On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King <wking@tremily.us> wrote:
>>> On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote:
>>>> But I really don't want to figure out how to handle submodule
>>>> collisions during a merge (or rebase!) of my superproject with changes that
>>>> someone else auto-committed in his local $superproject as he and I
>>>> arbitrarily floated up the upstream independently. There is nothing but
>>>> loathing down that path.
>>>
>>> This is true. I'm not sure how gitlink collisions are currently
>>> handled…
>>
>> They've always been trouble for me. But it may be that I am ignorant.
>
> I haven't dealt with any gitlink merges, but I think that supporting
> easy gitlink merges is orthogonal to this --remote option. For simple
> cases like "autocommitted submodule floats", one of the conflicting
> gitlinks will be an ancestor of the other, so it should be easy to
> automate that merge.
Submodule merges where one submodule commit is the ancestor of the
other are already resolved automatically in recent git. So Phil's
example will just work as long as only fast-forward merges are needed.
^ permalink raw reply
* Re: [PATCH] submodule: add 'deinit' command
From: Jens Lehmann @ 2012-12-02 19:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Phil Hord, W. Trevor King, Git, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <7vy5hhmcwp.fsf@alter.siamese.dyndns.org>
Am 02.12.2012 03:00, schrieb Junio C Hamano:
> 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?
Sure. I was worried about throwing away other settings the user
might have set in the submodule.$name section and the first reflex
was to protect them. But thinking about that again I noticed we are
already throwing away a possibly user customized "url" setting, so
we already remove a possibly customized setting.
Maybe the principle of least surprise is better followed when we
nuke the whole section, as it might surprise the user more to have
a setting resurrected he customized in the last life cycle of the
submodule than seeing that after an deinit followed by an init all
former customizations are consistently gone. So I tend to think now
that removing the whole section would be the better solution here.
Opinions by other submodule users?
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: Jens Lehmann @ 2012-12-02 20:29 UTC (permalink / raw)
To: W. Trevor King
Cc: Junio C Hamano, Phil Hord, Git, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121202190929.GG9401@odin.tremily.us>
Am 02.12.2012 20:09, schrieb W. Trevor King:
> Before I get into the details, I'd like to point out that I actually
> understand the purpose of `submodule init` now ;). To avoid further
> confusion, my current one-line command summaries would be:
>
> init: mark a submodule as active for future submodule operation
> deinit: mark a submodule as inactive for future submodule operation
> sync: update remote.<name>.origin in submodules to reflect changes
> in .gitmodules or the superproject's remote URL.
>
> I don't think we disagree on that, we just don't agree on how to
> implement it.
Nope, it is already implemented and you are arguing to change the
current implementation. To quote from another mail:
Am 01.12.2012 18:49, schrieb W. Trevor King:
> On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:
>> What real world problems do we have with the current init/sync that
>> this approach would solve?
>
> I don't have any, ...
We don't want to change working code and cause compatibility issues
just because we /could/ do things differently, no?
^ permalink raw reply
* [PATCH] remote.c: fix grammatical error in comment
From: Chris Rorvick @ 2012-12-02 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Chris Rorvick
In-Reply-To: <1354239700-3325-9-git-send-email-chris@rorvick.com>
The sentence originally began "Note that ..." and was changed to
"NOTE: ..." This change should have been made at the same time.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
This applies to the current cr/push-force-tag-update branch. It can
probably just be folded into the last commit.
Thanks,
Chris
remote.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/remote.c b/remote.c
index 6309a87..aa6b719 100644
--- a/remote.c
+++ b/remote.c
@@ -1337,8 +1337,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
*
* NOTE: We must actually have the old object in
* order to overwrite it in the remote reference,
- * and that the new object must be commit-ish.
- * These are implied by (b) and (c) respectively.
+ * and the new object must be commit-ish. These are
+ * implied by (b) and (c) respectively.
*
* (4) it is forced using the +A:B notation, or by
* passing the --force argument
--
1.8.0.1.541.g73be2da
^ permalink raw reply related
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-02 21:11 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, Phil Hord, Git, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BBBA29.2000106@web.de>
From: "W. Trevor King" <wking@tremily.us>
To: Jens Lehmann <Jens.Lehmann@web.de>, Junio C Hamano <gitster@pobox.com>
Cc: Phil Hord <phil.hord@gmail.com>, Git <git@vger.kernel.org>,
Heiko Voigt <hvoigt@hvoigt.net>, Jeff King <peff@peff.net>,
Shawn Pearce <spearce@spearce.org>, Nahor <nahor.j+gmane@gmail.com>
Bcc:
Subject: Re: [RFC] remove/deprecate 'submodule init' and 'sync'
Reply-To:
In-Reply-To: <50BBBA29.2000106@web.de>
<50BBB22A.7050901@web.de>
<20121202190929.GG9401@odin.tremily.us>
OpenPGP: id=39A2F3FA2AB17E5D8764F388FC29BDCDF15F5BE8;
url=http://tremily.us/pubkey.txt
On Sun, Dec 02, 2012 at 09:29:29PM +0100, Jens Lehmann wrote:
> Am 02.12.2012 20:09, schrieb W. Trevor King:
> > Before I get into the details, I'd like to point out that I actually
> > understand the purpose of `submodule init` now ;). To avoid further
> > confusion, my current one-line command summaries would be:
> >
> > init: mark a submodule as active for future submodule operation
> > deinit: mark a submodule as inactive for future submodule operation
> > sync: update remote.<name>.origin in submodules to reflect changes
> > in .gitmodules or the superproject's remote URL.
> >
> > I don't think we disagree on that, we just don't agree on how to
> > implement it.
>
> Nope, it is already implemented and you are arguing to change the
> current implementation.
Agreed.
> To quote from another mail:
>
> Am 01.12.2012 18:49, schrieb W. Trevor King:
> > On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:
> >> What real world problems do we have with the current init/sync that
> >> this approach would solve?
> >
> > I don't have any, ...
>
> We don't want to change working code and cause compatibility issues
> just because we /could/ do things differently, no?
In principle, yes, but in this case I think changing the
implementation does not risk much in the way of compatibility issues
(it only hurts users who rely on `submodule init` setting
submodule.<name>.url for reasons of their own. A few of the existing
tests explictly check the url setting, so perhaps there are a number
of users who do require this side effect?
I think this risk is outweighed by the benefits of having a clearer
activation option. For example:
On Sun, Dec 02, 2012 at 08:55:22PM +0100, Jens Lehmann wrote:
> Sure. I was worried about throwing away other settings the user
> might have set in the submodule.$name section and the first reflex
> was to protect them. But thinking about that again I noticed we are
> already throwing away a possibly user customized "url" setting, so
> we already remove a possibly customized setting.
With submodule.<name>.active, there's nothing customized that you'd
have to nuke on deinit (except 'active' iteself, which the user is
explicitly asking for).
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: [PATCH] gitk: add a checkbox to control the visibility of tags
From: Lukasz Stelmach @ 2012-12-02 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vlidhmc5i.fsf@alter.siamese.dyndns.org>
W dniu 02.12.2012 03:16, Junio C Hamano pisze:
> Ł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),
I did it on the master from github. Should I rebase it onto something else?
> 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.
This would make much more sense with gitk being abel to read a
per-repository configuration file, say from [file join $gitdir k] and
then save it there (but only if the file exists). I will send a separate
patch in a moment.
>> 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
>
--
Było mi bardzo miło. Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska. (c)PP
^ 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