* [PATCH v16 1/7] bisect: move argument parsing before state modification.
From: Jon Seymour @ 2011-08-03 21:57 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312408626-8600-1-git-send-email-jon.seymour@gmail.com>
Currently 'git bisect start' modifies some state prior to checking
that its arguments are valid.
This change moves argument validation before state modification
with the effect that state modification does not occur
unless argument validations succeeds.
An existing test is changed to check that new bisect state
is not created if arguments are invalid.
A new test is added to check that existing bisect state
is not modified if arguments are invalid.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
git-bisect.sh | 66 +++++++++++++++++++++---------------------
t/t6030-bisect-porcelain.sh | 14 +++++++--
2 files changed, 44 insertions(+), 36 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index b2186a8..20f6dd5 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -60,6 +60,39 @@ bisect_autostart() {
bisect_start() {
#
+ # Check for one bad and then some good revisions.
+ #
+ has_double_dash=0
+ for arg; do
+ case "$arg" in --) has_double_dash=1; break ;; esac
+ done
+ orig_args=$(git rev-parse --sq-quote "$@")
+ bad_seen=0
+ eval=''
+ while [ $# -gt 0 ]; do
+ arg="$1"
+ case "$arg" in
+ --)
+ shift
+ break
+ ;;
+ *)
+ rev=$(git rev-parse -q --verify "$arg^{commit}") || {
+ test $has_double_dash -eq 1 &&
+ die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
+ break
+ }
+ case $bad_seen in
+ 0) state='bad' ; bad_seen=1 ;;
+ *) state='good' ;;
+ esac
+ eval="$eval bisect_write '$state' '$rev' 'nolog'; "
+ shift
+ ;;
+ esac
+ done
+
+ #
# Verify HEAD.
#
head=$(GIT_DIR="$GIT_DIR" git symbolic-ref -q HEAD) ||
@@ -98,39 +131,6 @@ bisect_start() {
bisect_clean_state || exit
#
- # Check for one bad and then some good revisions.
- #
- has_double_dash=0
- for arg; do
- case "$arg" in --) has_double_dash=1; break ;; esac
- done
- orig_args=$(git rev-parse --sq-quote "$@")
- bad_seen=0
- eval=''
- while [ $# -gt 0 ]; do
- arg="$1"
- case "$arg" in
- --)
- shift
- break
- ;;
- *)
- rev=$(git rev-parse -q --verify "$arg^{commit}") || {
- test $has_double_dash -eq 1 &&
- die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
- break
- }
- case $bad_seen in
- 0) state='bad' ; bad_seen=1 ;;
- *) state='good' ;;
- esac
- eval="$eval bisect_write '$state' '$rev' 'nolog'; "
- shift
- ;;
- esac
- done
-
- #
# Change state.
# In case of mistaken revs or checkout error, or signals received,
# "bisect_auto_next" below may exit or misbehave.
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index b5063b6..b3d1b14 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -138,15 +138,23 @@ test_expect_success 'bisect start: back in good branch' '
grep "* other" branch.output > /dev/null
'
-test_expect_success 'bisect start: no ".git/BISECT_START" if junk rev' '
- git bisect start $HASH4 $HASH1 -- &&
- git bisect good &&
+test_expect_success 'bisect start: no ".git/BISECT_START" created if junk rev' '
+ git bisect reset &&
test_must_fail git bisect start $HASH4 foo -- &&
git branch > branch.output &&
grep "* other" branch.output > /dev/null &&
test_must_fail test -e .git/BISECT_START
'
+test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if junk rev' '
+ git bisect start $HASH4 $HASH1 -- &&
+ git bisect good &&
+ cp .git/BISECT_START saved &&
+ test_must_fail git bisect start $HASH4 foo -- &&
+ git branch > branch.output &&
+ grep "* (no branch)" branch.output > /dev/null &&
+ test_cmp saved .git/BISECT_START
+'
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
git bisect start $HASH4 $HASH1 -- &&
git bisect good &&
--
1.7.6.352.g172e
^ permalink raw reply related
* [PATCH v16 2/7] bisect: use && to connect statements that are deferred with eval.
From: Jon Seymour @ 2011-08-03 21:57 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312408626-8600-1-git-send-email-jon.seymour@gmail.com>
Christian Couder pointed out that the existing eval strategy
swallows an initial non-zero return. Using && to connect
the statements should fix this.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
git-bisect.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 20f6dd5..a44ffe1 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -86,7 +86,7 @@ bisect_start() {
0) state='bad' ; bad_seen=1 ;;
*) state='good' ;;
esac
- eval="$eval bisect_write '$state' '$rev' 'nolog'; "
+ eval="$eval bisect_write '$state' '$rev' 'nolog' &&"
shift
;;
esac
@@ -145,7 +145,7 @@ bisect_start() {
#
echo "$start_head" >"$GIT_DIR/BISECT_START" &&
git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES" &&
- eval "$eval" &&
+ eval "$eval true" &&
echo "git bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
#
# Check if we can proceed to the next bisect state.
--
1.7.6.352.g172e
^ permalink raw reply related
* [PATCH v16 3/7] bisect: add tests to document expected behaviour in presence of broken trees.
From: Jon Seymour @ 2011-08-03 21:57 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312408626-8600-1-git-send-email-jon.seymour@gmail.com>
If the repo is broken, we expect bisect to fail.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
t/t6030-bisect-porcelain.sh | 48 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index b3d1b14..9ae2de8 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -581,5 +581,53 @@ test_expect_success 'erroring out when using bad path parameters' '
'
#
+# This creates a broken branch which cannot be checked out because
+# the tree created has been deleted.
#
+# H1-H2-H3-H4-H5-H6-H7 <--other
+# \
+# S5-S6'-S7'-S8'-S9 <--broken
+#
+# Commits marked with ' have a missing tree.
+#
+test_expect_success 'broken branch creation' '
+ git bisect reset &&
+ git checkout -b broken $HASH4 &&
+ git tag BROKEN_HASH4 $HASH4 &&
+ add_line_into_file "5(broken): first line on a broken branch" hello2 &&
+ git tag BROKEN_HASH5 &&
+ mkdir missing &&
+ :> missing/MISSING &&
+ git add missing/MISSING &&
+ git commit -m "6(broken): Added file that will be deleted"
+ git tag BROKEN_HASH6 &&
+ add_line_into_file "7(broken): second line on a broken branch" hello2 &&
+ git tag BROKEN_HASH7 &&
+ add_line_into_file "8(broken): third line on a broken branch" hello2 &&
+ git tag BROKEN_HASH8 &&
+ git rm missing/MISSING &&
+ git commit -m "9(broken): Remove missing file"
+ git tag BROKEN_HASH9 &&
+ rm .git/objects/39/f7e61a724187ab767d2e08442d9b6b9dab587d
+'
+
+echo "" > expected.ok
+cat > expected.missing-tree.default <<EOF
+fatal: unable to read tree 39f7e61a724187ab767d2e08442d9b6b9dab587d
+EOF
+
+test_expect_success 'bisect fails if tree is broken on start commit' '
+ git bisect reset &&
+ test_must_fail git bisect start BROKEN_HASH7 BROKEN_HASH4 2>error.txt &&
+ test_cmp expected.missing-tree.default error.txt
+'
+
+test_expect_success 'bisect fails if tree is broken on trial commit' '
+ git bisect reset &&
+ test_must_fail git bisect start BROKEN_HASH9 BROKEN_HASH4 2>error.txt &&
+ git reset --hard broken &&
+ git checkout broken &&
+ test_cmp expected.missing-tree.default error.txt
+'
+
test_done
--
1.7.6.352.g172e
^ permalink raw reply related
* [PATCH v16 4/7] bisect: introduce support for --no-checkout option.
From: Jon Seymour @ 2011-08-03 21:57 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312408626-8600-1-git-send-email-jon.seymour@gmail.com>
If --no-checkout is specified, then the bisection process uses:
git update-ref --no-deref HEAD <trial>
at each trial instead of:
git checkout <trial>
Improved-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
bisect.c | 33 ++++++++++++++++++++++-----------
bisect.h | 2 +-
builtin/bisect--helper.c | 7 +++++--
3 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/bisect.c b/bisect.c
index dd7e8ed..c7b7d79 100644
--- a/bisect.c
+++ b/bisect.c
@@ -24,6 +24,7 @@ struct argv_array {
static const char *argv_checkout[] = {"checkout", "-q", NULL, "--", NULL};
static const char *argv_show_branch[] = {"show-branch", NULL, NULL};
+static const char *argv_update_ref[] = {"update-ref", "--no-deref", "BISECT_HEAD", NULL, NULL};
/* bits #0-15 in revision.h */
@@ -707,16 +708,23 @@ static void mark_expected_rev(char *bisect_rev_hex)
die("closing file %s: %s", filename, strerror(errno));
}
-static int bisect_checkout(char *bisect_rev_hex)
+static int bisect_checkout(char *bisect_rev_hex, int no_checkout)
{
int res;
mark_expected_rev(bisect_rev_hex);
argv_checkout[2] = bisect_rev_hex;
- res = run_command_v_opt(argv_checkout, RUN_GIT_CMD);
- if (res)
- exit(res);
+ if (no_checkout) {
+ argv_update_ref[3] = bisect_rev_hex;
+ if (run_command_v_opt(argv_update_ref, RUN_GIT_CMD))
+ die("update-ref --no-deref HEAD failed on %s",
+ bisect_rev_hex);
+ } else {
+ res = run_command_v_opt(argv_checkout, RUN_GIT_CMD);
+ if (res)
+ exit(res);
+ }
argv_show_branch[1] = bisect_rev_hex;
return run_command_v_opt(argv_show_branch, RUN_GIT_CMD);
@@ -788,7 +796,7 @@ static void handle_skipped_merge_base(const unsigned char *mb)
* - If one is "skipped", we can't know but we should warn.
* - If we don't know, we should check it out and ask the user to test.
*/
-static void check_merge_bases(void)
+static void check_merge_bases(int no_checkout)
{
struct commit_list *result;
int rev_nr;
@@ -806,7 +814,7 @@ static void check_merge_bases(void)
handle_skipped_merge_base(mb);
} else {
printf("Bisecting: a merge base must be tested\n");
- exit(bisect_checkout(sha1_to_hex(mb)));
+ exit(bisect_checkout(sha1_to_hex(mb), no_checkout));
}
}
@@ -849,7 +857,7 @@ static int check_ancestors(const char *prefix)
* If a merge base must be tested by the user, its source code will be
* checked out to be tested by the user and we will exit.
*/
-static void check_good_are_ancestors_of_bad(const char *prefix)
+static void check_good_are_ancestors_of_bad(const char *prefix, int no_checkout)
{
const char *filename = git_path("BISECT_ANCESTORS_OK");
struct stat st;
@@ -868,7 +876,7 @@ static void check_good_are_ancestors_of_bad(const char *prefix)
/* Check if all good revs are ancestor of the bad rev. */
if (check_ancestors(prefix))
- check_merge_bases();
+ check_merge_bases(no_checkout);
/* Create file BISECT_ANCESTORS_OK. */
fd = open(filename, O_CREAT | O_TRUNC | O_WRONLY, 0600);
@@ -908,8 +916,11 @@ static void show_diff_tree(const char *prefix, struct commit *commit)
* We use the convention that exiting with an exit code 10 means that
* the bisection process finished successfully.
* In this case the calling shell script should exit 0.
+ *
+ * If no_checkout is non-zero, the bisection process does not
+ * checkout the trial commit but instead simply updates BISECT_HEAD.
*/
-int bisect_next_all(const char *prefix)
+int bisect_next_all(const char *prefix, int no_checkout)
{
struct rev_info revs;
struct commit_list *tried;
@@ -920,7 +931,7 @@ int bisect_next_all(const char *prefix)
if (read_bisect_refs())
die("reading bisect refs failed");
- check_good_are_ancestors_of_bad(prefix);
+ check_good_are_ancestors_of_bad(prefix, no_checkout);
bisect_rev_setup(&revs, prefix, "%s", "^%s", 1);
revs.limited = 1;
@@ -966,6 +977,6 @@ int bisect_next_all(const char *prefix)
"(roughly %d step%s)\n", nr, (nr == 1 ? "" : "s"),
steps, (steps == 1 ? "" : "s"));
- return bisect_checkout(bisect_rev_hex);
+ return bisect_checkout(bisect_rev_hex, no_checkout);
}
diff --git a/bisect.h b/bisect.h
index 0862ce5..22f2e4d 100644
--- a/bisect.h
+++ b/bisect.h
@@ -27,7 +27,7 @@ struct rev_list_info {
const char *header_prefix;
};
-extern int bisect_next_all(const char *prefix);
+extern int bisect_next_all(const char *prefix, int no_checkout);
extern int estimate_bisect_steps(int all);
diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
index 5b22639..8d325a5 100644
--- a/builtin/bisect--helper.c
+++ b/builtin/bisect--helper.c
@@ -4,16 +4,19 @@
#include "bisect.h"
static const char * const git_bisect_helper_usage[] = {
- "git bisect--helper --next-all",
+ "git bisect--helper --next-all [--no-checkout]",
NULL
};
int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
{
int next_all = 0;
+ int no_checkout = 0;
struct option options[] = {
OPT_BOOLEAN(0, "next-all", &next_all,
"perform 'git bisect next'"),
+ OPT_BOOLEAN(0, "no-checkout", &no_checkout,
+ "update BISECT_HEAD instead of checking out the current commit"),
OPT_END()
};
@@ -24,5 +27,5 @@ int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
usage_with_options(git_bisect_helper_usage, options);
/* next-all */
- return bisect_next_all(prefix);
+ return bisect_next_all(prefix, no_checkout);
}
--
1.7.6.352.g172e
^ permalink raw reply related
* [PATCH v16 5/7] bisect: introduce --no-checkout support into porcelain.
From: Jon Seymour @ 2011-08-03 21:57 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312408626-8600-1-git-send-email-jon.seymour@gmail.com>
git-bisect can now perform bisection of a history without performing
a checkout at each stage of the bisection process. Instead, HEAD is updated.
One use-case for this function is allow git bisect to be used with
damaged repositories where git checkout would fail because the tree
referenced by the commit is damaged.
It can also be used in other cases where actual checkout of the tree
is not required to progress the bisection.
Improved-by: Christian Couder <chriscool@tuxfamily.org>
Improved-by: Junio C Hamano <gitster@pobox.com>
Improved-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
git-bisect.sh | 44 +++++++++++++++++++++++++++++++++-----------
1 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index a44ffe1..64f2302 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -3,7 +3,7 @@
USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
LONG_USAGE='git bisect help
print this long help message.
-git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
+git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<pathspec>...]
reset bisect state and start bisection.
git bisect bad [<rev>]
mark <rev> a known-bad revision.
@@ -34,6 +34,15 @@ require_work_tree
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+bisect_head()
+{
+ if test -f "$GIT_DIR/BISECT_HEAD"; then
+ echo BISECT_HEAD;
+ else
+ echo HEAD
+ fi
+}
+
bisect_autostart() {
test -s "$GIT_DIR/BISECT_START" || {
(
@@ -69,6 +78,7 @@ bisect_start() {
orig_args=$(git rev-parse --sq-quote "$@")
bad_seen=0
eval=''
+ mode=''
while [ $# -gt 0 ]; do
arg="$1"
case "$arg" in
@@ -76,6 +86,11 @@ bisect_start() {
shift
break
;;
+ --no-checkout)
+ mode=--no-checkout;
+ shift ;;
+ --*)
+ die "$(eval_gettext "unrecognised option: '\$arg'")" ;;
*)
rev=$(git rev-parse -q --verify "$arg^{commit}") || {
test $has_double_dash -eq 1 &&
@@ -107,7 +122,9 @@ bisect_start() {
then
# Reset to the rev from where we started.
start_head=$(cat "$GIT_DIR/BISECT_START")
- git checkout "$start_head" -- || exit
+ if test "z$mode" != "z--no-checkout"; then
+ git checkout "$start_head" --
+ fi
else
# Get rev from where we start.
case "$head" in
@@ -143,7 +160,10 @@ bisect_start() {
#
# Write new start state.
#
- echo "$start_head" >"$GIT_DIR/BISECT_START" &&
+ echo "$start_head" >"$GIT_DIR/BISECT_START" && {
+ test "z$mode" != "z--no-checkout" ||
+ git update-ref --no-deref BISECT_HEAD "$start_head"
+ } &&
git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES" &&
eval "$eval true" &&
echo "git bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
@@ -206,8 +226,8 @@ bisect_state() {
0,*)
die "$(gettext "Please call 'bisect_state' with at least one argument.")" ;;
1,bad|1,good|1,skip)
- rev=$(git rev-parse --verify HEAD) ||
- die "$(gettext "Bad rev input: HEAD")"
+ rev=$(git rev-parse --verify $(bisect_head)) ||
+ die "$(gettext "Bad rev input: $(bisect_head)")"
bisect_write "$state" "$rev"
check_expected_revs "$rev" ;;
2,bad|*,good|*,skip)
@@ -291,7 +311,7 @@ bisect_next() {
bisect_next_check good
# Perform all bisection computation, display and checkout
- git bisect--helper --next-all
+ git bisect--helper --next-all $(test -f "$GIT_DIR/BISECT_HEAD" && echo --no-checkout)
res=$?
# Check if we should exit because bisection is finished
@@ -340,12 +360,13 @@ bisect_reset() {
*)
usage ;;
esac
- if git checkout "$branch" -- ; then
- bisect_clean_state
- else
- die "$(eval_gettext "Could not check out original HEAD '\$branch'.
+ if ! test -f "$GIT_DIR/BISECT_HEAD"; then
+ if ! git checkout "$branch" --; then
+ die "$(eval_gettext "Could not check out original HEAD '\$branch'.
Try 'git bisect reset <commit>'.")"
+ fi
fi
+ bisect_clean_state
}
bisect_clean_state() {
@@ -362,7 +383,8 @@ bisect_clean_state() {
rm -f "$GIT_DIR/BISECT_RUN" &&
# Cleanup head-name if it got left by an old version of git-bisect
rm -f "$GIT_DIR/head-name" &&
-
+ git update-ref -d --no-deref BISECT_HEAD &&
+ # clean up BISECT_START last
rm -f "$GIT_DIR/BISECT_START"
}
--
1.7.6.352.g172e
^ permalink raw reply related
* [PATCH v16 6/7] bisect: add tests for the --no-checkout option.
From: Jon Seymour @ 2011-08-03 21:57 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312408626-8600-1-git-send-email-jon.seymour@gmail.com>
These tests verify that git-bisect --no-checkout can successfully
bisect commit histories that reference damaged trees.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
t/t6030-bisect-porcelain.sh | 82 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 9ae2de8..113e1c5 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -126,6 +126,18 @@ test_expect_success 'bisect reset removes packed refs' '
test -z "$(git for-each-ref "refs/heads/bisect")"
'
+test_expect_success 'bisect reset removes bisect state after --no-checkout' '
+ git bisect reset &&
+ git bisect start --no-checkout &&
+ git bisect good $HASH1 &&
+ git bisect bad $HASH3 &&
+ git bisect next &&
+ git bisect reset &&
+ test -z "$(git for-each-ref "refs/bisect/*")" &&
+ test -z "$(git for-each-ref "refs/heads/bisect")" &&
+ test -z "$(git for-each-ref "BISECT_HEAD")"
+'
+
test_expect_success 'bisect start: back in good branch' '
git branch > branch.output &&
grep "* other" branch.output > /dev/null &&
@@ -616,6 +628,14 @@ cat > expected.missing-tree.default <<EOF
fatal: unable to read tree 39f7e61a724187ab767d2e08442d9b6b9dab587d
EOF
+check_same()
+{
+ echo "Checking $1 is the same as $2" &&
+ git rev-parse "$1" > expected.same &&
+ git rev-parse "$2" > expected.actual &&
+ test_cmp expected.same expected.actual
+}
+
test_expect_success 'bisect fails if tree is broken on start commit' '
git bisect reset &&
test_must_fail git bisect start BROKEN_HASH7 BROKEN_HASH4 2>error.txt &&
@@ -630,4 +650,66 @@ test_expect_success 'bisect fails if tree is broken on trial commit' '
test_cmp expected.missing-tree.default error.txt
'
+test_expect_success 'bisect: --no-checkout - start commit bad' '
+ git bisect reset &&
+ git bisect start BROKEN_HASH7 BROKEN_HASH4 --no-checkout &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
+ git bisect reset
+'
+
+test_expect_success 'bisect: --no-checkout - trial commit bad' '
+ git bisect reset &&
+ git bisect start broken BROKEN_HASH4 --no-checkout &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
+ git bisect reset
+'
+
+test_expect_success 'bisect: --no-checkout - target before breakage' '
+ git bisect reset &&
+ git bisect start broken BROKEN_HASH4 --no-checkout &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
+ git bisect bad BISECT_HEAD &&
+ check_same BROKEN_HASH5 BISECT_HEAD &&
+ git bisect bad BISECT_HEAD &&
+ check_same BROKEN_HASH5 bisect/bad &&
+ git bisect reset
+'
+
+test_expect_success 'bisect: --no-checkout - target in breakage' '
+ git bisect reset &&
+ git bisect start broken BROKEN_HASH4 --no-checkout &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
+ git bisect bad BISECT_HEAD &&
+ check_same BROKEN_HASH5 BISECT_HEAD &&
+ git bisect good BISECT_HEAD &&
+ check_same BROKEN_HASH6 bisect/bad &&
+ git bisect reset
+'
+
+test_expect_success 'bisect: --no-checkout - target after breakage' '
+ git bisect reset &&
+ git bisect start broken BROKEN_HASH4 --no-checkout &&
+ check_same BROKEN_HASH6 BISECT_HEAD &&
+ git bisect good BISECT_HEAD &&
+ check_same BROKEN_HASH8 BISECT_HEAD &&
+ git bisect good BISECT_HEAD &&
+ check_same BROKEN_HASH9 bisect/bad &&
+ git bisect reset
+'
+
+test_expect_success 'bisect: demonstrate identification of damage boundary' "
+ git bisect reset &&
+ git checkout broken &&
+ git bisect start broken master --no-checkout &&
+ git bisect run sh -c '
+ GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
+ git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
+ git pack-objects --stdout >/dev/null < tmp.$$ &&
+ rc=$?
+ rm tmp.$$
+ test \$rc = 0' &&
+ check_same BROKEN_HASH6 bisect/bad &&
+ git bisect reset
+"
+
test_done
--
1.7.6.352.g172e
^ permalink raw reply related
* [PATCH v16 7/7] bisect: add documentation for --no-checkout option.
From: Jon Seymour @ 2011-08-03 21:57 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312408626-8600-1-git-send-email-jon.seymour@gmail.com>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
Documentation/git-bisect.txt | 32 +++++++++++++++++++++++++++++++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index ab60a18..44b9845 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -17,7 +17,7 @@ The command takes various subcommands, and different options depending
on the subcommand:
git bisect help
- git bisect start [<bad> [<good>...]] [--] [<paths>...]
+ git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<paths>...]
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [(<rev>|<range>)...]
@@ -263,6 +263,17 @@ rewind the tree to the pristine state. Finally the script should exit
with the status of the real test to let the "git bisect run" command loop
determine the eventual outcome of the bisect session.
+OPTIONS
+-------
+--no-checkout::
++
+Do not checkout the new working tree at each iteration of the bisection
+process. Instead just update a special reference named 'BISECT_HEAD' to make
+it point to the commit that should be tested.
++
+This option may be useful when the test you would perform in each step
+does not require a checked out tree.
+
EXAMPLES
--------
@@ -343,6 +354,25 @@ $ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
This shows that you can do without a run script if you write the test
on a single line.
+* Locate a good region of the object graph in a damaged repository
++
+------------
+$ git bisect start HEAD <known-good-commit> [ <boundary-commit> ... ] --no-checkout
+$ git bisect run sh -c '
+ GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*") &&
+ git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
+ git pack-objects --stdout >/dev/null <tmp.$$
+ rc=$?
+ rm -f tmp.$$
+ test $rc = 0'
+
+------------
++
+In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit that
+has at least one parent whose reachable graph is fully traversable in the sense
+required by 'git pack objects'.
+
+
SEE ALSO
--------
link:git-bisect-lk2009.html[Fighting regressions with git bisect],
--
1.7.6.352.g172e
^ permalink raw reply related
* Re: [PATCH v2] commit: allow partial commits with relative paths
From: Junio C Hamano @ 2011-08-03 22:07 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Michael J Gruber, git, Reuben Thomas
In-Reply-To: <20110803192828.GA4228@toss>
Clemens Buchacher <drizzd@aon.at> writes:
> On Tue, Aug 02, 2011 at 02:31:47PM -0700, Junio C Hamano wrote:
>>
>> Perhaps "common_prefix()"?
>
> Yes, I was thinking the same thing actually.
>
>> Don't you also want to consolidate dir.c:common_prefix() with this?
>
> I wasn't aware of it. I'm really swamped right now, but I'll take a
> look at it soon.
It is not too big a deal, though, so I'll merge this one to next and we
can fix it up in-tree later.
Thanks.
^ permalink raw reply
* git-archive's wrong documentation: really write pax rather than tar
From: Hin-Tak Leung @ 2011-08-03 22:17 UTC (permalink / raw)
To: git, rene.scharfe
Had a bit of discussion on R-devel a few months ago, and now that I am doing something similiar again I decided to write and report this issue:
http://r.789695.n4.nabble.com/quot-R-CMD-check-quot-accepts-but-quot-R-CMD-INSTALL-quot-rejects-a-tar-ball-td3420479.html
The summary of the problem is that, git-archive's "--format=tar" option really write the pax format most of the time, and some cross-platform archive extraction library (rather than the all-powerful GNU tar) really does not think that's the tar format and bail out.
Is it possible to (1) add a warning in the man-page, or (2) actually fix the problem in git-archive ( archive-tar.c ) to generate more conformant archive packages?
Thanks. BTW, git (and git archive) is a great tool!
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: henri GEIST @ 2011-08-03 22:29 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, Heiko Voigt, Alexei Sholik, git, Sverre Rabbelier
In-Reply-To: <4E39BDFF.3050804@web.de>
Le mercredi 03 août 2011 à 23:30 +0200, Jens Lehmann a écrit :
> Am 03.08.2011 21:41, schrieb Junio C Hamano:
> > Jens Lehmann <Jens.Lehmann@web.de> writes:
> >
> >> 1) To use me, you need another submodule "foo"
> >>
> >> This is very helpful when you want to add the Gimp submodule and it
> >> can tell you you'll need the libpng submodule too in your superproject
> >> (but I'd vote to use the submodule name here, not the path as that
> >> should be the superproject's decision).
> >
> > That is something you can add to .gitmodules in the superproject, no?
> > E.g.
> >
> > [submodule "Gimp"]
> > url = http://some/where/
> > path = gimp/
> > depends = version 1.2.3 of "Glib"
> >
> > [submodule "Glib"]
> > url = http://some/where/else/
> > path = libs/glib
>
> The "depends" information is not very useful inside the superproject,
> because when you already know that there you can simply commit version
> 1.2.3 of Glib together with Gimp instead of adding that information.
> That's what gitlinks are for, no?
>
> But when you fetch a new version of Gimp into your submodule, it would be
> really nice if the superproject could be notified that the Gimp developers
> updated to 1.2.4 of Glib and inform you that an update of Glib might be
> appropriate. That could avoid having you to dig through compiler errors to
> find out that the new foobar() function from Glib 1.2.4 is needed (and if
> you need to pull in a bugfix in Glib, you might notice that *a lot* later
> when you forget to do that).
>
Exact, I am really happy to read this.
And better do not bother to have the suproject.
cd to gimp directory, type git status it can tell you every thing and
when your satisfied you just have to type make.
At this point the superproject have not any use.
> >> In addition to that, it can (but mustn't) specify any of the following:
> >
> > I am guessing you meant "does not have to", instead of mustn't, here...
>
> Sure, thanks for deciphering that.
>
> >> a) Of this submodule "foo" I need at least that version because I won't
> >> compile/work with older versions of that. (this can be tightened to
> >> "exactly that version" to give henri the behavior he wants, but that
> >> should be policy, not mandatory)
> >
> > The "loose collection of projects" approach like that has its uses, and it
> > is called "repo". Why re-invent it? The behaviour Henri wants to specify
> > the exact version is how git submodules work already, so I do not see
> > there is anything to be done here.
>
> Let me make this clear: this is not about changing how submodules are
> committed in a superproject. It is not about having a loose collection of
> projects, they stay tied together in a defined state by the superproject.
>
Yes but for me, from when I started this this topic, it was all about
having a loose collection of project with dependency references between
them. And get rid of the superproject.
It is my first and only goal.
> Henri wanted it a bit upside down: any submodule could request a certain
> version of another submodule somewhere else in the repo. And he wanted to
> use gitlinks from one submodule to another for that, which I - hopefully -
> convinced him was no good idea.
>
You just convince me that submodules are more than I need and to make a
lighter independent version of submodules which will never been followed
by git commands.
> But I understand his need to have some kind of "version hint" from one
> submodule to another. Just that he wants to take the hint very serious,
> while I see it as means to communicate from the submodule maintainer to
> the superproject developers that another submodule might have to be
> updated too when they do that to his.
>
Yes
> >> b) And if you don't know where to get it, use this url
> >
> > Again that is the job of .gitmodules in the superproject.
>
> Yes. But this idea is about how the url could get into the .gitmodules of
> the superproject in the first place. That can make it easier for the
> superproject's developer to import a submodule into his repo and much more
> important: it makes it possible to pull in submodule dependencies
> automatically e.g. when running "git submodule add --resolve-dependencies
> Gimp".
Only if you have a superproject.
If not do the same thing from the gimp repository, now it contain all
necessary infos to do the job.
> >> That is all stuff the submodule knows better than the superproject.
> >
> > Not necessarily. The version A0 of submodule A may depend on submodule B
> > and may also know it must have at least version B0 of that submodule, but
> > the superproject would know other constraints, e.g. the superproject
> > itself also calls into submodule B and wants a newer version B1 of it.
>
> Right. That's what I tried to explain to Henri, the superproject ties it all
> together. But I also like his idea to add a way to communicate information
> from the submodule to the superproject, and give the superproject a choice
> if it wants to use it.
>
yes but the superproject contain no code in your design.
Then it will never need anything by itself.
It is only a container which you will inform with data already known by
the submodules I do not see any value to it.
Henri
^ permalink raw reply
* Re: Fwd: [PATCH 0/6] rebase: command "ref" and options --rewrite-{refs,heads,tags}
From: Greg Price @ 2011-08-03 22:31 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <CAGdFq_jLv810a1H=+M14hEho9B_BS4OhdVUz1S-jjMBi6PP28g@mail.gmail.com>
On Wed, Aug 03, 2011 at 03:32:41PM +0200, Sverre Rabbelier wrote:
> FWIW, I'm having the exact same need while working on the remote-hg
> series (which depends on my remote-helper follow-up series, which
> depends on fast-export-fixes, which depends on my original
> remote-helper series, which depends on peffs initial patches; luckily
> the latter two have been merged to next :P). I'd really like having
> this available, especially the rebase -i support.
Thanks for the encouragement and the poke. Work is busy, but I've put
together a new version of the series addressing everyone's comments
from last time. I'll give it the finishing touches and try to send it
out soon.
Greg
^ permalink raw reply
* [PATCH] Tolerate zlib deflation with window size < 32Kb
From: roberto.tyley @ 2011-08-03 22:32 UTC (permalink / raw)
To: git; +Cc: gitster, Roberto Tyley
From: Roberto Tyley <roberto.tyley@guardian.co.uk>
Git currently reports loose objects as 'corrupt' if they've been
deflated using a window size less than 32Kb, because the
experimental_loose_object() function doesn't recognise the header
byte as a zlib header. This patch makes the function tolerant of
all valid window sizes (15-bit to 8-bit) - but doesn't sacrifice
it's accuracy in distingushing the standard loose-object format
from the experimental (now abandoned) format.
On memory constrained systems zlib may use a much smaller window
size - working on Agit, I found that Android uses a 4KB window;
giving a header byte of 0x48, not 0x78. Consequently all loose
objects generated appear 'corrupt', which is why Agit is a read-only
Git client at this time - I don't want my client to generate Git
repos that other clients treat as broken :(
This patch makes Git tolerant of different deflate settings - it
might appear that it changes experimental_loose_object() to the point
where it could incorrectly identify the experimental format as the
standard one, but the two criteria (bitmask & checksum) can only
give a false result for an experimental object where both of the
following are true:
1) object size is exactly 8 bytes when uncompressed (bitmask)
2) [single-byte in-pack git type&size header] * 256
+ [1st byte of the following zlib header] % 31 = 0 (checksum)
As it happens, for all possible combinations of valid object type
(1-4) and window bits (0-7), the only time when the checksum will be
divisible by 31 is for 0x1838 - ie object type *1*, a Commit - which,
due the fields all Commit objects must contain, could never be as
small as 8 bytes in size.
Given this, the combination of the two criteria (bitmask & checksum)
always correctly determines the buffer format, and is more tolerant
than the previous version.
The alternative to this patch is simply removing support for the
experimental format, which I am also totally cool with.
References:
Android uses a 4KB window for deflation:
http://android.git.kernel.org/?p=platform/libcore.git;a=blob;f=luni/src/main/native/java_util_zip_Deflater.cpp;h=c0b2feff196e63a7b85d97cf9ae5bb2583409c28;hb=refs/heads/gingerbread#l53
Code snippet searching for false positives with the zlib checksum:
https://gist.github.com/1118177
Signed-off-by: Roberto Tyley <roberto.tyley@guardian.co.uk>
---
sha1_file.c | 32 ++++++++++++++++++++++++++------
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 89d7e5e..2083e8b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1217,14 +1217,34 @@ static int experimental_loose_object(unsigned char *map)
unsigned int word;
/*
- * Is it a zlib-compressed buffer? If so, the first byte
- * must be 0x78 (15-bit window size, deflated), and the
- * first 16-bit word is evenly divisible by 31. If so,
- * we are looking at the official format, not the experimental
- * one.
+ * We must determine if the buffer contains the standard
+ * zlib-deflated stream or the experimental format based
+ * on the in-pack object format. Compare the header byte
+ * for each format:
+ *
+ * RFC1950 zlib w/ deflate : 0www1000 : 0 <= www <= 7
+ * Experimental pack-based : Stttssss : ttt = 1,2,3,4
+ *
+ * If bit 7 is clear and bits 0-3 equal 8, the buffer MUST be
+ * in standard loose-object format, UNLESS it is a Git-pack
+ * format object *exactly* 8 bytes in size when inflated.
+ *
+ * However, RFC1950 also specifies that the 1st 16-bit word
+ * must be divisible by 31 - this checksum tells us our buffer
+ * is in the standard format, giving a false positive only if
+ * the 1st word of the Git-pack format object happens to be
+ * divisible by 31, ie:
+ * ((byte0 * 256) + byte1) % 31 = 0
+ * => 0ttt10000www1000 % 31 = 0
+ *
+ * As it happens, this case can only arise for www=3 & ttt=1
+ * - ie, a Commit object, which would have to be 8 bytes in
+ * size. As no Commit can be that small, we find that the
+ * combination of these two criteria (bitmask & checksum)
+ * can always correctly determine the buffer format.
*/
word = (map[0] << 8) + map[1];
- if (map[0] == 0x78 && !(word % 31))
+ if ((map[0] & 0x88) == 0x08 && !(word % 31))
return 0;
else
return 1;
--
1.7.4.1
^ permalink raw reply related
* Re: tracking submodules out of main directory.
From: henri GEIST @ 2011-08-03 22:41 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Junio C Hamano, Alexei Sholik, git,
Sverre Rabbelier
In-Reply-To: <20110803214530.GA34347@book.hvoigt.net>
Le mercredi 03 août 2011 à 23:45 +0200, Heiko Voigt a écrit :
> Hi,
>
> On Wed, Aug 03, 2011 at 09:07:14PM +0200, Jens Lehmann wrote:
> > Am 03.08.2011 19:11, schrieb Junio C Hamano:
> > But the superproject is still the place to say: I know these versions of
> > all submodules work together, so I commit their gitlinks here. But this
> > scheme enables submodules to give hints to help the superproject's user.
> >
> > > I also suspect that allowing each submodule to know and demand specific
> > > versions of other submodules will lead to inconsistencies. Which version
> > > of submodule C would you demand to have when submodule A wants version C0
> > > and submodule B wants version C1 of it?
> >
> > Right, in the discussion so far it seemed like henri seems to be the only
> > user who is wanting an exact match, and he says he needs to see these
> > inconsistencies. But I think he can modify the "version xxx or newer" to
> > his needs without imposing these inconsistencies on users (like me) who
> > don't want to see them.
>
> And I imagine if a submodule has such hints we could add a command say
>
> git submodule resolve-dependencies
>
> which could resolve such "I need a version newer than" hints given by a
> submodule to help the user to update a submodule in the superproject.
>
> Disclaimer: I think we need to think about all the implications such a
> scheme introduces very carefully. The picture is still a bit blurry for
> me.
>
As I see it if you want a command like
"git submodule resolve-dependencies"
- the process need to decide if it will chose te lower version above
all requierments or directly the head.
- if one or more say I want exactly this version and it is not
satisfied we need at least a warning.
- We need to issue an error if all the required version can not be
found in the same branch.
Henri
^ permalink raw reply
* Re: [PATCH 1/2] gitattributes: Clarify discussion of attribute macros
From: Jeff King @ 2011-08-03 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7v1ux2b2d8.fsf@alter.siamese.dyndns.org>
On Wed, Aug 03, 2011 at 02:40:19PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I don't know if that was intentional, or if the behavior is simply
> > accidental and the original code was simply never meant to have
> > "-binary" called at all.
>
> The latter. You were never expected to say -macro at all.
OK. Maybe we should flag an error, then? Or if not, then make the
documentation more clear that it's not allowed (or even say the current
behavior is reasonable, and document it).
-Peff
^ permalink raw reply
* Re: [PATCH] Tolerate zlib deflation with window size < 32Kb
From: Junio C Hamano @ 2011-08-03 23:56 UTC (permalink / raw)
To: roberto.tyley; +Cc: git, Roberto Tyley
In-Reply-To: <1312410730-12261-1-git-send-email-roberto.tyley@gmail.com>
roberto.tyley@gmail.com writes:
> + * We must determine if the buffer contains the standard
> + * zlib-deflated stream or the experimental format based
> + * on the in-pack object format. Compare the header byte
> + * for each format:
> + *
> + * RFC1950 zlib w/ deflate : 0www1000 : 0 <= www <= 7
> + * Experimental pack-based : Stttssss : ttt = 1,2,3,4
> + *
> + * If bit 7 is clear and bits 0-3 equal 8, the buffer MUST be
> + * in standard loose-object format, UNLESS it is a Git-pack
> + * format object *exactly* 8 bytes in size when inflated.
> + *
> + * However, RFC1950 also specifies that the 1st 16-bit word
> + * must be divisible by 31 - this checksum tells us our buffer
> + * is in the standard format, giving a false positive only if
> + * the 1st word of the Git-pack format object happens to be
> + * divisible by 31, ie:
> + * ((byte0 * 256) + byte1) % 31 = 0
> + * => 0ttt10000www1000 % 31 = 0
> + *
> + * As it happens, this case can only arise for www=3 & ttt=1
> + * - ie, a Commit object, which would have to be 8 bytes in
> + * size. As no Commit can be that small, we find that the
> + * combination of these two criteria (bitmask & checksum)
> + * can always correctly determine the buffer format.
> */
> word = (map[0] << 8) + map[1];
> - if (map[0] == 0x78 && !(word % 31))
> + if ((map[0] & 0x88) == 0x08 && !(word % 31))
Are you sure about this 0x88? Isn't it 0x8F or something?
> return 0;
> else
> return 1;
^ permalink raw reply
* Re: [PATCH 00/48] Handling more corner cases in merge-recursive.c
From: Junio C Hamano @ 2011-08-04 0:20 UTC (permalink / raw)
To: Elijah Newren; +Cc: git, jgfouca
In-Reply-To: <1307518278-23814-1-git-send-email-newren@gmail.com>
Unfortunately I seem to have found a regression that manifests in the real
life.
When this series is merged to 'next', it mismerges a trivial renamed path.
A sample commit to reproduce is 2d11f21c3, which is a merge between
28b9264dd6 and 5b42477b59. Check out the former and try to merge in the
latter.
The merge base of these two commits is 2cfe8a68ccb (no criss-cross).
One branch (current one, 28b9264dd6) does not have that path, but it does
have t/t4037-whitespace-status.sh:
$ git ls-tree 28b9264dd6 t/t4037-whitespace-status.sh
100755 blob 3c728a3ebf9ce52e5c24c81525d5cb749cfb2957 t/t4037-whitespace-status.sh
What happened to that path on the current branch is this:
$ git log -m -M --raw --pretty=short 2cfe8a68ccb..28b9264dd6 -- \
t/t40{37,40}-whitespace-status.sh
commit af7b41c923677ff9291bab56ec7069922e37453b
Author: Jeff King <peff@peff.net>
diff_tree: disable QUICK optimization with diff filter
:100755 100755 abc4934... 3c728a3... M t/t4037-whitespace-status.sh
In other words, we had t4037, and we have t4037 but we updated its
contents from abc4934 to 3c728a3.
Running "log -m -M --raw --pretty=short 2cfe8a68ccb..5b42477b59" shows
that the merged branch (5b42477b59) has renamed t4037 to t4040 at
0e098b6d:
commit 0e098b6d79fbcab763874f2b6fde5aa82144d150
Author: Johannes Sixt <j6t@kdbg.org>
Make test case number unique
:100755 100755 a30b03b... a30b03b... R100 t/t4037-whitespace-status.sh t/t4040-wh..
This commit is on a side-branch that has not been merged at the merge base
2cfe8a68ccb; its contents a30b03b is older than what 2cfe8a68ccb has, and
was updated by 2cfe8a68ccb to abc4934.
Another merge after this commit updated it at 7d0cf357:
commit 7d0cf357a31cc8a442342696788d776265482ce9 (from 98b256bd...)
Merge: 98b256b 2cfe8a6
Author: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/maint-diff-q-filter'
:100755 100755 a30b03b... abc4934... M t/t4040-whitespace-status.sh
This abc4934 is the same contents as the merge base had at t4037.
So this is an "our side kept t4037 and updated its contents from abc4934
to 3c728a3, while the other side renamed t4037 to t4040 and kept its
contents as abc4934". We should merge this as structural change "our side
left it untouched, their side renamed, so take the rename without
conflict" and content level change "our side updated but their side left
it untouched, so take our modification without conflict".
In other words, in the result, we should have 3c728a3 at t4040, and that
indeed is what we got in the recorded history:
$ git ls-tree 2d11f21c3 -- t/t4040-whitespace-status.sh
100755 blob 3c728a3ebf9ce52e5c24c81525d5cb749cfb2957 t/t4040-whitespace-status.sh
However, the merge retried with this series cleanly resolves the path, but
with wrong contents:
$ git checkout 28b9264dd6
$ git merge 5b42477b59
$ git ls-files -s t/t4040-whitespace-status.sh
100755 abc49348b196cf0fec232b6f2399356e4fe324d5 0 t/t4040-whitespace-status.sh
Correct answer should be:
$ git ls-files -s t/t4040-whitespace-status.sh
100755 3c728a3ebf9ce52e5c24c81525d5cb749cfb2957 0 t/t4040-whitespace-status.sh
I am rewinding today's integration of 'next' to unmerge this topic
now. :-(...
^ permalink raw reply
* What's cooking in git.git (Aug 2011, #01; Wed, 3)
From: Junio C Hamano @ 2011-08-04 0:32 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
There are a few 'fixup!' commits queued in topics still in 'pu', so that
authors have a choice to just say "that fix looks good, squash it in!"
instead of going through an extra round.
I should start making noises about the feature freeze by now, but with a
vacation week in the US early in July, my half-absense during OSCON last
week, and just because it is summer in general, this round is going slower
than planned. Let's shoot for the feature freeze in two weeks and decide
which stragglers to postpone to the next round.
--------------------------------------------------
[New Topics]
* ac/describe-dirty-refresh (2011-08-01) 2 commits
- fixup! describe: Refresh the index when run with --dirty
- describe: Refresh the index when run with --dirty
* cb/maint-ls-files-error-report (2011-08-01) 2 commits
- squash! ls-files: fix pathspec display on error
- ls-files: fix pathspec display on error
* ef/ipv4-connect-error-report (2011-08-01) 2 commits
(merged to 'next' on 2011-08-03 at ea4842b)
+ connect: only log if all attempts failed (ipv4)
+ Merge branch 'maint' into ef/ipv4-connect-error-report
* jl/submodule-status-summary-doc (2011-08-01) 1 commit
(merged to 'next' on 2011-08-03 at 88f97a9)
+ Documentation/submodule: add command references and update options
* js/bisect-no-checkout (2011-08-03) 9 commits
- bisect: add documentation for --no-checkout option.
- fixup! bisect: add tests for the --no-checkout option
- bisect: add tests for the --no-checkout option.
- fixup! bisect: introduce --no-checkout support into porcelain
- bisect: introduce --no-checkout support into porcelain.
- bisect: introduce support for --no-checkout option.
- bisect: add tests to document expected behaviour in presence of broken trees.
- bisect: use && to connect statements that are deferred with eval.
- bisect: move argument parsing before state modification.
Getting there; I have a couple of trivial fix-ups queued there, though.
* ms/reflog-show-is-default (2011-08-01) 1 commit
(merged to 'next' on 2011-08-03 at ae9cf6f)
+ reflog: actually default to subcommand 'show'
* oa/pull-reflog (2011-08-01) 1 commit
(merged to 'next' on 2011-08-03 at faeff94)
+ pull: remove extra space from reflog message
* rs/grep-function-context (2011-08-01) 2 commits
- grep: long context options
- grep: add option to show whole function as context
Will merge to "next".
* cb/partial-commit-relative-pathspec (2011-08-02) 1 commit
(merged to 'next' on 2011-08-03 at 6918f69)
+ commit: allow partial commits with relative paths
* mh/check-attr-relative (2011-08-02) 7 commits
- fixup! builtin/check-attr.c and test-path-utils.c
- test-path-utils: Add subcommand "prefix_path"
- test-path-utils: Add subcommand "absolute_path"
- git-check-attr: Normalize paths
- git-check-attr: Demonstrate problems with relative paths
- git-check-attr: Demonstrate problems with unnormalized paths
- git-check-attr: test that no output is written to stderr
(this branch uses mh/check-attr-listing.)
--------------------------------------------------
[Graduated to "master"]
* jc/maint-reset-unmerged-path (2011-07-13) 1 commit
(merged to 'next' on 2011-07-19 at bbc2d54)
+ reset [<commit>] paths...: do not mishandle unmerged paths
(this branch is used by jc/diff-index-refactor.)
* jc/streaming-filter (2011-07-22) 1 commit
(merged to 'next' on 2011-07-22 at 2081cd7)
+ streaming: free git_istream upon closing
A large leak found and plugged.
* jk/clone-detached (2011-06-07) 4 commits
(merged to 'next' on 2011-07-25 at 013d7d0)
+ clone: always fetch remote HEAD
+ make copy_ref globally available
+ consider only branches in guess_remote_head
+ t: add tests for cloning remotes with detached HEAD
* sr/transport-helper-fix (2011-07-19) 21 commits
(merged to 'next' on 2011-07-19 at e1ef414)
+ transport-helper: die early on encountering deleted refs
+ transport-helper: implement marks location as capability
+ transport-helper: Use capname for refspec capability too
+ transport-helper: change import semantics
+ transport-helper: update ref status after push with export
+ transport-helper: use the new done feature where possible
+ transport-helper: check status code of finish_command
+ transport-helper: factor out push_update_refs_status
+ fast-export: support done feature
+ fast-import: introduce 'done' command
+ git-remote-testgit: fix error handling
+ git-remote-testgit: only push for non-local repositories
+ remote-curl: accept empty line as terminator
+ remote-helpers: export GIT_DIR variable to helpers
+ git_remote_helpers: push all refs during a non-local export
+ transport-helper: don't feed bogus refs to export push
+ git-remote-testgit: import non-HEAD refs
+ t5800: document some non-functional parts of remote helpers
+ t5800: use skip_all instead of prereq
+ t5800: factor out some ref tests
+ transport-helper: fix minor leak in push_refs_with_export
(this branch is used by sr/transport-helper-fix-rfc.)
* vi/make-test-vector-less-specific (2011-07-19) 1 commit
(merged to 'next' on 2011-07-25 at 1973192)
+ tests: cleanup binary test vector files
--------------------------------------------------
[Stalled]
* nk/branch-v-abbrev (2011-07-01) 1 commit
- branch -v: honor core.abbrev
Perhaps needs an updated commit log message?
* di/fast-import-doc (2011-07-13) 2 commits
- doc/fast-import: document feature import-marks-if-exists
- doc/fast-import: clarify notemodify command
Comments from fast-import folks?
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-07-14) 7 commits
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
--------------------------------------------------
[Cooking]
* cb/maint-exec-error-report (2011-08-01) 2 commits
- notice error exit from pager
- error_routine: use parent's stderr if exec fails
* cb/maint-quiet-push (2011-07-31) 1 commit
(merged to 'next' on 2011-08-01 at 87df938)
+ propagate --quiet to send-pack/receive-pack
* jl/submodule-update-quiet (2011-07-28) 1 commit
(merged to 'next' on 2011-08-01 at c611587)
+ submodule: update and add must honor --quiet flag
* jn/gitweb-config-list-case (2011-07-31) 1 commit
(merged to 'next' on 2011-08-01 at 9268738)
+ gitweb: Git config keys are case insensitive, make config search too
* jn/gitweb-system-config (2011-07-24) 1 commit
(merged to 'next' on 2011-08-01 at 4941e45)
+ gitweb: Introduce common system-wide settings for convenience
* js/ls-tree-error (2011-07-25) 2 commits
(merged to 'next' on 2011-08-01 at 61bae55)
+ Ensure git ls-tree exits with a non-zero exit code if read_tree_recursive fails.
+ Add a test to check that git ls-tree sets non-zero exit code on error.
* jc/merge-reword (2011-05-25) 2 commits
- merge: mark the final "Merge made by..." message for l10n
- merge: reword the final message
Probably the topmost commit should be dropped.
* jk/reset-reflog-message-fix (2011-07-22) 1 commit
(merged to 'next' on 2011-08-01 at 6c88837)
+ reset: give better reflog messages
* jk/add-i-hunk-filter (2011-07-27) 5 commits
- add--interactive: add option to autosplit hunks
- add--interactive: allow negatation of hunk filters
- add--interactive: allow hunk filtering on command line
- add--interactive: factor out regex error handling
- add--interactive: refactor patch mode argument processing
* mh/check-attr-listing (2011-08-02) 19 commits
- Rename struct git_attr_check to git_attr_value
- git-check-attr: Fix command-line handling to match docs
- git-check-attr: Drive two tests using the same raw data
- git-check-attr: Add an --all option to show all attributes
- git-check-attr: Error out if no pathnames are specified
- git-check-attr: Process command-line args more systematically
- git-check-attr: Handle each error separately
- git-check-attr: Extract a function error_with_usage()
- git-check-attr: Introduce a new variable
- git-check-attr: Extract a function output_attr()
- Allow querying all attributes on a file
- git-check-attr: Use git_attr_name()
- Provide access to the name attribute of git_attr
- git-check-attr: Add tests of command-line parsing
- git-check-attr: Add missing "&&"
- Disallow the empty string as an attribute name
- Remove anachronism from comment
- doc: Correct git_attr() calls in example code
- doc: Add a link from gitattributes(5) to git-check-attr(1)
(this branch is used by mh/check-attr-relative.)
Except for a few nits, this seems mostly ready.
* jc/diff-index-refactor (2011-07-13) 2 commits
(merged to 'next' on 2011-08-01 at 98d8b08)
+ diff-lib: refactor run_diff_index() and do_diff_cache()
+ diff-lib: simplify do_diff_cache()
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
* jk/http-auth-keyring (2011-08-03) 13 commits
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories.
* tc/minix (2011-07-20) 1 commit
(merged to 'next' on 2011-07-25 at 36ad29f)
+ Makefile: add Minix configuration options.
* jc/pack-order-tweak (2011-07-08) 2 commits
(merged to 'next' on 2011-07-25 at 1460c31)
+ pack-objects: optimize "recency order"
+ core: log offset pack data accesses happened
* js/ref-namespaces (2011-07-21) 5 commits
(merged to 'next' on 2011-07-25 at 5b7dcfe)
+ ref namespaces: tests
+ ref namespaces: documentation
+ ref namespaces: Support remote repositories via upload-pack and receive-pack
+ ref namespaces: infrastructure
+ Fix prefix handling in ref iteration functions
* rc/histogram-diff (2011-08-03) 13 commits
- fixup! xdiff/xhistogram: rework handling of recursed results
- xdiff/xhistogram: drop need for additional variable
- xdiff/xhistogram: rely on xdl_trim_ends()
- xdiff/xhistogram: rework handling of recursed results
- xdiff: do away with xdl_mmfile_next()
(merged to 'next' on 2011-08-03 at f9e2328)
+ Make test number unique
(merged to 'next' on 2011-07-25 at 3351028)
+ xdiff/xprepare: use a smaller sample size for histogram diff
+ xdiff/xprepare: skip classification
+ teach --histogram to diff
+ t4033-diff-patience: factor out tests
+ xdiff/xpatience: factor out fall-back-diff function
+ xdiff/xprepare: refactor abort cleanups
+ xdiff/xprepare: use memset()
* rr/revert-cherry-pick-continue (2011-08-01) 18 commits
- revert: Propagate errors upwards from do_pick_commit
- revert: Introduce --continue to continue the operation
- revert: Don't implicitly stomp pending sequencer operation
- revert: Remove sequencer state when no commits are pending
- reset: Make reset remove the sequencer state
- revert: Introduce --reset to remove sequencer state
- revert: Make pick_commits functionally act on a commit list
- revert: Save command-line options for continuing operation
- revert: Save data for continuing after conflict resolution
- revert: Don't create invalid replay_opts in parse_args
- revert: Separate cmdline parsing from functional code
- revert: Introduce struct to keep command-line options
- revert: Eliminate global "commit" variable
- revert: Rename no_replay to record_origin
- revert: Don't check lone argument in get_encoding
- revert: Simplify and inline add_message_to_msg
- config: Introduce functions to write non-standard file
- advice: Introduce error_resolve_conflict
Rerolled (v5) and looked reasonably clean.
Will merge to "next".
* en/merge-recursive (2011-07-14) 50 commits
- fixup! Do not assume that qsort is stable
- t3030: fix accidental success in symlink rename
- merge-recursive: Fix working copy handling for rename/rename/add/add
- merge-recursive: add handling for rename/rename/add-dest/add-dest
- merge-recursive: Have conflict_rename_delete reuse modify/delete code
- merge-recursive: Make modify/delete handling code reusable
- merge-recursive: Consider modifications in rename/rename(2to1) conflicts
- merge-recursive: Create function for merging with branchname:file markers
- merge-recursive: Record more data needed for merging with dual renames
- merge-recursive: Defer rename/rename(2to1) handling until process_entry
- merge-recursive: Small cleanups for conflict_rename_rename_1to2
- merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
- merge-recursive: Introduce a merge_file convenience function
- merge-recursive: Fix modify/delete resolution in the recursive case
- merge-recursive: Provide more info in conflict markers with file renames
- merge-recursive: Cleanup and consolidation of rename_conflict_info
- merge-recursive: Consolidate process_entry() and process_df_entry()
- merge-recursive: Improve handling of rename target vs. directory addition
- merge-recursive: Add comments about handling rename/add-source cases
- merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
- merge-recursive: Fix deletion of untracked file in rename/delete conflicts
- merge-recursive: When we detect we can skip an update, actually skip it
- merge-recursive: Split update_stages_and_entry; only update stages at end
- merge-recursive: Consolidate different update_stages functions
- merge-recursive: Allow make_room_for_path() to remove D/F entries
- merge-recursive: Split was_tracked() out of would_lose_untracked()
- merge-recursive: Save D/F conflict filenames instead of unlinking them
- merge-recursive: Fix code checking for D/F conflicts still being present
- merge-recursive: Fix sorting order and directory change assumptions
- merge-recursive: Fix recursive case with D/F conflict via add/add conflict
- merge-recursive: Avoid working directory changes during recursive case
- merge-recursive: Remember to free generated unique path names
- merge-recursive: Mark some diff_filespec struct arguments const
- merge-recursive: Correct a comment
- merge-recursive: Make BUG message more legible by adding a newline
- t6022: Add testcase for merging a renamed file with a simple change
- t6022: New tests checking for unnecessary updates of files
- t6022: Remove unnecessary untracked files to make test cleaner
- t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
- t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
- t6036: tests for criss-cross merges with various directory/file conflicts
- t6036: criss-cross with weird content can fool git into clean merge
- t6036: Add differently resolved modify/delete conflict in criss-cross test
- t6042: Ensure rename/rename conflicts leave index and workdir in sane state
- t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
- t6042: Add tests for content issues with modify/rename/directory conflicts
- t6042: Add a testcase where undetected rename causes silent file deletion
- t6042: Add a pair of cases where undetected renames cause issues
- t6042: Add failing testcase for rename/modify/add-source conflict
- t6042: Add a testcase where git deletes an untracked file
The tip one should be squashed somewhere. I wanted to push this out in
'next' today, but this seems to regress a rather trivial renaming merge,
so I had to rewind and rebuild 'next' before pushing it out.
^ permalink raw reply
* Re: [PATCH v16 5/7] bisect: introduce --no-checkout support into porcelain.
From: Junio C Hamano @ 2011-08-04 0:32 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, chriscool, j6t, jnareb, jrnieder
In-Reply-To: <1312408626-8600-6-git-send-email-jon.seymour@gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
> +bisect_head()
> +{
> + if test -f "$GIT_DIR/BISECT_HEAD"; then
> + echo BISECT_HEAD;
> + else
if test -f ...
then
echo BISECT_HEAD
else
> + --no-checkout)
> + mode=--no-checkout;
You seem to be very fond of extraneous semicolons.
Also I very much prefer to write "then" on its own line, indented at the
same level as "if". Consistently doing so will make your if statement a
lot easier to read when some of them need to have multi-line conditionals.
^ permalink raw reply
* Re: [PATCH v16 6/7] bisect: add tests for the --no-checkout option.
From: Junio C Hamano @ 2011-08-04 0:43 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, chriscool, j6t, jnareb, jrnieder
In-Reply-To: <1312408626-8600-7-git-send-email-jon.seymour@gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
> @@ -616,6 +628,14 @@ cat > expected.missing-tree.default <<EOF
> fatal: unable to read tree 39f7e61a724187ab767d2e08442d9b6b9dab587d
> EOF
>
> +check_same()
> +{
> + echo "Checking $1 is the same as $2" &&
> + git rev-parse "$1" > expected.same &&
> + git rev-parse "$2" > expected.actual &&
> + test_cmp expected.same expected.actual
Please indent with tabs; I know some existing lines in this file needs
fixing in a separate patch, but we do not have to make it worse.
> +test_expect_success 'bisect: demonstrate identification of damage boundary' "
> + git bisect reset &&
> + git checkout broken &&
> + git bisect start broken master --no-checkout &&
> + git bisect run sh -c '
> + GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
I have a suspicion that the dq around the format=%(...) here does not do
what you seem to think; doesn't it just step outside of the dq context of
the second parameter of the outermost test_expect_success? Wouldn't your
shell see
git for-each-ref --format=%(objectname)
without dq and barf on () as a consequence?
^ permalink raw reply
* Re: git-archive's wrong documentation: really write pax rather than tar
From: Jeff King @ 2011-08-04 1:41 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: git, rene.scharfe
In-Reply-To: <1312409879.97173.YahooMailClassic@web29501.mail.ird.yahoo.com>
On Wed, Aug 03, 2011 at 11:17:59PM +0100, Hin-Tak Leung wrote:
> The summary of the problem is that, git-archive's "--format=tar"
> option really write the pax format most of the time, and some
> cross-platform archive extraction library (rather than the
> all-powerful GNU tar) really does not think that's the tar format and
> bail out.
Out of curiosity, what is the library? Putting pax headers into ustar
format has been standardized in POSIX since 2001.
> Is it possible to (1) add a warning in the man-page, or (2) actually
> fix the problem in git-archive ( archive-tar.c ) to generate more
> conformant archive packages?
That header contains useful information (the commit id from which the
archive was generated). And there is a way to turn it off: give a tree
id instead of a commit id. There is an example in the git-archive
manpage that does exactly this already. Look for the example mentioning
"pax header" here:
http://www.kernel.org/pub/software/scm/git/docs/git-archive.html
It might be a bit more obvious to find if we actually had a
--no-pax-header option, though.
-Peff
^ permalink raw reply
* Re: [PATCH 00/48] Handling more corner cases in merge-recursive.c
From: Junio C Hamano @ 2011-08-04 1:48 UTC (permalink / raw)
To: Elijah Newren; +Cc: git, jgfouca
In-Reply-To: <7v4o1y81sv.fsf@alter.siamese.dyndns.org>
A very simple reproduction recipe.
-- >8 --
#!/bin/sh
mkdir en && cd en || exit
git init
echo 1 >one
git add one
git commit -m 'origin'
git checkout -b side
git mv one two
git commit -m 'side renames one to two'
git checkout master
echo 2 >one
git add one
git commit -m 'master updates one'
git checkout HEAD^0
git merge side
-- 8< --
Tonight's "pu" fails like this:
$ git merge side
error: addinfo_cache failed for path 'two'
Merge made by the 'recursive' strategy.
one | 1 -
two | 1 +
2 files changed, 1 insertions(+), 1 deletions(-)
delete mode 100644 one
create mode 100644 two
^ permalink raw reply
* Re: Why isn't there a hook for all operations that update the working tree?
From: Neal Kreitzinger @ 2011-08-04 1:56 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List
In-Reply-To: <CACBZZX7dJhGT0H8JZRbQ_t9mNnJocaktYAXgMSihfLBuFmL3nw@mail.gmail.com>
On 7/28/2011 6:59 AM, Ævar Arnfjörð Bjarmason wrote:
> I have a repository where I'd like to run a program every time the
> working tree is updated. githooks(5) specifies that you can use
> post-{checkout,merge} hooks to hook into those two operations.
>
> However that doesn't catch e.g. "git reset --hard". Is there any
> reason beside omission that there isn't a post-reset hook? Or hooks
> for any other thing (most of which surely slip my mind) which can
> update the working tree?
You could create an alias like "git resetr" that runs the script.
v/r,
neal
^ permalink raw reply
* Re: git-archive's wrong documentation: really write pax rather than tar
From: Junio C Hamano @ 2011-08-04 1:56 UTC (permalink / raw)
To: Jeff King; +Cc: Hin-Tak Leung, git, rene.scharfe
In-Reply-To: <20110804014143.GA32579@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It might be a bit more obvious to find if we actually had a
> --no-pax-header option, though.
Yeah, we would need to make sure that --no-pack-header causes a barf
for other backends, though. "struct archiver_args" right now seems to have
compression_level but I think it should just have "const char **" that is
interpreted by backends.
^ permalink raw reply
* Re: git-archive's wrong documentation: really write pax rather than tar
From: Jeff King @ 2011-08-04 2:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Hin-Tak Leung, git, rene.scharfe
In-Reply-To: <7v62me6ism.fsf@alter.siamese.dyndns.org>
On Wed, Aug 03, 2011 at 06:56:41PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > It might be a bit more obvious to find if we actually had a
> > --no-pax-header option, though.
>
> Yeah, we would need to make sure that --no-pack-header causes a barf
> for other backends, though. "struct archiver_args" right now seems to have
> compression_level but I think it should just have "const char **" that is
> interpreted by backends.
Actually, it is relevant for zip, too. The option should really be
called "--no-commit-id" or something similar. I don't think it's as big
a deal with zip (because there is no compatibility issue), but you may
want to omit the header for other reasons (e.g., because you know it
doesn't point to a commit that is public).
-Peff
^ permalink raw reply
* Re: Why isn't there a hook for all operations that update the working tree?
From: Junio C Hamano @ 2011-08-04 2:06 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List
In-Reply-To: <CACBZZX7dJhGT0H8JZRbQ_t9mNnJocaktYAXgMSihfLBuFmL3nw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> ... Is there any
> reason beside omission that there isn't a post-reset hook?
> Or hooks for any other thing ...
In principle, we historically tended to avoid hooks unless absolutely
necessary. Even having to check to find out no hook needs to be run is
considered wasted cycles.
http://thread.gmane.org/gmane.comp.version-control.git/79314/focus=79321
I'd especially rather not to see a hook on something as low level as
"reset". It would be too tempting to use "reset" itself inside a hook that
is run from the post-reset hook, and I do not want to complicate the code
even further to give callers to ask disabling the hook.
^ 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