From a947ab79d43353ba29633f6716659d605d4600bc Mon Sep 17 00:00:00 2001 From: "Michael S. Tsirkin" Date: Wed, 21 Mar 2007 10:37:36 +0200 Subject: [PATCH 01/21] fix typo in git-am manpage Fix typo in git-am manpage Signed-off-by: Michael S. Tsirkin Signed-off-by: Junio C Hamano --- Documentation/git-am.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 4fb1d8441..13a738986 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -70,7 +70,7 @@ default. You could use `--no-utf8` to override this. the patch. -C, -p:: - These flag are passed to the `git-apply` program that applies + These flags are passed to the `git-apply` program that applies the patch. --interactive:: From 1ce09dd6787c495986c75b37b07ba6bbf19b47da Mon Sep 17 00:00:00 2001 From: Brandon Casey Date: Mon, 19 Mar 2007 18:00:37 -0500 Subject: [PATCH 02/21] [PATCH] prefer "git COMMAND" over "git-COMMAND" in gitk Preferring git _space_ COMMAND over git _dash_ COMMAND allows the user to have only git and gitk in their path. e.g. when git and gitk are symbolic links in a personal bin directory to the real git and gitk. Signed-off-by: Paul Mackerras --- gitk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gitk b/gitk index 1cd2a8f52..db28d745d 100755 --- a/gitk +++ b/gitk @@ -1906,7 +1906,7 @@ proc do_file_hl {serial} { } else { set gdtargs [list "-S$highlight_files"] } - set cmd [concat | git-diff-tree -r -s --stdin $gdtargs] + set cmd [concat | git diff-tree -r -s --stdin $gdtargs] set filehighlight [open $cmd r+] fconfigure $filehighlight -blocking 0 fileevent $filehighlight readable readfhighlight @@ -1958,7 +1958,7 @@ proc readfhighlight {} { } if {[eof $filehighlight]} { # strange... - puts "oops, git-diff-tree died" + puts "oops, git diff-tree died" catch {close $filehighlight} unset filehighlight } From a1bf91e081de236af34bf8acd484881ce146fc93 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 22 Mar 2007 02:54:59 -0700 Subject: [PATCH 03/21] git-rebase: make 'rebase HEAD branch' work as expected. When you want to amend the commit message of 3 commits before the tip of the current branch, say 'master', A--B--C--D--E(master) it is sometimes handy to make your head detached at that commit with: $ git checkout HEAD~3 ;# check out B $ git commit --amend ;# without modifying contents... to create: .B'(HEAD) / A--B--C--D--E(master) and then rebase 'master' branch onto HEAD with this: $ git rebase HEAD master to result in: .B'-C'-D'-E(master=HEAD) / A--B--C--D--E However, the current code interprets HEAD after it switches to the branch 'master', which means the rebase will not do anything. You have to say something unwieldly like this instead: $ git rebase $(git rev-parse HEAD) master This fixes it by expanding the $onto commit name before switching to the target branch. Signed-off-by: Junio C Hamano --- git-rebase.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index b51d19d12..aadd580f8 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -265,6 +265,10 @@ upstream_name="$1" upstream=`git rev-parse --verify "${upstream_name}^0"` || die "invalid upstream $upstream_name" +# Make sure the branch to rebase onto is valid. +onto_name=${newbase-"$upstream_name"} +onto=$(git-rev-parse --verify "${onto_name}^0") || exit + # If a hook exists, give it a chance to interrupt if test -x "$GIT_DIR/hooks/pre-rebase" then @@ -291,10 +295,6 @@ case "$#" in esac branch=$(git-rev-parse --verify "${branch_name}^0") || exit -# Make sure the branch to rebase onto is valid. -onto_name=${newbase-"$upstream_name"} -onto=$(git-rev-parse --verify "${onto_name}^0") || exit - # Now we are rebasing commits $upstream..$branch on top of $onto # Check if we are already based on $onto, but this should be From 85295a52e683a24d8404c6989d8b8f134a0ea684 Mon Sep 17 00:00:00 2001 From: "Michael S. Tsirkin" Date: Thu, 22 Mar 2007 11:07:30 +0200 Subject: [PATCH 04/21] git-merge: Put FETCH_HEAD data in merge commit message This makes git-fetch && git-merge FETCH_HEAD produce the same merge message as git-pull . Signed-off-by: Michael S. Tsirkin Signed-off-by: Junio C Hamano --- git-merge.sh | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/git-merge.sh b/git-merge.sh index 8759c5a7e..fa4589173 100755 --- a/git-merge.sh +++ b/git-merge.sh @@ -108,6 +108,10 @@ merge_name () { git-show-ref -q --verify "refs/heads/$truname" 2>/dev/null then echo "$rh branch '$truname' (early part) of ." + elif test "$remote" = "FETCH_HEAD" -a -r "$GIT_DIR/FETCH_HEAD" + then + sed -e 's/ not-for-merge / /' -e 1q \ + "$GIT_DIR/FETCH_HEAD" else echo "$rh commit '$remote'" fi From 0a0d080bdc68d2bd4a1824b08123690c8065badb Mon Sep 17 00:00:00 2001 From: Andy Parkins Date: Tue, 20 Mar 2007 10:58:32 +0000 Subject: [PATCH 05/21] update-hook: abort early if the project description is unset It was annoying to always have the first email from a project be from the "Unnamed repository; edit this file to name it for gitweb project"; just because it's so easy to forget to set it. This patch checks to see if the description file is still default (or empty) and aborts if so - allowing you to fix the problem before sending out silly looking emails to every developer. Signed-off-by: Andy Parkins Signed-off-by: Junio C Hamano --- templates/hooks--update | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/templates/hooks--update b/templates/hooks--update index 8f6c4fea2..1a6077389 100644 --- a/templates/hooks--update +++ b/templates/hooks--update @@ -56,6 +56,12 @@ recipients=$(git-repo-config hooks.mailinglist) announcerecipients=$(git-repo-config hooks.announcelist) allowunannotated=$(git-repo-config --bool hooks.allowunannotated) +# check for no description +if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file to name it for gitweb" ]; then + echo "*** Project description file hasn't been set" >&2 + exit 1 +fi + # --- Check types newrev_type=$(git-cat-file -t $newrev) From 605fac8b5bd6d4a2ca817631e2c56ba2d0a1ed91 Mon Sep 17 00:00:00 2001 From: Nicolas Pitre Date: Wed, 21 Mar 2007 17:11:44 -0400 Subject: [PATCH 06/21] update HEAD reflog when branch pointed to by HEAD is directly modified The HEAD reflog is updated as well as the reflog for the branch pointed to by HEAD whenever it is referenced with "HEAD". There are some cases where a specific branch may be modified directly. In those cases, the HEAD reflog should be updated as well if it is a symref to that branch in order to be consistent. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano --- refs.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/refs.c b/refs.c index 9f1fb68d0..f471152bf 100644 --- a/refs.c +++ b/refs.c @@ -980,6 +980,27 @@ int write_ref_sha1(struct ref_lock *lock, unlock_ref(lock); return -1; } + if (strcmp(lock->orig_ref_name, "HEAD") != 0) { + /* + * Special hack: If a branch is updated directly and HEAD + * points to it (may happen on the remote side of a push + * for example) then logically the HEAD reflog should be + * updated too. + * A generic solution implies reverse symref information, + * but finding all symrefs pointing to the given branch + * would be rather costly for this rare event (the direct + * update of a branch) to be worth it. So let's cheat and + * check with HEAD only which should cover 99% of all usage + * scenarios (even 100% of the default ones). + */ + unsigned char head_sha1[20]; + int head_flag; + const char *head_ref; + head_ref = resolve_ref("HEAD", head_sha1, 1, &head_flag); + if (head_ref && (head_flag & REF_ISSYMREF) && + !strcmp(head_ref, lock->ref_name)) + log_ref_write("HEAD", lock->old_sha1, sha1, logmsg); + } if (commit_lock_file(lock->lk)) { error("Couldn't set %s", lock->ref_name); unlock_ref(lock); From 979ea5856cddace7223ddd715a448dbe49fcb290 Mon Sep 17 00:00:00 2001 From: Peter Eriksen Date: Wed, 21 Mar 2007 19:43:37 +0100 Subject: [PATCH 07/21] Documentation/pack-format.txt: Clear up description of types. Signed-off-by: Peter Eriksen Signed-off-by: Junio C Hamano --- Documentation/technical/pack-format.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index 0e1ffb242..9ce3c473a 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -21,11 +21,11 @@ GIT pack format which looks like this: (undeltified representation) - n-byte type and length (4-bit type, (n-1)*7+4-bit length) + n-byte type and length (3-bit type, (n-1)*7+4-bit length) compressed data (deltified representation) - n-byte type and length (4-bit type, (n-1)*7+4-bit length) + n-byte type and length (3-bit type, (n-1)*7+4-bit length) 20-byte base object name compressed delta data @@ -102,11 +102,13 @@ trailer | | packfile checksum | Pack file entry: <+ packed object header: - 1-byte type (upper 4-bit) + 1-byte size extension bit (MSB) + type (next 3 bit) size0 (lower 4-bit) n-byte sizeN (as long as MSB is set, each 7-bit) size0..sizeN form 4+7+7+..+7 bit integer, size0 - is the most significant part. + is the least significant part, and sizeN is the + most significant part. packed object data: If it is not DELTA, then deflated bytes (the size above is the size before compression). From cc96fd092a55a7a8685f0dee1e287ded70bc08b7 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 22 Mar 2007 17:32:51 -0700 Subject: [PATCH 08/21] git-apply: Do not free the wrong buffer when we convert the data for writeout When we write out the result of patch application, we sometimes need to munge the data (e.g. under core.autocrlf). After doing so, what we should free is the temporary buffer that holds the converted data returned from convert_to_working_tree(), not the original one. This patch also moves the call to open() up in the function, as the caller expects us to fail cheaply if leading directories need to be created (and then the caller creates them and calls us again). For that calling pattern, attempting conversion before opening the file adds unnecessary overhead. Acked-by: Linus Torvalds Signed-off-by: Junio C Hamano --- builtin-apply.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/builtin-apply.c b/builtin-apply.c index dfa171679..27a182bfa 100644 --- a/builtin-apply.c +++ b/builtin-apply.c @@ -2355,7 +2355,7 @@ static void add_index_file(const char *path, unsigned mode, void *buf, unsigned static int try_create_file(const char *path, unsigned int mode, const char *buf, unsigned long size) { - int fd; + int fd, converted; char *nbuf; unsigned long nsize; @@ -2364,17 +2364,18 @@ static int try_create_file(const char *path, unsigned int mode, const char *buf, * terminated. */ return symlink(buf, path); + + fd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666); + if (fd < 0) + return -1; + nsize = size; nbuf = (char *) buf; - if (convert_to_working_tree(path, &nbuf, &nsize)) { - free((char *) buf); + converted = convert_to_working_tree(path, &nbuf, &nsize); + if (converted) { buf = nbuf; size = nsize; } - - fd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666); - if (fd < 0) - return -1; while (size) { int written = xwrite(fd, buf, size); if (written < 0) @@ -2386,6 +2387,8 @@ static int try_create_file(const char *path, unsigned int mode, const char *buf, } if (close(fd) < 0) die("closing file %s: %s", path, strerror(errno)); + if (converted) + free(nbuf); return 0; } From 3007a78033fec09b97ff1ca816a2d23c292dd956 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Thu, 22 Mar 2007 21:05:28 -0400 Subject: [PATCH 09/21] t4118: be nice to non-GNU sed Elias Pipping: > I'm on a mac, hence /usr/bin/sed is not gnu sed, which makes > t4118 fail. Signed-off-by: Johannes Schindelin Ack'd-by: Elias Pipping Signed-off-by: Junio C Hamano --- t/t4118-apply-empty-context.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/t/t4118-apply-empty-context.sh b/t/t4118-apply-empty-context.sh index 690a18200..27cc6f2b8 100755 --- a/t/t4118-apply-empty-context.sh +++ b/t/t4118-apply-empty-context.sh @@ -23,7 +23,8 @@ test_expect_success setup ' cat file2 >file2.orig git add file1 file2 && sed -e "/^B/d" file1 && - sed -e "/^B/d" file2 && + sed -e "/^[BQ]/d" file2 && + echo Q | tr -d "\\012" >>file2 && cat file1 >file1.mods && cat file2 >file2.mods && git diff | From cc65343a8436896f4c78f5f802595870784df454 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Thu, 22 Mar 2007 17:18:08 +0100 Subject: [PATCH 10/21] Bisect: convert revs given to good and bad to commits MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Without this the rev could be (e.g.) a tag and then the condition to end the bisect might fail and you have to check the already known to be bad revision once more. Signed-off-by: Uwe Kleine-König Signed-off-by: Junio C Hamano --- git-bisect.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-bisect.sh b/git-bisect.sh index b1c3a6b1c..dbce0dfec 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -85,7 +85,7 @@ bisect_bad() { 0) rev=$(git-rev-parse --verify HEAD) ;; 1) - rev=$(git-rev-parse --verify "$1") ;; + rev=$(git-rev-parse --verify "$1^{commit}") ;; *) usage ;; esac || exit @@ -104,7 +104,7 @@ bisect_good() { esac for rev in $revs do - rev=$(git-rev-parse --verify "$rev") || exit + rev=$(git-rev-parse --verify "$rev^{commit}") || exit echo "$rev" >"$GIT_DIR/refs/bisect/good-$rev" echo "# good: "$(git-show-branch $rev) >>"$GIT_DIR/BISECT_LOG" echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG" From a17c4101003dbadc13d404a5dd5d106de1e57a3a Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Fri, 23 Mar 2007 08:49:59 +0100 Subject: [PATCH 11/21] Bisect: implement "git bisect run ..." to automatically bisect. This idea was suggested by Bill Lear (Message-ID: <17920.38942.364466.642979@lisa.zopyra.com>) and I think it is a very good one. This patch adds a new test file for "git bisect run", but there is currently only one basic test. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- Documentation/git-bisect.txt | 30 +++++++++++++++++++ git-bisect.sh | 54 ++++++++++++++++++++++++++++++++-- t/t6030-bisect-run.sh | 57 ++++++++++++++++++++++++++++++++++++ 3 files changed, 138 insertions(+), 3 deletions(-) create mode 100755 t/t6030-bisect-run.sh diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 16ec7269b..b7cd71538 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -22,6 +22,7 @@ depending on the subcommand: git bisect visualize git bisect replay git bisect log + git bisect run ... This command uses 'git-rev-list --bisect' option to help drive the binary search process to find which change introduced a bug, @@ -121,6 +122,35 @@ like this: $ git bisect start arch/i386 include/asm-i386 ------------ +If you have a script that can tell if the current +source code is good or bad, you can automatically bisect using: + +------------ +$ git bisect run my_script +------------ + +Note that the "run" script (`my_script` in the above example) +should exit with code 0 in +case the current source code is good and with a code between 1 and 127 +(included) in case the current source code is bad. + +Any other exit code (a program that does "exit(-1)" leaves $? = 255, +see exit(3) manual page, the value is chopped with "& 0377") will +abort the automatic bisect process. + +You may often find that during bisect you want to have near-constant +tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or +"revision that does not have this commit needs this patch applied to +work around other problem this bisection is not interested in") +applied to the revision being tested. + +To cope with such a situation, after the inner git-bisect finds the +next revision to test, with the "run" script, you can apply that tweak +before compiling, run the real test, and after the test decides if the +revision (possibly with the needed tweaks) passed the test, rewind the +tree to the pristine state. Finally the "run" script can exit with +the status of the real test to let "git bisect run" command loop to +know the outcome. Author ------ diff --git a/git-bisect.sh b/git-bisect.sh index dbce0dfec..3043f6551 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -1,14 +1,15 @@ #!/bin/sh -USAGE='[start|bad|good|next|reset|visualize|replay|log]' +USAGE='[start|bad|good|next|reset|visualize|replay|log|run]' LONG_USAGE='git bisect start [] reset bisect state and start bisection. git bisect bad [] mark a known-bad revision. git bisect good [...] mark ... known-good revisions. git bisect next find next bisection to test and check it out. git bisect reset [] finish bisection search and go back to branch. git bisect visualize show bisect status in gitk. -git bisect replay replay bisection log -git bisect log show bisect log.' +git bisect replay replay bisection log. +git bisect log show bisect log. +git bisect run ... use ... to automatically bisect.' . git-sh-setup require_work_tree @@ -185,6 +186,7 @@ bisect_reset() { rm -f "$GIT_DIR/refs/heads/bisect" "$GIT_DIR/head-name" rm -f "$GIT_DIR/BISECT_LOG" rm -f "$GIT_DIR/BISECT_NAMES" + rm -f "$GIT_DIR/BISECT_RUN" fi } @@ -220,6 +222,50 @@ bisect_replay () { bisect_auto_next } +bisect_run () { + while true + do + echo "running $@" + "$@" + res=$? + + # Check for really bad run error. + if [ $res -lt 0 -o $res -ge 128 ]; then + echo >&2 "bisect run failed:" + echo >&2 "exit code $res from '$@' is < 0 or >= 128" + exit $res + fi + + # Use "bisect_good" or "bisect_bad" + # depending on run success or failure. + if [ $res -gt 0 ]; then + next_bisect='bisect_bad' + else + next_bisect='bisect_good' + fi + + # We have to use a subshell because bisect_good or + # bisect_bad functions can exit. + ( $next_bisect > "$GIT_DIR/BISECT_RUN" ) + res=$? + + cat "$GIT_DIR/BISECT_RUN" + + if [ $res -ne 0 ]; then + echo >&2 "bisect run failed:" + echo >&2 "$next_bisect exited with error code $res" + exit $res + fi + + if grep "is first bad commit" "$GIT_DIR/BISECT_RUN" > /dev/null; then + echo "bisect run success" + exit 0; + fi + + done +} + + case "$#" in 0) usage ;; @@ -244,6 +290,8 @@ case "$#" in bisect_replay "$@" ;; log) cat "$GIT_DIR/BISECT_LOG" ;; + run) + bisect_run "$@" ;; *) usage ;; esac diff --git a/t/t6030-bisect-run.sh b/t/t6030-bisect-run.sh new file mode 100755 index 000000000..39c72283b --- /dev/null +++ b/t/t6030-bisect-run.sh @@ -0,0 +1,57 @@ +#!/bin/sh +# +# Copyright (c) 2007 Christian Couder +# +test_description='Tests git-bisect run functionality' + +. ./test-lib.sh + +add_line_into_file() +{ + _line=$1 + _file=$2 + + if [ -f "$_file" ]; then + echo "$_line" >> $_file || return $? + MSG="Add <$_line> into <$_file>." + else + echo "$_line" > $_file || return $? + git add $_file || return $? + MSG="Create file <$_file> with <$_line> inside." + fi + + git-commit -m "$MSG" $_file +} + +HASH1= +HASH3= +HASH4= + +test_expect_success \ + 'set up basic repo with 1 file (hello) and 4 commits' \ + 'add_line_into_file "1: Hello World" hello && + add_line_into_file "2: A new day for git" hello && + add_line_into_file "3: Another new day for git" hello && + add_line_into_file "4: Ciao for now" hello && + HASH1=$(git rev-list HEAD | tail -1) && + HASH3=$(git rev-list HEAD | head -2 | tail -1) && + HASH4=$(git rev-list HEAD | head -1)' + +# We want to automatically find the commit that +# introduced "Another" into hello. +test_expect_success \ + 'git bisect run simple case' \ + 'echo "#!/bin/sh" > test_script.sh && + echo "grep Another hello > /dev/null" >> test_script.sh && + echo "test \$? -ne 0" >> test_script.sh && + chmod +x test_script.sh && + git bisect start && + git bisect good $HASH1 && + git bisect bad $HASH4 && + git bisect run ./test_script.sh > my_bisect_log.txt && + grep "$HASH3 is first bad commit" my_bisect_log.txt' + +# +# +test_done + From abba9dbbf450d4037a5e2054250f197169ac63eb Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 23 Mar 2007 02:37:19 -0700 Subject: [PATCH 12/21] checkout: report where the new HEAD is upon detaching HEAD After "git reset" moves the HEAD around, it reports which commit you are on, which gives the user a warm fuzzy feeling of assurance. Give the same assurance from git-checkout when moving the detached HEAD around. Signed-off-by: Junio C Hamano --- git-checkout.sh | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/git-checkout.sh b/git-checkout.sh index 3c9b1bb05..a7390e808 100755 --- a/git-checkout.sh +++ b/git-checkout.sh @@ -163,6 +163,13 @@ cd_to_toplevel detached= detach_warn= +describe_detached_head () { + test -n "$quiet" || { + printf >&2 "$1 " + GIT_PAGER= git log >&2 -1 --pretty=oneline --abbrev-commit "$2" + } +} + if test -z "$branch$newbranch" && test "$new" != "$old" then detached="$new" @@ -173,9 +180,9 @@ If you want to create a new branch from this checkout, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b " fi -elif test -z "$oldbranch" && test -z "$quiet" +elif test -z "$oldbranch" then - echo >&2 "Previous HEAD position was $old" + describe_detached_head 'Previous HEAD position was' "$old" fi if [ "X$old" = X ] @@ -275,6 +282,7 @@ if [ "$?" -eq 0 ]; then then echo >&2 "$detach_warn" fi + describe_detached_head 'HEAD is now at' HEAD fi rm -f "$GIT_DIR/MERGE_HEAD" else From 673e58389fd8531ee1ac191350c2c10b1656486e Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 23 Mar 2007 13:15:21 -0700 Subject: [PATCH 13/21] git-bisect: typofix The branch you are on while bisecting is always "bisect", and checking for "refs/heads/bisect*" is wrong. Only check if it is exactly "refs/heads/bisect". Signed-off-by: Junio C Hamano --- git-bisect.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-bisect.sh b/git-bisect.sh index 3043f6551..8eaea7cd1 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -50,7 +50,7 @@ bisect_start() { head=$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD) || die "Bad HEAD - I need a symbolic ref" case "$head" in - refs/heads/bisect*) + refs/heads/bisect) if [ -s "$GIT_DIR/head-name" ]; then branch=`cat "$GIT_DIR/head-name"` else From 12cb8137332e21957195c3af2923c03a8aad5b5a Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 23 Mar 2007 13:24:22 -0700 Subject: [PATCH 14/21] git-bisect.sh: properly dq $GIT_DIR Otherwise you would be in trouble if your GIT_DIR has IFS letters in it. Signed-off-by: Junio C Hamano --- git-bisect.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-bisect.sh b/git-bisect.sh index 8eaea7cd1..936b4a4b8 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -141,7 +141,7 @@ bisect_next() { bad=$(git-rev-parse --verify refs/bisect/bad) && good=$(git-rev-parse --sq --revs-only --not \ $(cd "$GIT_DIR" && ls refs/bisect/good-*)) && - rev=$(eval "git-rev-list --bisect $good $bad -- $(cat $GIT_DIR/BISECT_NAMES)") || exit + rev=$(eval "git-rev-list --bisect $good $bad -- $(cat "$GIT_DIR/BISECT_NAMES")") || exit if [ -z "$rev" ]; then echo "$bad was both good and bad" exit 1 From f9308a182e220c97cdbf90ee8de2ce21980cb7e9 Mon Sep 17 00:00:00 2001 From: Jakub Narebski Date: Fri, 23 Mar 2007 21:04:31 +0100 Subject: [PATCH 15/21] gitweb: Fix "next" link in commit view Fix copy'n'paste error in commit c9d193df which caused that "next" link for merge commits in "commit" view (merge: _commit_ _commit_ ...) was to "commitdiff" view instead of being to "commit" view. Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano --- gitweb/gitweb.perl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 653ca3cc6..ea39d7e98 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -3719,7 +3719,7 @@ sub git_commit { $formats_nav .= '(merge: ' . join(' ', map { - $cgi->a({-href => href(action=>"commitdiff", + $cgi->a({-href => href(action=>"commit", hash=>$_)}, esc_html(substr($_, 0, 7))); } @$parents ) . From a4e9d71edb5f87b4dae57b8a474124451e397e6c Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 23 Mar 2007 13:34:49 -0700 Subject: [PATCH 16/21] Fix path-limited "rev-list --bisect" termination condition. In a path-limited bisection, when the $bad commit is not changing the limited path, and the number of suspects is 1, the code miscounted and returned $bad from find_bisection(), which is not marked with TREECHANGE. This is of course filtered by the output routine, resulting in an empty output, in turn causing git-bisect driver to say "$bad was both good and bad". Illustration. Suppose you have these four commits, and only C changes path P. You know D is bad and A is good. A---B---C*--D git-bisect driver runs this to find a bisection point: $ git rev-list --bisect A..D -- P which calls find_bisection() with B, C and D. The set of commits that is given to this function is the same set of commits as rev-list without --bisect option and pathspec returns. Among them, only C is marked with TREECHANGE. Let's call the set of commits given to find_bisection() that are marked with TREECHANGE (or all of them if no path limiter is in effect) "the bisect set". In the above example, the size of the bisect set is 1 (contains only "C"). For each commit in its input, find_bisection() computes the number of commits it can reach in the bisect set. For a commit in the bisect set, this number includes itself, so the number is 1 or more. This number is called "depth", and computed by count_distance() function. When you have a bisect set of N commits, and a commit has depth D, how good is your bisection if you returned that commit? How good this bisection is can be measured by how many commits are effectively tested "together" by testing one commit. Currently you have (N-1) untested commits (the tip of the bisect set, although it is included in the bisect set, is already known to be bad). If the commit with depth D turns out to be bad, then your next bisect set will have D commits and you will have (D-1) untested commits left, which means you tested (N-1)-(D-1) = (N-D) commits with this bisection. If it turns out to be good, then your next bisect set will have (N-D) commits, and you will have (N-D-1) untested commits left, which means you tested (N-1)-(N-D-1) = D commits with this bisection. Therefore, the goodness of this bisection is is min(N-D, D), and find_bisection() function tries to find a commit that maximizes this, by initializing "closest" variable to 0 and whenever a commit with the goodness that is larger than the current "closest" is found, that commit and its goodness are remembered by updating "closest" variable. The "the commit with the best goodness so far" is kept in "best" variable, and is initialized to a commit that happens to be at the beginning of the list of commits given to this function (which may or may not be in the bisect set when path-limit is in use). However, when N is 1, then the sole tree-changing commit has depth of 1, and min(N-D, D) evaluates to 0. This is not larger than the initial value of "closest", and the "so far the best one" commit is never replaced in the loop. When path-limit is not in use, this is not a problem, as any commit in the input set is tree-changing. But when path-limit is in use, and when the starting "bad" commit does not change the specified path, it is not correct to return it. Signed-off-by: Junio C Hamano --- builtin-rev-list.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin-rev-list.c b/builtin-rev-list.c index c2db5a5b0..51858e323 100644 --- a/builtin-rev-list.c +++ b/builtin-rev-list.c @@ -180,7 +180,7 @@ static struct commit_list *find_bisection(struct commit_list *list) nr++; p = p->next; } - closest = 0; + closest = -1; best = list; for (p = list; p; p = p->next) { From 7891a2811dc7cae375e34c9f4fa6c8ecaef0f6d7 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Sat, 24 Mar 2007 06:29:58 +0100 Subject: [PATCH 17/21] Documentation: bisect: reformat some paragraphs. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- Documentation/git-bisect.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index b7cd71538..a77fbe848 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -122,17 +122,17 @@ like this: $ git bisect start arch/i386 include/asm-i386 ------------ -If you have a script that can tell if the current -source code is good or bad, you can automatically bisect using: +If you have a script that can tell if the current source code is good +or bad, you can automatically bisect using: ------------ $ git bisect run my_script ------------ -Note that the "run" script (`my_script` in the above example) -should exit with code 0 in -case the current source code is good and with a code between 1 and 127 -(included) in case the current source code is bad. +Note that the "run" script (`my_script` in the above example) should +exit with code 0 in case the current source code is good and with a +code between 1 and 127 (included) in case the current source code is +bad. Any other exit code (a program that does "exit(-1)" leaves $? = 255, see exit(3) manual page, the value is chopped with "& 0377") will From cc070d1f797c7488ed479817d893ad78fc4dae2b Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Sat, 24 Mar 2007 06:31:16 +0100 Subject: [PATCH 18/21] Documentation: bisect: reword one paragraph. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- Documentation/git-bisect.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index a77fbe848..4bd468e66 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -134,9 +134,9 @@ exit with code 0 in case the current source code is good and with a code between 1 and 127 (included) in case the current source code is bad. -Any other exit code (a program that does "exit(-1)" leaves $? = 255, -see exit(3) manual page, the value is chopped with "& 0377") will -abort the automatic bisect process. +Any other exit code will abort the automatic bisect process. (A +program that does "exit(-1)" leaves $? = 255, see exit(3) manual page, +the value is chopped with "& 0377".) You may often find that during bisect you want to have near-constant tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or From fed820ad5662d8b6f11b5e7f788fa87afe1ad919 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Sat, 24 Mar 2007 06:31:49 +0100 Subject: [PATCH 19/21] Documentation: bisect: reformat more paragraphs. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- Documentation/git-bisect.txt | 73 +++++++++++++++++++----------------- 1 file changed, 39 insertions(+), 34 deletions(-) diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 4bd468e66..0bfb1525b 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -12,8 +12,8 @@ SYNOPSIS DESCRIPTION ----------- -The command takes various subcommands, and different options -depending on the subcommand: +The command takes various subcommands, and different options depending +on the subcommand: git bisect start [...] git bisect bad @@ -24,10 +24,9 @@ depending on the subcommand: git bisect log git bisect run ... -This command uses 'git-rev-list --bisect' option to help drive -the binary search process to find which change introduced a bug, -given an old "good" commit object name and a later "bad" commit -object name. +This command uses 'git-rev-list --bisect' option to help drive the +binary search process to find which change introduced a bug, given an +old "good" commit object name and a later "bad" commit object name. The way you use it is: @@ -38,15 +37,16 @@ $ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good ------------------------------------------------ -When you give at least one bad and one good versions, it will -bisect the revision tree and say something like: +When you give at least one bad and one good versions, it will bisect +the revision tree and say something like: ------------------------------------------------ Bisecting: 675 revisions left to test after this ------------------------------------------------ -and check out the state in the middle. Now, compile that kernel, and boot -it. Now, let's say that this booted kernel works fine, then just do +and check out the state in the middle. Now, compile that kernel, and +boot it. Now, let's say that this booted kernel works fine, then just +do ------------------------------------------------ $ git bisect good # this one is good @@ -58,12 +58,12 @@ which will now say Bisecting: 337 revisions left to test after this ------------------------------------------------ -and you continue along, compiling that one, testing it, and depending on -whether it is good or bad, you say "git bisect good" or "git bisect bad", -and ask for the next bisection. +and you continue along, compiling that one, testing it, and depending +on whether it is good or bad, you say "git bisect good" or "git bisect +bad", and ask for the next bisection. -Until you have no more left, and you'll have been left with the first bad -kernel rev in "refs/bisect/bad". +Until you have no more left, and you'll have been left with the first +bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a @@ -71,10 +71,10 @@ Oh, and then after you want to reset to the original head, do a $ git bisect reset ------------------------------------------------ -to get back to the master branch, instead of being in one of the bisection -branches ("git bisect start" will do that for you too, actually: it will -reset the bisection state, and before it does that it checks that you're -not using some old bisection branch). +to get back to the master branch, instead of being in one of the +bisection branches ("git bisect start" will do that for you too, +actually: it will reset the bisection state, and before it does that +it checks that you're not using some old bisection branch). During the bisection process, you can say @@ -84,9 +84,14 @@ $ git bisect visualize to see the currently remaining suspects in `gitk`. -The good/bad input is logged, and `git bisect -log` shows what you have done so far. You can truncate its -output somewhere and save it in a file, and run +The good/bad input is logged, and + +------------ +$ git bisect log +------------ + +shows what you have done so far. You can truncate its output somewhere +and save it in a file, and run ------------ $ git bisect replay that-file @@ -95,12 +100,13 @@ $ git bisect replay that-file if you find later you made a mistake telling good/bad about a revision. -If in a middle of bisect session, you know what the bisect -suggested to try next is not a good one to test (e.g. the change -the commit introduces is known not to work in your environment -and you know it does not have anything to do with the bug you -are chasing), you may want to find a near-by commit and try that -instead. It goes something like this: +If in a middle of bisect session, you know what the bisect suggested +to try next is not a good one to test (e.g. the change the commit +introduces is known not to work in your environment and you know it +does not have anything to do with the bug you are chasing), you may +want to find a near-by commit and try that instead. + +It goes something like this: ------------ $ git bisect good/bad # previous round was good/bad. @@ -110,13 +116,12 @@ $ git reset --hard HEAD~3 # try 3 revs before what # was suggested ------------ -Then compile and test the one you chose to try. After that, -tell bisect what the result was as usual. +Then compile and test the one you chose to try. After that, tell +bisect what the result was as usual. -You can further cut down the number of trials if you know what -part of the tree is involved in the problem you are tracking -down, by giving paths parameters when you say `bisect start`, -like this: +You can further cut down the number of trials if you know what part of +the tree is involved in the problem you are tracking down, by giving +paths parameters when you say `bisect start`, like this: ------------ $ git bisect start arch/i386 include/asm-i386 From 1207f9e705bcd69af286b2f887e67ae2baad3faf Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Sat, 24 Mar 2007 06:30:33 +0100 Subject: [PATCH 20/21] Documentation: bisect: add some titles to some paragraphs. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- Documentation/git-bisect.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 0bfb1525b..8a42deb32 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -28,6 +28,9 @@ This command uses 'git-rev-list --bisect' option to help drive the binary search process to find which change introduced a bug, given an old "good" commit object name and a later "bad" commit object name. +Basic bisect commands: start, bad, good +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + The way you use it is: ------------------------------------------------ @@ -65,6 +68,9 @@ bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". +Bisect reset +~~~~~~~~~~~~ + Oh, and then after you want to reset to the original head, do a ------------------------------------------------ @@ -76,6 +82,9 @@ bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). +Bisect visualize +~~~~~~~~~~~~~~~~ + During the bisection process, you can say ------------ @@ -84,6 +93,9 @@ $ git bisect visualize to see the currently remaining suspects in `gitk`. +Bisect log and bisect replay +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + The good/bad input is logged, and ------------ @@ -100,6 +112,9 @@ $ git bisect replay that-file if you find later you made a mistake telling good/bad about a revision. +Avoiding to test a commit +~~~~~~~~~~~~~~~~~~~~~~~~~ + If in a middle of bisect session, you know what the bisect suggested to try next is not a good one to test (e.g. the change the commit introduces is known not to work in your environment and you know it @@ -119,6 +134,9 @@ $ git reset --hard HEAD~3 # try 3 revs before what Then compile and test the one you chose to try. After that, tell bisect what the result was as usual. +Cutting down bisection by giving path parameter to bisect start +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + You can further cut down the number of trials if you know what part of the tree is involved in the problem you are tracking down, by giving paths parameters when you say `bisect start`, like this: @@ -127,6 +145,9 @@ paths parameters when you say `bisect start`, like this: $ git bisect start arch/i386 include/asm-i386 ------------ +Bisect run +~~~~~~~~~~ + If you have a script that can tell if the current source code is good or bad, you can automatically bisect using: From 6cea055547c6f90450a34a5f30db4a48e154ab81 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Sat, 24 Mar 2007 06:32:05 +0100 Subject: [PATCH 21/21] Documentation: bisect: make a comment fit better in the man page. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- Documentation/git-bisect.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 8a42deb32..b2bc58d85 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -35,9 +35,9 @@ The way you use it is: ------------------------------------------------ $ git bisect start -$ git bisect bad # Current version is bad -$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version - # tested that was good +$ git bisect bad # Current version is bad +$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version + # tested that was good ------------------------------------------------ When you give at least one bad and one good versions, it will bisect