* [PATCH 0/2] git-p4: remove test bash-isms
From: Pete Wyckoff @ 2012-02-26 15:37 UTC (permalink / raw)
To: git; +Cc: Vitor Antunes
Two fixes to make the t98* tests run in dash.
Pete Wyckoff (2):
git-p4: remove bash-ism in t9809
git-p4: remove bash-ism in t9800
t/t9800-git-p4-basic.sh | 25 ++++++++++++++++---------
t/t9809-git-p4-client-view.sh | 2 +-
2 files changed, 17 insertions(+), 10 deletions(-)
--
1.7.9.2.288.g74b75
^ permalink raw reply
* [PATCH 1/2] git-p4: remove bash-ism in t9809
From: Pete Wyckoff @ 2012-02-26 15:37 UTC (permalink / raw)
To: git; +Cc: Vitor Antunes
In-Reply-To: <1330270647-8817-1-git-send-email-pw@padd.com>
Plain old $# works to count the number of arguments in
either bash or dash, even if the arguments have spaces.
Based-on-patch-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9809-git-p4-client-view.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9809-git-p4-client-view.sh b/t/t9809-git-p4-client-view.sh
index ae9145e..18d93e4 100755
--- a/t/t9809-git-p4-client-view.sh
+++ b/t/t9809-git-p4-client-view.sh
@@ -31,7 +31,7 @@ client_view() {
#
check_files_exist() {
ok=0 &&
- num=${#@} &&
+ num=$# &&
for arg ; do
test_path_is_file "$arg" &&
ok=$(($ok + 1))
--
1.7.9.2.288.g74b75
^ permalink raw reply related
* [PATCH 2/2] git-p4: remove bash-ism in t9800
From: Pete Wyckoff @ 2012-02-26 15:37 UTC (permalink / raw)
To: git; +Cc: Vitor Antunes
In-Reply-To: <1330270647-8817-1-git-send-email-pw@padd.com>
This works in both bash and dash:
arf$ bash -c 'VAR=1 env' | grep VAR
VAR=1
arf$ dash -c 'VAR=1 env' | grep VAR
VAR=1
But the variables are not propagated through a function
in dash:
arf$ bash -c 'f() { "$@"
}; VAR=1 f "env"' | grep VAR
VAR=1
arf$ dash -c 'f() { "$@"
}; VAR=1 f "env"' | grep VAR
Fix constructs like this, in particular, setting variables
through test_must_fail.
Based-on-patch-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9800-git-p4-basic.sh | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 04ee20e..9f17cdb 100755
--- a/t/t9800-git-p4-basic.sh
+++ b/t/t9800-git-p4-basic.sh
@@ -234,8 +234,11 @@ test_expect_success 'refuse to preserve users without perms' '
git config git-p4.skipSubmitEditCheck true &&
echo "username-noperms: a change by alice" >>file1 &&
git commit --author "Alice <alice@localhost>" -m "perms: a change by alice" file1 &&
- P4EDITOR=touch P4USER=bob P4PASSWD=secret test_must_fail "$GITP4" commit --preserve-user &&
- test_must_fail git diff --exit-code HEAD..p4/master
+ # dashism: test_must_fail does not propagate variables
+ P4EDITOR=touch P4USER=bob P4PASSWD=secret &&
+ export P4EDITOR P4USER P4PASSWD &&
+ test_must_fail "$GITP4" commit --preserve-user &&
+ ! git diff --exit-code HEAD..p4/master
)
'
@@ -250,13 +253,15 @@ test_expect_success 'preserve user where author is unknown to p4' '
git commit --author "Bob <bob@localhost>" -m "preserve: a change by bob" file1 &&
echo "username-unknown: a change by charlie" >>file1 &&
git commit --author "Charlie <charlie@localhost>" -m "preserve: a change by charlie" file1 &&
- P4EDITOR=touch P4USER=alice P4PASSWD=secret test_must_fail "$GITP4" commit --preserve-user &&
- test_must_fail git diff --exit-code HEAD..p4/master &&
+ P4EDITOR=touch P4USER=alice P4PASSWD=secret &&
+ export P4EDITOR P4USER P4PASSWD &&
+ test_must_fail "$GITP4" commit --preserve-user &&
+ ! git diff --exit-code HEAD..p4/master &&
echo "$0: repeat with allowMissingP4Users enabled" &&
git config git-p4.allowMissingP4Users true &&
git config git-p4.preserveUser true &&
- P4EDITOR=touch P4USER=alice P4PASSWD=secret "$GITP4" commit &&
+ "$GITP4" commit &&
git diff --exit-code HEAD..p4/master &&
p4_check_commit_author file1 alice
)
@@ -275,20 +280,22 @@ test_expect_success 'not preserving user with mixed authorship' '
p4_add_user derek Derek &&
make_change_by_user usernamefile3 Derek derek@localhost &&
- P4EDITOR=cat P4USER=alice P4PASSWD=secret "$GITP4" commit |\
+ P4EDITOR=cat P4USER=alice P4PASSWD=secret &&
+ export P4EDITOR P4USER P4PASSWD &&
+ "$GITP4" commit |\
grep "git author derek@localhost does not match" &&
make_change_by_user usernamefile3 Charlie charlie@localhost &&
- P4EDITOR=cat P4USER=alice P4PASSWD=secret "$GITP4" commit |\
+ "$GITP4" commit |\
grep "git author charlie@localhost does not match" &&
make_change_by_user usernamefile3 alice alice@localhost &&
- P4EDITOR=cat P4USER=alice P4PASSWD=secret "$GITP4" |\
+ "$GITP4" commit |\
test_must_fail grep "git author.*does not match" &&
git config git-p4.skipUserNameCheck true &&
make_change_by_user usernamefile3 Charlie charlie@localhost &&
- P4EDITOR=cat P4USER=alice P4PASSWD=secret "$GITP4" commit |\
+ "$GITP4" commit |\
test_must_fail grep "git author.*does not match" &&
p4_check_commit_author usernamefile3 alice
--
1.7.9.2.288.g74b75
^ permalink raw reply related
* [gitolite] denying access by factors other than ref/path names
From: Sitaram Chamarty @ 2012-02-26 15:50 UTC (permalink / raw)
To: gitolite, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
Gitolite now allows you to deny access using data other than ref
names or path names.
For example, you can deny a push if:
* it adds more then N new files (or variations, like changed
files, binary files, new binary files...)
* it contains autogenerated files that can't be caught by
gitignore
* it fails a "no non-merge first-parents" rule
* you don't like the phase of the moon :)
Since the actual decision is done by a script you write, you can
enforce pretty much any site-specific stupi^Wstandards, (like
ensuring that junior developers push only their own commits).
http://sitaramc.github.com/gitolite/vref.html has all the gory
details for anyone interested, and contrib/VREF in the latest pu
branch has example code.
--
Sitaram
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] submodules: Use relative paths to gitdir and work tree
From: Johannes Sixt @ 2012-02-26 17:38 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, Git Mailing List, Antony Male, Phil Hord, msysGit
In-Reply-To: <4F32F252.7050105@web.de>
Am 08.02.2012 23:08, schrieb Jens Lehmann:
> This patch series replaces all absolute paths pointing from submodule work
> trees to its gitdir and back with relative paths as discussed in $gmane/187785.
>
> The motivation is to make superprojects movable again. They lost this ability
> with the move of the git directory of submodules into the .git/modules directory
> of the superproject. While fixing that a bug which would hit when moving the
> submodule inside the superproject was also fixed.
>
> Jens Lehmann (2):
> submodules: always use a relative path to gitdir
> submodules: always use a relative path from gitdir to work tree
This series, with the tip at e3307adaba in Junio's repo causes major
headaches on Windows.
First, a check for an absolute path must be extended to take
Windows-style paths into account.
Second, the a's and b's are filled with different forms of absolute
paths (/c/there vs. c:/there), and as a consequence the subsequent loops
do not find a suitable relative path.
The below is a minimal hack that passes all t/*submod* tests, but it
works only on Windows, where the pwd utility has an option -W that
prints a Windows style absolute path.
How would you have this solved? One option would be to introduce a function
pwd() { builtin pwd -W "$@"; }
in git-sh-setup conditionally on Windows (but that would affect other
shell scripts, too).
Any other ideas?
diff --git a/git-submodule.sh b/git-submodule.sh
index 3463d6d..f37745e 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -139,8 +139,8 @@ module_clone()
gitdir="$gitdir/modules/$path"
case $gitdir in
- /*)
- a="$(cd_to_toplevel && pwd)/"
+ /* | [a-z]:/*)
+ a="$(cd_to_toplevel && pwd -W)/"
b=$gitdir
while [ "$b" ] && [ "${a%%/*}" = "${b%%/*}" ]
do
@@ -170,8 +170,8 @@ module_clone()
echo "gitdir: $rel_gitdir" >"$path/.git"
- a=$(cd "$gitdir" && pwd)
- b=$(cd "$path" && pwd)
+ a=$(cd "$gitdir" && pwd -W)
+ b=$(cd "$path" && pwd -W)
while [ "$b" ] && [ "${a%%/*}" = "${b%%/*}" ]
do
a=${a#*/} b=${b#*/};
--
1.7.8.216.g2e426
^ permalink raw reply related
* Re: [PATCH 2/2] git-p4: remove bash-ism in t9800
From: Johannes Sixt @ 2012-02-26 17:48 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Vitor Antunes
In-Reply-To: <1330270647-8817-3-git-send-email-pw@padd.com>
Am 26.02.2012 16:37, schrieb Pete Wyckoff:
> - P4EDITOR=touch P4USER=bob P4PASSWD=secret test_must_fail "$GITP4" commit --preserve-user &&
> - test_must_fail git diff --exit-code HEAD..p4/master
> + # dashism: test_must_fail does not propagate variables
> + P4EDITOR=touch P4USER=bob P4PASSWD=secret &&
> + export P4EDITOR P4USER P4PASSWD &&
> + test_must_fail "$GITP4" commit --preserve-user &&
> + ! git diff --exit-code HEAD..p4/master
It is a bashism that variables assigned in front of a shell function are
exported. But it is not a dashism that they are not exported; that
(surprising?) behavior is actually conforming to POSIX.
With the new code, be aware that the variables remain exported, which
might affect subsequent tests in general, though not this one, because
the assignments are in a sub-shell:
> )
> '
-- Hannes
^ permalink raw reply
* Re: [PATCH] Makefile: add thread-utils.h to LIB_H
From: Thomas Rast @ 2012-02-26 18:13 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: git, gitster
In-Reply-To: <20120224234242.GA3124@altlinux.org>
"Dmitry V. Levin" <ldv@altlinux.org> writes:
> Starting with commit v1.7.8-165-g0579f91, grep.h includes
> thread-utils.h, so the latter has to be added to LIB_H.
Oops, my bad.
Acked-by: Thomas Rast <trast@student.ethz.ch>
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 2/2] git-p4: remove bash-ism in t9800
From: Pete Wyckoff @ 2012-02-26 18:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Vitor Antunes
In-Reply-To: <4F4A7057.2020309@kdbg.org>
j6t@kdbg.org wrote on Sun, 26 Feb 2012 18:48 +0100:
> Am 26.02.2012 16:37, schrieb Pete Wyckoff:
> > - P4EDITOR=touch P4USER=bob P4PASSWD=secret test_must_fail "$GITP4" commit --preserve-user &&
> > - test_must_fail git diff --exit-code HEAD..p4/master
> > + # dashism: test_must_fail does not propagate variables
> > + P4EDITOR=touch P4USER=bob P4PASSWD=secret &&
> > + export P4EDITOR P4USER P4PASSWD &&
> > + test_must_fail "$GITP4" commit --preserve-user &&
> > + ! git diff --exit-code HEAD..p4/master
>
> It is a bashism that variables assigned in front of a shell function are
> exported. But it is not a dashism that they are not exported; that
> (surprising?) behavior is actually conforming to POSIX.
>
> With the new code, be aware that the variables remain exported, which
> might affect subsequent tests in general, though not this one, because
> the assignments are in a sub-shell:
>
> > )
> > '
Interesting, thanks. I thought about the subshell behavior and
use, on purpose, the fact that the variables stay exported in the
second and third hunks.
-- Pete
^ permalink raw reply
* Stash during incomplete merge
From: Phil Hord @ 2012-02-26 18:36 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Phil Hord
Hi list,
I was cherry-picking changes from an old branch recently when I ran into
unexpected behavior with git stash pop. When I git-stash-save after
resolving a merge-conflict, the subsequent git-stash-pop does not
restore my index.
I think it is the same problem being asked about here:
http://stackoverflow.com/questions/9009354/git-stash-during-a-merge-conflict
Is this expected behavior or a bug?
<http://stackoverflow.com/questions/9009354/git-stash-during-a-merge-conflict>Here's
a script the demonstrates the anomaly, but my actual encounter involved
more files, some of which I added to the index and some I did not:
# Create a sample merge-conflict
git init tmp-repo && cd tmp-repo
echo foo > foo.txt && git add foo.txt && git commit -m "foo"
git checkout -b A master && echo foo-A > foo.txt && git commit -am "foo-A"
git checkout -b B master && echo foo-B > foo.txt && git commit -am "foo-B"
git merge A
git status
# Resolve the conflict
echo foo-AB > foo.txt && git add foo.txt
git status
git stash
# test test test... Resume...
git stash pop
Here's some of the final output:
$ git merge A
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt
Recorded preimage for 'foo.txt'
Automatic merge failed; fix conflicts and then commit the result.
$ git status
# On branch B
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: foo.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ # Resolve the conflict
$ echo foo-AB > foo.txt && git add foo.txt
$ git status
# On branch B
# Changes to be committed:
#
# modified: foo.txt
#
$ # Now foo.txt is in my index. But I have to test something before I
commit.
$ git stash
Saved working directory and index state WIP on B: 80f2a13 foo-B
HEAD is now at 80f2a13 foo-B
$ # test test test... Resume...
$ git stash pop
# On branch B
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: foo.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (460a6d5c67a3db613fd27f1854ecc7b89eeaa207)
^ permalink raw reply
* Re: [PATCH 0/2] submodules: Use relative paths to gitdir and work tree
From: Jens Lehmann @ 2012-02-26 19:58 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Git Mailing List, Antony Male, Phil Hord, msysGit
In-Reply-To: <4F4A6DFA.5080709@kdbg.org>
Am 26.02.2012 18:38, schrieb Johannes Sixt:
> Am 08.02.2012 23:08, schrieb Jens Lehmann:
>> This patch series replaces all absolute paths pointing from submodule work
>> trees to its gitdir and back with relative paths as discussed in $gmane/187785.
>>
>> The motivation is to make superprojects movable again. They lost this ability
>> with the move of the git directory of submodules into the .git/modules directory
>> of the superproject. While fixing that a bug which would hit when moving the
>> submodule inside the superproject was also fixed.
>>
>> Jens Lehmann (2):
>> submodules: always use a relative path to gitdir
>> submodules: always use a relative path from gitdir to work tree
>
> This series, with the tip at e3307adaba in Junio's repo causes major
> headaches on Windows.
>
> First, a check for an absolute path must be extended to take
> Windows-style paths into account.
Okay, but that check is not part of my series (it was introduced by 501770e1
"Move git-dir for submodules", which is in Git since 1.7.8), so that looks
like it would need to be fixed for msysgit even without my patches, right?
But I'm not so happy about the two code paths there anyway, so I prepared a
patch to replace them with a single code path based upon the paths computed
in the last patch of this series. Please see the always-use-relative-gitdir
branch in my github repo https://github.com/jlehmann/git-submod-enhancements
> Second, the a's and b's are filled with different forms of absolute
> paths (/c/there vs. c:/there), and as a consequence the subsequent loops
> do not find a suitable relative path.
>
> The below is a minimal hack that passes all t/*submod* tests, but it
> works only on Windows, where the pwd utility has an option -W that
> prints a Windows style absolute path.
>
> How would you have this solved? One option would be to introduce a function
>
> pwd() { builtin pwd -W "$@"; }
>
> in git-sh-setup conditionally on Windows (but that would affect other
> shell scripts, too).
I suspect other shell scripts might be less affected when non-Windows
paths are forced (at least when they aren't developed under Windows
only). What about something like this:
pwd() { builtin pwd -W "$@" | sed -e 's,^\([a-z]\):/,/\1/,'; }
> Any other ideas?
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3463d6d..f37745e 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -139,8 +139,8 @@ module_clone()
> gitdir="$gitdir/modules/$path"
>
> case $gitdir in
> - /*)
> - a="$(cd_to_toplevel && pwd)/"
> + /* | [a-z]:/*)
> + a="$(cd_to_toplevel && pwd -W)/"
> b=$gitdir
> while [ "$b" ] && [ "${a%%/*}" = "${b%%/*}" ]
> do
Hmm, here the path which starts with "c:/" is returned by the "git
rev-parse --git-dir" which is used to initialize the $gitdir variable
a few lines up.
> @@ -170,8 +170,8 @@ module_clone()
>
> echo "gitdir: $rel_gitdir" >"$path/.git"
>
> - a=$(cd "$gitdir" && pwd)
> - b=$(cd "$path" && pwd)
> + a=$(cd "$gitdir" && pwd -W)
> + b=$(cd "$path" && pwd -W)
> while [ "$b" ] && [ "${a%%/*}" = "${b%%/*}" ]
> do
> a=${a#*/} b=${b#*/};
I don't understand why you need this. Does "pwd" sometimes return a
path starting with "c:/" and sometimes "/c/" depending on what form
you use when you cd into that directory? If not, does the following
help you on windows? (If that is the case, you might need the pwd
redefinition too to make that work)
-----------------8<--------------------
diff --git a/git-submodule.sh b/git-submodule.sh
index 5deabf6..5bb8109 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -134,7 +134,7 @@ module_clone()
test -n "$name" || name="$path"
base_path=$(dirname "$path")
- gitdir=$(git rev-parse --git-dir)
+ gitdir=$(git rev-parse --git-dir | sed -e 's,^\([a-z]\):/,/\1/,')
gitdir_base="$gitdir/modules/$base_path"
gitdir="$gitdir/modules/$path"
^ permalink raw reply related
* [PATCH] fsck: do not print dangling objects by default
From: Clemens Buchacher @ 2012-02-26 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Every reference to git fsck that I could find in the documentation or on
the web is followed by the some kind of assurance that dangling objects
are "not a problem", "nothing to worry about" or "not at all
interesting".
Instead of telling the user everywhere to ignore those messages, let's
not print them in the first place. The --dangling flag can be used to
explicitly enable printing dangling objects.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Documentation/git-fsck.txt | 3 +++
Documentation/git-repack.txt | 2 +-
Documentation/user-manual.txt | 20 ++------------------
builtin/fsck.c | 7 +++++--
t/t1410-reflog.sh | 2 +-
t/t1450-fsck.sh | 6 +-----
t/t6050-replace.sh | 2 +-
7 files changed, 14 insertions(+), 28 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 6c47395..199c5a0 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -30,6 +30,9 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
Print out objects that exist but that aren't reachable from any
of the reference nodes.
+--dangling::
+ Print objects that exist but that are never 'directly' used.
+
--root::
Report root nodes.
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 40af321..4c1aff6 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -34,7 +34,7 @@ OPTIONS
Especially useful when packing a repository that is used
for private development. Use
with '-d'. This will clean up the objects that `git prune`
- leaves behind, but `git fsck --full` shows as
+ leaves behind, but `git fsck --full --dangling` shows as
dangling.
+
Note that users fetching over dumb protocols will have to fetch the
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f13a846..09ffbcc 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1582,25 +1582,12 @@ Checking the repository for corruption
The linkgit:git-fsck[1] command runs a number of self-consistency checks
on the repository, and reports on any problems. This may take some
-time. The most common warning by far is about "dangling" objects:
+time.
-------------------------------------------------
$ git fsck
-dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
-dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
-dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
-dangling blob 218761f9d90712d37a9c5e36f406f92202db07eb
-dangling commit bf093535a34a4d35731aa2bd90fe6b176302f14f
-dangling commit 8e4bec7f2ddaa268bef999853c25755452100f8e
-dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085
-dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
-...
-------------------------------------------------
-Dangling objects are not a problem. At worst they may take up a little
-extra disk space. They can sometimes provide a last-resort method for
-recovering lost work--see <<dangling-objects>> for details.
-
[[recovering-lost-changes]]
Recovering lost changes
~~~~~~~~~~~~~~~~~~~~~~~
@@ -1665,7 +1652,7 @@ commits in the dangling objects that `git fsck` reports. See
<<dangling-objects>> for the details.
-------------------------------------------------
-$ git fsck
+$ git fsck --dangling
dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
@@ -3301,9 +3288,6 @@ broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
missing blob 4b9458b3786228369c63936db65827de3cc06200
------------------------------------------------
-(Typically there will be some "dangling object" messages too, but they
-aren't interesting.)
-
Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
points to it. If you could find just one copy of that missing blob
object, possibly in some other repository, you could move it into
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 8c479a7..0745535 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -29,6 +29,7 @@ static int errors_found;
static int write_lost_and_found;
static int verbose;
static int show_progress = -1;
+static int show_dangling;
#define ERROR_OBJECT 01
#define ERROR_REACHABLE 02
#define ERROR_PACK 04
@@ -221,8 +222,9 @@ static void check_unreachable_object(struct object *obj)
* start looking at, for example.
*/
if (!obj->used) {
- printf("dangling %s %s\n", typename(obj->type),
- sha1_to_hex(obj->sha1));
+ if (show_dangling)
+ printf("dangling %s %s\n", typename(obj->type),
+ sha1_to_hex(obj->sha1));
if (write_lost_and_found) {
char *filename = git_path("lost-found/%s/%s",
obj->type == OBJ_COMMIT ? "commit" : "other",
@@ -614,6 +616,7 @@ static char const * const fsck_usage[] = {
static struct option fsck_opts[] = {
OPT__VERBOSE(&verbose, "be verbose"),
OPT_BOOLEAN(0, "unreachable", &show_unreachable, "show unreachable objects"),
+ OPT_BOOLEAN(0, "dangling", &show_dangling, "show dangling objects"),
OPT_BOOLEAN(0, "tags", &show_tags, "report tags"),
OPT_BOOLEAN(0, "root", &show_root, "report root nodes"),
OPT_BOOLEAN(0, "cache", &keep_cache_objects, "make index objects head nodes"),
diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
index 252fc82..12441c5 100755
--- a/t/t1410-reflog.sh
+++ b/t/t1410-reflog.sh
@@ -20,7 +20,7 @@ check_have () {
}
check_fsck () {
- output=$(git fsck --full)
+ output=$(git fsck --full --dangling)
case "$1" in
'')
test -z "$output" ;;
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 523ce9c..78bfbc3 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -27,12 +27,8 @@ test_expect_success 'loose objects borrowed from alternate are not missing' '
git init &&
echo ../../../.git/objects >.git/objects/info/alternates &&
test_commit C fileC one &&
- git fsck >../out 2>&1
+ git fsck >../actual 2>&1
) &&
- {
- grep -v dangling out >actual ||
- :
- } &&
test_cmp empty actual
'
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c87f28..5b36ee3 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -95,7 +95,7 @@ test_expect_success 'tag replaced commit' '
'
test_expect_success '"git fsck" works' '
- git fsck master > fsck_master.out &&
+ git fsck --dangling master > fsck_master.out &&
grep "dangling commit $R" fsck_master.out &&
grep "dangling tag $(cat .git/refs/tags/mytag)" fsck_master.out &&
test -z "$(git fsck)"
--
1.7.9.1
^ permalink raw reply related
* Re: sha-1 check in rev-list --verify-objects redundant?
From: Junio C Hamano @ 2012-02-26 21:37 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <CACsJy8BUeedTZSq_ay=JmqUt3wrnm6n1eOcFt0WPkEo2B-1zwA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On the well-formedness, unless I'm mistaken, --verify-objects is
> _always_ used in conjunction with index-pack.
Hmm, you are making my head hurt. Is the above "always" a typo of
"never"?
The static check_everything_connected() function in builtin/fetch.c is a
direct callsite of "rev-list --verify-objects", and the function is used
in two codepaths:
* store_updated_refs() that is used after we receive and store objects
from the other end. We may or may not have run index-pack in this
codepath; in either case we need to make sure the other side did send
everything that is needed to complete the history between what we used
to have and what they claimed to supply us, to protect us from a broken
remote side.
* quickfetch() that is called even before we get any object from the
other end, to optimize the transfer when we already have what we need.
The latter is the original use to protect against unconnected island of
chain I explained in the previous message, but the former is also abot the
same protection, in a different callchain.
In both cases, the check by --verify-objects is about completeness of the
history (is everything connected to the tips of refs we have?), and is
different from integrity of individual objects (is each individual object
well formed and hash correctly?). Both kinds of sanity need to be
checked, as they are orthogonal concepts.
In order to check the history completeness, we need to read the objects
that we walk during the check. I wouldn't be surprised if the codepath to
do this is written overly defensive, taking a belt-and-suspender approach,
and check the well-formedness of an object before it reads it to find out
the other objects pointed by it.
If we _know_ that we have checked the integrity of all the necessary
individual objects before we start reading them in order to check the
completeness of the history, there is an opportunity to optimize by
teaching --verify-objects paths to optionally be looser than it currently
is, to avoid checking the object integrity twice.
^ permalink raw reply
* Re: [PATCH] fsck: do not print dangling objects by default
From: Junio C Hamano @ 2012-02-26 21:57 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20120226204357.GA26088@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Every reference to git fsck that I could find in the documentation or on
> the web is followed by the some kind of assurance that dangling objects
> are "not a problem", "nothing to worry about" or "not at all
> interesting".
>
> Instead of telling the user everywhere to ignore those messages, let's
> not print them in the first place. The --dangling flag can be used to
> explicitly enable printing dangling objects.
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Thanks.
I think that both the ultimate goal explained above, and the direction in
which the documentation updates tries to move us, are good. I only gave a
cursory look at the code changes, but what they implement seems to match
the intention.
Of course I may be missing something, so objections from others to argue
why we shouldn't do this is very much welcomed to stop me and Clemens ;-).
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index f13a846..09ffbcc 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1582,25 +1582,12 @@ Checking the repository for corruption
>
> The linkgit:git-fsck[1] command runs a number of self-consistency checks
> on the repository, and reports on any problems. This may take some
> +time.
> ...
> -Dangling objects are not a problem. At worst they may take up a little
> -extra disk space. They can sometimes provide a last-resort method for
> -recovering lost work--see <<dangling-objects>> for details.
Losing this description is not a problem and is indeed an improvement in
this section in the user manual, but let's make a mental note that the
user needs to also learn what the third sentence says elsewhere in this
document.
<< reads on >>
> @@ -1665,7 +1652,7 @@ commits in the dangling objects that `git fsck` reports. See
> <<dangling-objects>> for the details.
>
> -------------------------------------------------
> -$ git fsck
> +$ git fsck --dangling
> dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
> dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
> dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
> @@ -3301,9 +3288,6 @@ broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
> missing blob 4b9458b3786228369c63936db65827de3cc06200
> ------------------------------------------------
>
> -(Typically there will be some "dangling object" messages too, but they
> -aren't interesting.)
> -
The old sentence becomes stale as the example _explicitly_ asks the
command to show the dangling ones.
> Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
> points to it. If you could find just one copy of that missing blob
> object, possibly in some other repository, you could move it into
And this part, together with the introductory text of the section (not
shown in the context), says what the "third sentence" above wanted to say.
So overall I think this is a vast improvement without losing any
information or clarity.
Nice.
^ permalink raw reply
* Re: [PATCH] Allow Overriding GIT_BUILD_DIR
From: Junio C Hamano @ 2012-02-26 22:19 UTC (permalink / raw)
To: David A. Greene; +Cc: git
In-Reply-To: <87vcmu5psm.fsf@smith.obbligato.org>
"David A. Greene" <greened@obbligato.org> writes:
> Let tests override GIT_BUILD_DIR so git will work if tests are not at
> the same directory level as standard git tests. Prior to this change,
> GIT_BUILD_DIR is hardwired to be exactly one directory above where the
> test lives. A test within contrib/, for example, can now use
> test-lib.sh and set an appropriate value for GIT_BUILD_DIR.
Ok, this is getting closer. We use GIT_BUILD_DIR to find out crucial bits
of the build environment in order to run tests, like the binaries being
tested that are in $GIT_BUILD_DIR/bin-wrappers, but we set GIT_BUILD_DIR
always to one level above where the test script being run is (because they
are typically t/t1234-name.sh). By making them able to name GIT_BUILD_DIR
directly to a place that is different from a level above "$TEST_DIRECTORY",
a test script can live anywhere.
There are two more things that worries me a bit.
One is what TEST_DIRECTORY should mean in the new world order. We use it
to find where the test-lib.sh and other lib-*.sh helper definitions are,
also we use it to find large-ish test vectors like t3900/ and t4013/. If
an external test script t1234-git-subtree.sh wants to use a separate file
to keep its own helper definitions, how should it name it? It cannot be
relative to TEST_DIRECTORY that is typically "t/". It cannot be relative
to "../" as TRASH_DIRECTORY where the script runs, as the --root option
may move it elsewhere on the filesystem (and is the reason TEST_DIRECTORY
variable exists in the first place).
And how well does an external test script work with the --root option that
moves the TEST_DIRECTORY?
> Signed-off-by: David A. Greene <greened@obbligato.org>
> ---
> t/test-lib.sh | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
>
> ------------------
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index a65dfc7..4585138 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -55,6 +55,7 @@ unset $(perl -e '
> .*_TEST
> PROVE
> VALGRIND
> + BUILD_DIR
A funny indentation found here.
> ));
> @@ -901,7 +902,14 @@ then
> # itself.
> TEST_DIRECTORY=$(pwd)
> fi
> -GIT_BUILD_DIR="$TEST_DIRECTORY"/..
> +
> +if test -z "$GIT_BUILD_DIR"
> +then
> + # We allow tests to override this, in case they want to run tests
> + # outside of t/, e.g. for running tests on the test library
> + # itself.
# For in-tree test scripts, this is one level above the TEST_DIRECTORY
# (t/), but a test script that lives outside t/ can set this variable to
# point at the right place so that it can find t/ directory that house
# test helpers like lib-pager*.sh and test vectors like t4013/.
> + GIT_BUILD_DIR="$TEST_DIRECTORY"/..
> +fi
>
> if test -n "$valgrind"
> then
>
> --------------------
^ permalink raw reply
* Re: [PATCH] grep -P: Fix matching ^ and $
From: Junio C Hamano @ 2012-02-26 22:39 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1330161868-7954-1-git-send-email-michal.kiedrowicz@gmail.com>
Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> @@ -893,4 +900,20 @@ test_expect_success 'mimic ack-grep --group' '
> test_cmp expected actual
> '
>
> +cat >expected <<EOF
> +space: line with leading space1
> +space: line with leading space2
> +space: line with leading space3
> +EOF
> +
> +test_expect_success 'grep -E "^ "' '
> + git grep -E "^ " space >actual &&
> + test_cmp expected actual
> +'
> +
> +test_expect_success "grep -P '^ '" '
> + git grep -P "^ " space >actual &&
> + test_cmp expected actual
> +'
This test does not pass for me as I do not usually build with pcre;
shouldn't it be protected with some test prerequisite?
Otherwise the patch looks good; thanks.
^ permalink raw reply
* Re: [PATCH] fsck: do not print dangling objects by default
From: Junio C Hamano @ 2012-02-26 22:46 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <7vty2ddzqj.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think that both the ultimate goal explained above, and the direction in
> which the documentation updates tries to move us, are good. I only gave a
> cursory look at the code changes, but what they implement seems to match
> the intention.
>
> Of course I may be missing something, so objections from others to argue
> why we shouldn't do this is very much welcomed to stop me and Clemens ;-).
Let's start with the obvious.
It is much easier for a user to use a new option on the command line when
he wants to use an improved behaviour when he runs the command manually.
Having to update scripts that run the command to act on its output, on the
other hand, is much more painful to the users.
And the intended audience for this change clearly is interactive users
that follow the user-manual to try things out.
Given that, isn't it not just sufficient but actually better to instead
add a new --no-dangling option and keep the default unchanged?
^ permalink raw reply
* Re: [PATCH v6 00/11] Column display
From: Junio C Hamano @ 2012-02-26 23:02 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1330170078-29353-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Nguyễn Thái Ngọc Duy (11):
> column: add API to print items in columns
> Add git-column and column mode parsing
> Stop starting pager recursively
> column: add columnar layout
> column: support columns with different widths
> column: add column.ui for default column output settings
> help: reuse print_columns() for help -a
> branch: add --column
> status: add --column
> column: support piping stdout to external git-column process
> tag: add --column
The first one adds something that nobody uses, hence it cannot be blamed
by bisecting, but the "API" gets updated over time by other changes.
Perhaps the first two may want to become a single commit.
Other than that, the patch progression looks very logical. The column
output subsystem gets enhanced using git-column as the scaffolding to help
testing and developing it, and then various commands start to make use of
the result when the subsystem has become usable in their context.
But I am very much reluctant to see us adding a "git column" subcommand; I
cannot justify it myself because what it does is even less connected to
git than the "--no-index" mode of grep/diff commands, i.e. it does not
have much to do with "Git, the version control system".
Shouldn't it be "test-column" that is useful during the hacking, much like
"test-date", "test-chmtime", and "test_credential"?
^ permalink raw reply
* Re: [PATCH v6 05/11] column: support columns with different widths
From: Junio C Hamano @ 2012-02-26 23:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1330170078-29353-6-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
The contrast between this and the previous one is striking.
The addition of MODE_COLUMN and MODE_ROW are very well explained, and it
will help people to later learn how to use the columns subsystem in their
programs. But this does not even mention what "different widths" is, let
alone explaining how to use it or if it is always on and the programs do
not have to worry about (and have no control over) its behaviour.
I am guessing from the patch that you can tell the column subsystem to use
a different mode, just like you can use MODE_COLUMN or MODE_ROW to instruct
column/row major ordering, by using MODE_DENSE or something.
I am also reading from the patch that the "dense mode" allocates minimum
necessary width dynamically to columns, which end up having different
width. So "different" is not the more important part; "dense" is.
But the reader should not have to guess these things.
^ permalink raw reply
* Re: [PATCH 2/3] parse-options: allow positivation of options starting, with no-
From: Junio C Hamano @ 2012-02-26 23:32 UTC (permalink / raw)
To: René Scharfe
Cc: git, Bert Wesarg, Geoffrey Irving, Johannes Schindelin,
Pierre Habouzit
In-Reply-To: <4F49332E.7070003@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Long options can be negated by adding no- right after the leading
> two dashes. This is useful e.g. to override options set by aliases.
>
> For options that are defined to start with no- already, this looks
> a bit funny. Allow such options to also be negated by removing the
> prefix.
True about "a bit funny", but the fact that the solution has to touch
parse-options.c confuses me.
I would naïvely expect that it would be sufficient to update an existing
definition for "--no-frotz" that uses PARSE_OPT_NONEG to instead define
"--frotz" that by itself is a no-op, and "--no-frotz" would cause whatever
the option currently means, with an update to the help text that says
something to the effect that "--frotz by itself is meaningless and is
always used as --no-frotz".
There must be a reason the patch had to take an approach in the opposite
direction to allow removal of --[no-] prefix, but it is not obvious to me
what it is.
Note that I am _not_ saying that this is a bad change. I am just saying
that it is unclear why we still want two different ways to support the
"--no-frotz" option, one by defining "frotz" option that allows "no" to be
prefixed, and the other by defining "no-frotz" that allows "no-" to be
stripped.
^ permalink raw reply
* Re: [PATCH] am: don't infloop for an empty input file
From: Junio C Hamano @ 2012-02-26 23:58 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <87399y24wt.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Today, "git am" surprised me.
> I mistakenly ran it on an empty file and it went into an infinite loop.
Yeah, that is an embarrassing regression in 1.7.7.
Thanks for noticing.
^ permalink raw reply
* Re: [PATCH] rebase -m: only call "notes copy" when rewritten exists and is non-empty
From: Junio C Hamano @ 2012-02-27 0:01 UTC (permalink / raw)
To: Andrew Wong; +Cc: git
In-Reply-To: <1330144282-22540-1-git-send-email-andrew.kw.w@gmail.com>
Andrew Wong <andrew.kw.w@gmail.com> writes:
> This prevents a shell error complaining rebase-merge/rewritten doesn't exist.
Yeah, the updated logic overall makes more sense, too. "when we have
rewritten, then we do these two things" is clear from the text.
Thanks.
^ permalink raw reply
* Re: [PATCH v4] Display change history as a diff between two dirs
From: Junio C Hamano @ 2012-02-27 0:13 UTC (permalink / raw)
To: Roland Kaufmann, Tim Henigan; +Cc: git
In-Reply-To: <4F495703.10401@gmail.com>
Roland Kaufmann <rlndkfmn+git@gmail.com> writes:
> Watching patches serially it can be difficult to get an overview of how
> a pervasive change is distributed through-out different modules. Thus;
>
> Extract snapshots of the files that have changed between two revisions
> into temporary directories and launch a graphical tool to show the diff
> between them.
>
> Use existing functionality in git-diff to get the files themselves, and
> git-difftool to launch the diff viewer.
>
> Based on a script called 'git-diffc' by Nitin Gupta.
>
> Signed-off-by: Roland Kaufmann <rlndkfmn+git@gmail.com>
> ---
Sorry, but I completely forgot about this three-month old topic (the last
discussion was early November last year).
How does this compare with Tim Henigan's "diffall"? I think the problem
these two topics try to address is the same, and their approach may be
similar enough that having one consolidated effort might be worth it.
I seem to have suggested during the previous review round of this series
the same thing I suggested to Tim, that we _might_ want to instead have
the logic to populate the two temporary trees on the core side with a new
external diff interface.
http://thread.gmane.org/gmane.comp.version-control.git/184458/focus=184462
^ permalink raw reply
* Re: [PATCH 0/2] git-p4: fix submit regression with --use-client-spec
From: Junio C Hamano @ 2012-02-27 0:18 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Laurent Charrière
In-Reply-To: <1330218385-22309-1-git-send-email-pw@padd.com>
Pete Wyckoff <pw@padd.com> writes:
> This pair of patches fixes a regression that happened with ecb7cf9
> (git-p4: rewrite view handling, 2012-01-02). There are two factors that
> affect where files go in the client when submitting: the cilent spec,
> and the depot path. When the depot path was not exactly the root of
> the client, submit fails.
>
> Fix this by always using the true client root. And also notice that
> somebody has to tell the submit path that it should be looking at the
> cilent spec. Save useClientSpec in a configuration variable if it
> was specified as an option on the command line.
>
> Junio: can you put this on maint to go out with the next 1.9.x?
Surely and thanks.
Your "p4: submit with wildcards" seems to conflict with this change and
may need to be rebased, though.
>
> Pete Wyckoff (2):
> git-p4: set useClientSpec variable on initial clone
> git-p4: fix submit regression with clientSpec and subdir clone
>
> Documentation/git-p4.txt | 10 ++-
> contrib/fast-import/git-p4 | 97 ++++++++++++++++---------
> t/t9809-git-p4-client-view.sh | 159 ++++++++++++++++++++++++++++++++++++++---
> 3 files changed, 219 insertions(+), 47 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/2] git-p4: fix submit regression with --use-client-spec
From: Pete Wyckoff @ 2012-02-27 0:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Laurent Charrière
In-Reply-To: <7vhaydcenz.fsf@alter.siamese.dyndns.org>
gitster@pobox.com wrote on Sun, 26 Feb 2012 16:18 -0800:
> Pete Wyckoff <pw@padd.com> writes:
>
> > This pair of patches fixes a regression that happened with ecb7cf9
> > (git-p4: rewrite view handling, 2012-01-02). There are two factors that
> > affect where files go in the client when submitting: the cilent spec,
> > and the depot path. When the depot path was not exactly the root of
> > the client, submit fails.
> >
> > Fix this by always using the true client root. And also notice that
> > somebody has to tell the submit path that it should be looking at the
> > cilent spec. Save useClientSpec in a configuration variable if it
> > was specified as an option on the command line.
> >
> > Junio: can you put this on maint to go out with the next 1.9.x?
>
> Surely and thanks.
>
> Your "p4: submit with wildcards" seems to conflict with this change and
> may need to be rebased, though.
Ah, yes. The conflicting chunks can be added in any order above
class P4Command. I'll rebase and resend in a few days, after
waiting for review comments.
-- Pete
^ permalink raw reply
* Re: [PATCH v6 00/11] Column display
From: Nguyen Thai Ngoc Duy @ 2012-02-27 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa45dwq7.fsf@alter.siamese.dyndns.org>
2012/2/27 Junio C Hamano <gitster@pobox.com>:
> But I am very much reluctant to see us adding a "git column" subcommand; I
> cannot justify it myself because what it does is even less connected to
> git than the "--no-index" mode of grep/diff commands, i.e. it does not
> have much to do with "Git, the version control system".
>
> Shouldn't it be "test-column" that is useful during the hacking, much like
> "test-date", "test-chmtime", and "test_credential"?
It used to be test-column. But we would need an external program to
pipe through to minimize changing display code, especially when
display code can get complicated (e.g. git-tag for example). The other
reason is to get column display even when the command does not support
it (e.g. GIT_PAGER="git column" git diff --name-status HEAD~10)
--
Duy
^ 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