* Re: [PATCH 0/9] Bisect skip
From: Shawn O. Pearce @ 2007-10-22 6:02 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, Johannes Schindelin, git
In-Reply-To: <200710220747.28731.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> wrote:
> Here is the "bisect skip" patch series.
> It's just a rename from "dunno" to "skip" compared to the previous "dunno"
> patch series that was in Shawn's pu branch.
>
> In fact there is no change in the first 3 patches and trivial changes in the
> other patches.
Thanks. I'm reparking this new version in pu tonight. It is too
late in the morning here for me to go through this any further than
applying and merging. I'm almost done looking through and testing
the new option parser series and then will be looking at this one
next; probably Tuesday.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] "git help" and "git help -a" shouldn't exit(1) unless they error
From: Shawn O. Pearce @ 2007-10-22 5:47 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <20071021214744.GH16291@srparish.net>
Scott R Parish <srp@srparish.net> wrote:
> diff --git a/help.c b/help.c
> index 1cd33ec..b0d2dd4 100644
> --- a/help.c
> +++ b/help.c
> @@ -204,14 +204,14 @@ int cmd_help(int argc, const char **argv, const char *prefix)
> if (!help_cmd) {
> printf("usage: %s\n\n", git_usage_string);
> list_common_cmds_help();
> - exit(1);
> + exit(0);
> }
Although it seems simple on the surface this patch breaks the
test suite:
$ make test
make -C t/ all
make[1]: Entering directory `/home/spearce/mygit/t'
*** t0000-basic.sh ***
You do not seem to have built git yet.
The issue here is t0000-basic.sh runs "../git" and tests that the
exit status is 1. If it isn't (the patch above makes it 0) we just
abort the test suite entirely.
I think its correct for "git help" to exit 0, and also for "git
help checkout" or "git checkout --help" to exit 0, but "git" by
itself with no subcommand should exit with an error, it requires a
subcommand to continue. So some sort of change is needed in git.c
to handle this special no subcommand condition.
--
Shawn.
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-22 5:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: david, git
In-Reply-To: <20071022050111.GL14735@spearce.org>
On Oct 22, 2007, at 7:01 AM, Shawn O. Pearce wrote:
> david@lang.hm wrote:
>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>>> If a .gitattributes is in the work tree and we checkout a
>>> different head, the .gitattributes of the head we are switching
>>> to must have precedence.
>>>
>>> Maybe the gitattributes of a file should be part of the per-file
>>> flags in the index. Thus we could verify if the flags changed and
>>> if so, adjust the work tree accordig to the new flags. I'm
>>> lacking a deeper insight into the git internals. Therefore, I
>>> can't really say if the index is the right place. But it looks
>>> to me as if changing an attribute should be treated similar to a
>>> changing sha1, as far as the work tree is concerned.
>>
>> the problem with this is that each attribute ends up needing it's own
>> flag, which severely limits extending things (see the discussions
>> on file
>> permissions for examples). it's also much harder to manipulate
>> them then
>> in a file.
>
> Yea, you really don't want to copy .gitattributes into the per-file
> records in the index. That's not going to scale as more types of
> attributes are defined.
>
> Fortunately the .gitattributes file format was designed to be
> readable even when there's merge conflicts; that is it is a
> very simple line-oriented record format. One could difference
> the old .gitattributes currently found in the index against the
> .gitattributes we are switching to (from the target tree-ish),
> scan the lines removed/added, find which files those match against
> in the target tree-ish, and just add those files to the list of
> things we need to checkout.
>
> If any of those files is dirty then we just refuse the checkout,
> just as if the file was modified and we were switching branches.
> The user then needs to decide how to continue (probably stash the
> file and then restart the checkout).
Sounds like a reasonable plan. I have no time to look into this
right away.
> Rather simple IMHO. Of course I haven't gone into that part of
> read-tree recently, and the .gitattribute parser reads from the
> working directory, so you need to make sure you checkout the target
> .gitattributes file before anything else in the "to process list".
.gitattributes is first looked for in the working directory,
and if not there, .gitattributes is read from the index.
Steffen
^ permalink raw reply
* [PATCH 9/9] Bisect: add a "bisect replay" test case.
From: Christian Couder @ 2007-10-22 5:49 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t6030-bisect-porcelain.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index db82259..16d0c4a 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -167,6 +167,13 @@ test_expect_success 'bisect skip: add line and then a new test' '
git bisect skip &&
git bisect good > my_bisect_log.txt &&
grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ git bisect log > log_to_replay.txt
+ git bisect reset
+'
+
+test_expect_success 'bisect skip and bisect replay' '
+ git bisect replay log_to_replay.txt > my_bisect_log.txt &&
+ grep "$HASH5 is first bad commit" my_bisect_log.txt &&
git bisect reset
'
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* [PATCH 8/9] Bisect: add "bisect skip" to the documentation.
From: Christian Couder @ 2007-10-22 5:49 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Also fix "bisect bad" and "bisect good" short usage description.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-bisect.txt | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 1072fb8..785f381 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -16,8 +16,9 @@ The command takes various subcommands, and different options depending
on the subcommand:
git bisect start [<bad> [<good>...]] [--] [<paths>...]
- git bisect bad <rev>
- git bisect good <rev>
+ git bisect bad [<rev>]
+ git bisect good [<rev>...]
+ git bisect skip [<rev>...]
git bisect reset [<branch>]
git bisect visualize
git bisect replay <logfile>
@@ -134,6 +135,20 @@ $ 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.
+Bisect skip
+~~~~~~~~~~~~
+
+Instead of choosing by yourself a nearby commit, you may just want git
+to do it for you using:
+
+------------
+$ git bisect skip # Current version cannot be tested
+------------
+
+But computing the commit to test may be slower afterwards and git may
+eventually not be able to tell the first bad among a bad and one or
+more "skip"ped commits.
+
Cutting down bisection by giving more parameters to bisect start
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* [PATCH 7/9] Bisect: factorise "bisect_{bad,good,skip}" into "bisect_state".
From: Christian Couder @ 2007-10-22 5:49 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 82 +++++++++++++++++++++-----------------------------------
1 files changed, 31 insertions(+), 51 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index d7f0a20..89f443b 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -134,47 +134,33 @@ bisect_write() {
test -z "$nolog" && echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
-bisect_bad() {
+bisect_state() {
bisect_autostart
- case "$#" in
- 0)
- rev=$(git rev-parse --verify HEAD) ;;
- 1)
- rev=$(git rev-parse --verify "$1^{commit}") ;;
+ state=$1
+ case "$#,$state" in
+ 0,*)
+ die "Please call 'bisect_state' with at least one argument." ;;
+ 1,bad|1,good|1,skip)
+ rev=$(git rev-parse --verify HEAD) ||
+ die "Bad rev input: HEAD"
+ bisect_write "$state" "$rev" ;;
+ 2,bad)
+ rev=$(git rev-parse --verify "$2^{commit}") ||
+ die "Bad rev input: $2"
+ bisect_write "$state" "$rev" ;;
+ *,good|*,skip)
+ shift
+ revs=$(git rev-parse --revs-only --no-flags "$@") &&
+ test '' != "$revs" || die "Bad rev input: $@"
+ for rev in $revs
+ do
+ rev=$(git rev-parse --verify "$rev^{commit}") ||
+ die "Bad rev commit: $rev^{commit}"
+ bisect_write "$state" "$rev"
+ done ;;
*)
usage ;;
- esac || exit
- bisect_write 'bad' "$rev"
- bisect_auto_next
-}
-
-bisect_good() {
- bisect_autostart
- case "$#" in
- 0) revs=$(git rev-parse --verify HEAD) || exit ;;
- *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
- test '' != "$revs" || die "Bad rev input: $@" ;;
esac
- for rev in $revs
- do
- rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write 'good' "$rev"
- done
- bisect_auto_next
-}
-
-bisect_skip() {
- bisect_autostart
- case "$#" in
- 0) revs=$(git rev-parse --verify HEAD) || exit ;;
- *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
- test '' != "$revs" || die "Bad rev input: $@" ;;
- esac
- for rev in $revs
- do
- rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write 'skip' "$rev"
- done
bisect_auto_next
}
@@ -404,24 +390,22 @@ bisect_run () {
exit $res
fi
- # Use "bisect_good" or "bisect_bad"
- # depending on run success or failure.
+ # Find current state depending on run success or failure.
if [ $res -gt 0 ]; then
- next_bisect='bisect_bad'
+ state='bad'
else
- next_bisect='bisect_good'
+ state='good'
fi
- # We have to use a subshell because bisect_good or
- # bisect_bad functions can exit.
- ( $next_bisect > "$GIT_DIR/BISECT_RUN" )
+ # We have to use a subshell because "bisect_state" can exit.
+ ( bisect_state $state > "$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"
+ echo >&2 "'bisect_state $state' exited with error code $res"
exit $res
fi
@@ -443,12 +427,8 @@ case "$#" in
case "$cmd" in
start)
bisect_start "$@" ;;
- bad)
- bisect_bad "$@" ;;
- good)
- bisect_good "$@" ;;
- skip)
- bisect_skip "$@" ;;
+ bad|good|skip)
+ bisect_state "$cmd" "$@" ;;
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* Re: [PATCH, take 1] Linear-time/space rename logic (exact renames only)
From: Linus Torvalds @ 2007-10-22 5:41 UTC (permalink / raw)
To: David Symonds
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, David Kastrup,
Jeff King
In-Reply-To: <ee77f5c20710211731n2646ae11jd2fb2c0be12494ac@mail.gmail.com>
On Mon, 22 Oct 2007, David Symonds wrote:
> > @@ -291,7 +291,7 @@ LIB_H = \
> > run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
> > tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
> > utf8.h reflog-walk.h patch-ids.h attr.h decorate.h progress.h \
> > - mailmap.h remote.h
> > + mailmap.h remote.h hash.o
>
> I assume that should be "hash.h", not "hash.o"?
Oops.
Yes.
Linus
^ permalink raw reply
* [PATCH 6/9] Bisect: factorise some logging into "bisect_write".
From: Christian Couder @ 2007-10-22 5:48 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Also use "die" instead of "echo >&2 something ; exit 1".
And simplify "bisect_replay".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 46 +++++++++++++---------------------------------
1 files changed, 13 insertions(+), 33 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 82aa404..d7f0a20 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -106,12 +106,11 @@ bisect_start() {
die "'$arg' does not appear to be a valid revision"
break
}
- if [ $bad_seen -eq 0 ]; then
- bad_seen=1
- bisect_write 'bad' "$rev"
- else
- bisect_write 'good' "$rev"
- fi
+ case $bad_seen in
+ 0) state='bad' ; bad_seen=1 ;;
+ *) state='good' ;;
+ esac
+ bisect_write "$state" "$rev" 'nolog'
shift
;;
esac
@@ -132,6 +131,7 @@ bisect_write() {
esac
echo "$rev" >"$GIT_DIR/refs/bisect/$tag"
echo "# $state: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+ test -z "$nolog" && echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
bisect_bad() {
@@ -145,7 +145,6 @@ bisect_bad() {
usage ;;
esac || exit
bisect_write 'bad' "$rev"
- echo "git-bisect bad $rev" >>"$GIT_DIR/BISECT_LOG"
bisect_auto_next
}
@@ -160,7 +159,6 @@ bisect_good() {
do
rev=$(git rev-parse --verify "$rev^{commit}") || exit
bisect_write 'good' "$rev"
- echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
done
bisect_auto_next
}
@@ -176,7 +174,6 @@ bisect_skip() {
do
rev=$(git rev-parse --verify "$rev^{commit}") || exit
bisect_write 'skip' "$rev"
- echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
done
bisect_auto_next
}
@@ -352,10 +349,8 @@ bisect_reset() {
else
branch=master
fi ;;
- 1) git show-ref --verify --quiet -- "refs/heads/$1" || {
- echo >&2 "$1 does not seem to be a valid branch"
- exit 1
- }
+ 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
+ die "$1 does not seem to be a valid branch"
branch="$1" ;;
*)
usage ;;
@@ -375,10 +370,7 @@ bisect_clean_state() {
}
bisect_replay () {
- test -r "$1" || {
- echo >&2 "cannot read $1 for replaying"
- exit 1
- }
+ test -r "$1" || die "cannot read $1 for replaying"
bisect_reset
while read bisect command rev
do
@@ -386,23 +378,11 @@ bisect_replay () {
case "$command" in
start)
cmd="bisect_start $rev"
- eval "$cmd"
- ;;
- good)
- bisect_write 'good' "$rev"
- echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
- ;;
- bad)
- bisect_write 'bad' "$rev"
- echo "git-bisect bad $rev" >>"$GIT_DIR/BISECT_LOG"
- ;;
- skip)
- bisect_write 'skip' "$rev"
- echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
- ;;
+ eval "$cmd" ;;
+ good|bad|skip)
+ bisect_write "$command" "$rev" ;;
*)
- echo >&2 "?? what are you talking about?"
- exit 1 ;;
+ die "?? what are you talking about?" ;;
esac
done <"$1"
bisect_auto_next
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* [PATCH 5/9] Bisect: factorise "bisect_write_*" functions.
From: Christian Couder @ 2007-10-22 5:48 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 46 ++++++++++++++++++++--------------------------
1 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index cd46190..82aa404 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -108,9 +108,9 @@ bisect_start() {
}
if [ $bad_seen -eq 0 ]; then
bad_seen=1
- bisect_write_bad "$rev"
+ bisect_write 'bad' "$rev"
else
- bisect_write_good "$rev"
+ bisect_write 'good' "$rev"
fi
shift
;;
@@ -122,6 +122,18 @@ bisect_start() {
bisect_auto_next
}
+bisect_write() {
+ state="$1"
+ rev="$2"
+ case "$state" in
+ bad) tag="$state" ;;
+ good|skip) tag="$state"-"$rev" ;;
+ *) die "Bad bisect_write argument: $state" ;;
+ esac
+ echo "$rev" >"$GIT_DIR/refs/bisect/$tag"
+ echo "# $state: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+}
+
bisect_bad() {
bisect_autostart
case "$#" in
@@ -132,17 +144,11 @@ bisect_bad() {
*)
usage ;;
esac || exit
- bisect_write_bad "$rev"
+ bisect_write 'bad' "$rev"
echo "git-bisect bad $rev" >>"$GIT_DIR/BISECT_LOG"
bisect_auto_next
}
-bisect_write_bad() {
- rev="$1"
- echo "$rev" >"$GIT_DIR/refs/bisect/bad"
- echo "# bad: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
-}
-
bisect_good() {
bisect_autostart
case "$#" in
@@ -153,18 +159,12 @@ bisect_good() {
for rev in $revs
do
rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write_good "$rev"
+ bisect_write 'good' "$rev"
echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
done
bisect_auto_next
}
-bisect_write_good() {
- rev="$1"
- echo "$rev" >"$GIT_DIR/refs/bisect/good-$rev"
- echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
-}
-
bisect_skip() {
bisect_autostart
case "$#" in
@@ -175,18 +175,12 @@ bisect_skip() {
for rev in $revs
do
rev=$(git rev-parse --verify "$rev^{commit}") || exit
- bisect_write_skip "$rev"
+ bisect_write 'skip' "$rev"
echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
done
bisect_auto_next
}
-bisect_write_skip() {
- rev="$1"
- echo "$rev" >"$GIT_DIR/refs/bisect/skip-$rev"
- echo "# skip: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
-}
-
bisect_next_check() {
missing_good= missing_bad=
git show-ref -q --verify refs/bisect/bad || missing_bad=t
@@ -395,15 +389,15 @@ bisect_replay () {
eval "$cmd"
;;
good)
- bisect_write_good "$rev"
+ bisect_write 'good' "$rev"
echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
;;
bad)
- bisect_write_bad "$rev"
+ bisect_write 'bad' "$rev"
echo "git-bisect bad $rev" >>"$GIT_DIR/BISECT_LOG"
;;
skip)
- bisect_write_skip "$rev"
+ bisect_write 'skip' "$rev"
echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
;;
*)
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* [PATCH 4/9] Bisect: implement "bisect skip" to mark untestable revisions.
From: Christian Couder @ 2007-10-22 5:48 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
When there are some "skip"ped revisions, we add the '--bisect-all'
option to "git rev-list --bisect-vars". Then we filter out the
"skip"ped revisions from the result of the rev-list command, and we
modify the "bisect_rev" var accordingly.
We don't always use "--bisect-all" because it is slower
than "--bisect-vars" or "--bisect".
When we cannot find for sure the first bad commit because of
"skip"ped commits, we print the hash of each possible first bad
commit and then we exit with code 2.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 125 ++++++++++++++++++++++++++++++++++++++++--
t/t6030-bisect-porcelain.sh | 71 ++++++++++++++++++++++++
2 files changed, 190 insertions(+), 6 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 436ccf6..cd46190 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -17,6 +17,8 @@ git bisect replay <logfile>
replay bisection log.
git bisect log
show bisect log.
+git bisect skip [<rev>...]
+ mark <rev>... untestable revisions.
git bisect run <cmd>...
use <cmd>... to automatically bisect.'
@@ -163,6 +165,28 @@ bisect_write_good() {
echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
}
+bisect_skip() {
+ bisect_autostart
+ case "$#" in
+ 0) revs=$(git rev-parse --verify HEAD) || exit ;;
+ *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
+ test '' != "$revs" || die "Bad rev input: $@" ;;
+ esac
+ for rev in $revs
+ do
+ rev=$(git rev-parse --verify "$rev^{commit}") || exit
+ bisect_write_skip "$rev"
+ echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
+ done
+ bisect_auto_next
+}
+
+bisect_write_skip() {
+ rev="$1"
+ echo "$rev" >"$GIT_DIR/refs/bisect/skip-$rev"
+ echo "# skip: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+}
+
bisect_next_check() {
missing_good= missing_bad=
git show-ref -q --verify refs/bisect/bad || missing_bad=t
@@ -205,17 +229,97 @@ bisect_auto_next() {
bisect_next_check && bisect_next || :
}
+filter_skipped() {
+ _eval="$1"
+ _skip="$2"
+
+ if [ -z "$_skip" ]; then
+ eval $_eval
+ return
+ fi
+
+ # Let's parse the output of:
+ # "git rev-list --bisect-vars --bisect-all ..."
+ eval $_eval | while read hash line
+ do
+ case "$VARS,$FOUND,$TRIED,$hash" in
+ # We display some vars.
+ 1,*,*,*) echo "$hash $line" ;;
+
+ # Split line.
+ ,*,*,---*) ;;
+
+ # We had nothing to search.
+ ,,,bisect_rev*)
+ echo "bisect_rev="
+ VARS=1
+ ;;
+
+ # We did not find a good bisect rev.
+ # This should happen only if the "bad"
+ # commit is also a "skip" commit.
+ ,,*,bisect_rev*)
+ echo "bisect_rev=$TRIED"
+ VARS=1
+ ;;
+
+ # We are searching.
+ ,,*,*)
+ TRIED="${TRIED:+$TRIED|}$hash"
+ case "$_skip" in
+ *$hash*) ;;
+ *)
+ echo "bisect_rev=$hash"
+ echo "bisect_tried=\"$TRIED\""
+ FOUND=1
+ ;;
+ esac
+ ;;
+
+ # We have already found a rev to be tested.
+ ,1,*,bisect_rev*) VARS=1 ;;
+ ,1,*,*) ;;
+
+ # ???
+ *) die "filter_skipped error " \
+ "VARS: '$VARS' " \
+ "FOUND: '$FOUND' " \
+ "TRIED: '$TRIED' " \
+ "hash: '$hash' " \
+ "line: '$line'"
+ ;;
+ esac
+ done
+}
+
+exit_if_skipped_commits () {
+ _tried=$1
+ if expr "$_tried" : ".*[|].*" > /dev/null ; then
+ echo "There are only 'skip'ped commit left to test."
+ echo "The first bad commit could be any of:"
+ echo "$_tried" | sed -e 's/[|]/\n/g'
+ echo "We cannot bisect more!"
+ exit 2
+ fi
+}
+
bisect_next() {
case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
bisect_next_check good
+ skip=$(git for-each-ref --format='%(objectname)' \
+ "refs/bisect/skip-*" | tr '[\012]' ' ') || exit
+
+ BISECT_OPT=''
+ test -n "$skip" && BISECT_OPT='--bisect-all'
+
bad=$(git rev-parse --verify refs/bisect/bad) &&
good=$(git for-each-ref --format='^%(objectname)' \
"refs/bisect/good-*" | tr '[\012]' ' ') &&
- eval="git rev-list --bisect-vars $good $bad --" &&
+ eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
- eval=$(eval "$eval") &&
+ eval=$(filter_skipped "$eval" "$skip") &&
eval "$eval" || exit
if [ -z "$bisect_rev" ]; then
@@ -223,11 +327,16 @@ bisect_next() {
exit 1
fi
if [ "$bisect_rev" = "$bad" ]; then
+ exit_if_skipped_commits "$bisect_tried"
echo "$bisect_rev is first bad commit"
git diff-tree --pretty $bisect_rev
exit 0
fi
+ # We should exit here only if the "bad"
+ # commit is also a "skip" commit (see above).
+ exit_if_skipped_commits "$bisect_rev"
+
echo "Bisecting: $bisect_nr revisions left to test after this"
echo "$bisect_rev" >"$GIT_DIR/refs/heads/new-bisect"
git checkout -q new-bisect || exit
@@ -286,15 +395,17 @@ bisect_replay () {
eval "$cmd"
;;
good)
- echo "$rev" >"$GIT_DIR/refs/bisect/good-$rev"
- echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+ bisect_write_good "$rev"
echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
;;
bad)
- echo "$rev" >"$GIT_DIR/refs/bisect/bad"
- echo "# bad: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+ bisect_write_bad "$rev"
echo "git-bisect bad $rev" >>"$GIT_DIR/BISECT_LOG"
;;
+ skip)
+ bisect_write_skip "$rev"
+ echo "git-bisect skip $rev" >>"$GIT_DIR/BISECT_LOG"
+ ;;
*)
echo >&2 "?? what are you talking about?"
exit 1 ;;
@@ -362,6 +473,8 @@ case "$#" in
bisect_bad "$@" ;;
good)
bisect_good "$@" ;;
+ skip)
+ bisect_skip "$@" ;;
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 03cdba5..db82259 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -71,6 +71,63 @@ test_expect_success 'bisect start with one bad and good' '
git bisect next
'
+# $HASH1 is good, $HASH4 is bad, we skip $HASH3
+# but $HASH2 is bad,
+# so we should find $HASH2 as the first bad commit
+test_expect_success 'bisect skip: successfull result' '
+ git bisect reset &&
+ git bisect start $HASH4 $HASH1 &&
+ git bisect skip &&
+ git bisect bad > my_bisect_log.txt &&
+ grep "$HASH2 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
+# $HASH1 is good, $HASH4 is bad, we skip $HASH3 and $HASH2
+# so we should not be able to tell the first bad commit
+# among $HASH2, $HASH3 and $HASH4
+test_expect_success 'bisect skip: cannot tell between 3 commits' '
+ git bisect start $HASH4 $HASH1 &&
+ git bisect skip || return 1
+
+ if git bisect skip > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH1 my_bisect_log.txt &&
+ grep $HASH2 my_bisect_log.txt &&
+ grep $HASH3 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect reset
+ fi
+'
+
+# $HASH1 is good, $HASH4 is bad, we skip $HASH3
+# but $HASH2 is good,
+# so we should not be able to tell the first bad commit
+# among $HASH3 and $HASH4
+test_expect_success 'bisect skip: cannot tell between 2 commits' '
+ git bisect start $HASH4 $HASH1 &&
+ git bisect skip || return 1
+
+ if git bisect good > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH1 my_bisect_log.txt &&
+ ! grep $HASH2 my_bisect_log.txt &&
+ grep $HASH3 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect reset
+ fi
+'
+
# We want to automatically find the commit that
# introduced "Another" into hello.
test_expect_success \
@@ -99,6 +156,20 @@ test_expect_success \
grep "$HASH4 is first bad commit" my_bisect_log.txt &&
git bisect reset'
+# $HASH1 is good, $HASH5 is bad, we skip $HASH3
+# but $HASH4 is good,
+# so we should find $HASH5 as the first bad commit
+HASH5=
+test_expect_success 'bisect skip: add line and then a new test' '
+ add_line_into_file "5: Another new line." hello &&
+ HASH5=$(git rev-parse --verify HEAD) &&
+ git bisect start $HASH5 $HASH1 &&
+ git bisect skip &&
+ git bisect good > my_bisect_log.txt &&
+ grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
#
#
test_done
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* [PATCH 3/9] Bisect: fix some white spaces and empty lines breakages.
From: Christian Couder @ 2007-10-22 5:48 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-bisect.sh | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 388887a..436ccf6 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -64,7 +64,7 @@ bisect_start() {
branch=`cat "$GIT_DIR/head-name"`
else
branch=master
- fi
+ fi
git checkout $branch || exit
;;
refs/heads/*)
@@ -95,11 +95,11 @@ bisect_start() {
arg="$1"
case "$arg" in
--)
- shift
+ shift
break
;;
*)
- rev=$(git rev-parse --verify "$arg^{commit}" 2>/dev/null) || {
+ rev=$(git rev-parse --verify "$arg^{commit}" 2>/dev/null) || {
test $has_double_dash -eq 1 &&
die "'$arg' does not appear to be a valid revision"
break
@@ -110,10 +110,10 @@ bisect_start() {
else
bisect_write_good "$rev"
fi
- shift
+ shift
;;
esac
- done
+ done
sq "$@" >"$GIT_DIR/BISECT_NAMES"
echo "git-bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG"
@@ -143,7 +143,7 @@ bisect_write_bad() {
bisect_good() {
bisect_autostart
- case "$#" in
+ case "$#" in
0) revs=$(git rev-parse --verify HEAD) || exit ;;
*) revs=$(git rev-parse --revs-only --no-flags "$@") &&
test '' != "$revs" || die "Bad rev input: $@" ;;
@@ -153,7 +153,6 @@ bisect_good() {
rev=$(git rev-parse --verify "$rev^{commit}") || exit
bisect_write_good "$rev"
echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
-
done
bisect_auto_next
}
@@ -207,7 +206,7 @@ bisect_auto_next() {
}
bisect_next() {
- case "$#" in 0) ;; *) usage ;; esac
+ case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
bisect_next_check good
@@ -255,7 +254,7 @@ bisect_reset() {
exit 1
}
branch="$1" ;;
- *)
+ *)
usage ;;
esac
if git checkout "$branch"; then
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* [PATCH 2/9] rev-list documentation: add "--bisect-all".
From: Christian Couder @ 2007-10-22 5:48 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-rev-list.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 7cd0e89..4852804 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -34,6 +34,7 @@ SYNOPSIS
[ \--pretty | \--header ]
[ \--bisect ]
[ \--bisect-vars ]
+ [ \--bisect-all ]
[ \--merge ]
[ \--reverse ]
[ \--walk-reflogs ]
@@ -354,6 +355,21 @@ the expected number of commits to be tested if `bisect_rev`
turns out to be bad to `bisect_bad`, and the number of commits
we are bisecting right now to `bisect_all`.
+--bisect-all::
+
+This outputs all the commit objects between the included and excluded
+commits, ordered by their distance to the included and excluded
+commits. The farthest from them is displayed first. (This is the only
+one displayed by `--bisect`.)
+
+This is useful because it makes it easy to choose a good commit to
+test when you want to avoid to test some of them for some reason (they
+may not compile for example).
+
+This option can be used along with `--bisect-vars`, in this case,
+after all the sorted commit objects, there will be the same text as if
+`--bisect-vars` had been used alone.
+
--
Commit Ordering
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* [PATCH 1/9] rev-list: implement --bisect-all
From: Christian Couder @ 2007-10-22 5:47 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
This is Junio's patch with some stuff to make --bisect-all
compatible with --bisect-vars.
This option makes it possible to see all the potential
bisection points. The best ones are displayed first.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-rev-list.c | 100 ++++++++++++++++++++++++++++++++++++++++++++-------
log-tree.c | 2 +-
log-tree.h | 1 +
3 files changed, 88 insertions(+), 15 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 33726b8..4439332 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -9,6 +9,7 @@
#include "revision.h"
#include "list-objects.h"
#include "builtin.h"
+#include "log-tree.h"
/* bits #0-15 in revision.h */
@@ -38,7 +39,8 @@ static const char rev_list_usage[] =
" --left-right\n"
" special purpose:\n"
" --bisect\n"
-" --bisect-vars"
+" --bisect-vars\n"
+" --bisect-all"
;
static struct rev_info revs;
@@ -74,6 +76,7 @@ static void show_commit(struct commit *commit)
parents = parents->next;
}
}
+ show_decorations(commit);
if (revs.commit_format == CMIT_FMT_ONELINE)
putchar(' ');
else
@@ -278,6 +281,57 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
return best;
}
+struct commit_dist {
+ struct commit *commit;
+ int distance;
+};
+
+static int compare_commit_dist(const void *a_, const void *b_)
+{
+ struct commit_dist *a, *b;
+
+ a = (struct commit_dist *)a_;
+ b = (struct commit_dist *)b_;
+ if (a->distance != b->distance)
+ return b->distance - a->distance; /* desc sort */
+ return hashcmp(a->commit->object.sha1, b->commit->object.sha1);
+}
+
+static struct commit_list *best_bisection_sorted(struct commit_list *list, int nr)
+{
+ struct commit_list *p;
+ struct commit_dist *array = xcalloc(nr, sizeof(*array));
+ int cnt, i;
+
+ for (p = list, cnt = 0; p; p = p->next) {
+ int distance;
+ unsigned flags = p->item->object.flags;
+
+ if (revs.prune_fn && !(flags & TREECHANGE))
+ continue;
+ distance = weight(p);
+ if (nr - distance < distance)
+ distance = nr - distance;
+ array[cnt].commit = p->item;
+ array[cnt].distance = distance;
+ cnt++;
+ }
+ qsort(array, cnt, sizeof(*array), compare_commit_dist);
+ for (p = list, i = 0; i < cnt; i++) {
+ struct name_decoration *r = xmalloc(sizeof(*r) + 100);
+ struct object *obj = &(array[i].commit->object);
+
+ sprintf(r->name, "dist=%d", array[i].distance);
+ r->next = add_decoration(&name_decoration, obj, r);
+ p->item = array[i].commit;
+ p = p->next;
+ }
+ if (p)
+ p->next = NULL;
+ free(array);
+ return list;
+}
+
/*
* zero or positive weight is the number of interesting commits it can
* reach, including itself. Especially, weight = 0 means it does not
@@ -292,7 +346,8 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
* or positive distance.
*/
static struct commit_list *do_find_bisection(struct commit_list *list,
- int nr, int *weights)
+ int nr, int *weights,
+ int find_all)
{
int n, counted;
struct commit_list *p;
@@ -351,7 +406,7 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
clear_distance(list);
/* Does it happen to be at exactly half-way? */
- if (halfway(p, nr))
+ if (!find_all && halfway(p, nr))
return p;
counted++;
}
@@ -389,19 +444,22 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
weight_set(p, weight(q));
/* Does it happen to be at exactly half-way? */
- if (halfway(p, nr))
+ if (!find_all && halfway(p, nr))
return p;
}
}
show_list("bisection 2 counted all", counted, nr, list);
- /* Then find the best one */
- return best_bisection(list, nr);
+ if (!find_all)
+ return best_bisection(list, nr);
+ else
+ return best_bisection_sorted(list, nr);
}
static struct commit_list *find_bisection(struct commit_list *list,
- int *reaches, int *all)
+ int *reaches, int *all,
+ int find_all)
{
int nr, on_list;
struct commit_list *p, *best, *next, *last;
@@ -434,14 +492,13 @@ static struct commit_list *find_bisection(struct commit_list *list,
weights = xcalloc(on_list, sizeof(*weights));
/* Do the real work of finding bisection commit. */
- best = do_find_bisection(list, nr, weights);
-
+ best = do_find_bisection(list, nr, weights, find_all);
if (best) {
- best->next = NULL;
+ if (!find_all)
+ best->next = NULL;
*reaches = weight(best);
}
free(weights);
-
return best;
}
@@ -468,6 +525,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
int i;
int read_from_stdin = 0;
int bisect_show_vars = 0;
+ int bisect_find_all = 0;
git_config(git_default_config);
init_revisions(&revs, prefix);
@@ -490,6 +548,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
bisect_list = 1;
continue;
}
+ if (!strcmp(arg, "--bisect-all")) {
+ bisect_list = 1;
+ bisect_find_all = 1;
+ continue;
+ }
if (!strcmp(arg, "--bisect-vars")) {
bisect_list = 1;
bisect_show_vars = 1;
@@ -536,9 +599,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (bisect_list) {
int reaches = reaches, all = all;
- revs.commits = find_bisection(revs.commits, &reaches, &all);
+ revs.commits = find_bisection(revs.commits, &reaches, &all,
+ bisect_find_all);
if (bisect_show_vars) {
int cnt;
+ char hex[41];
if (!revs.commits)
return 1;
/*
@@ -550,15 +615,22 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
* A bisect set of size N has (N-1) commits further
* to test, as we already know one bad one.
*/
- cnt = all-reaches;
+ cnt = all - reaches;
if (cnt < reaches)
cnt = reaches;
+ strcpy(hex, sha1_to_hex(revs.commits->item->object.sha1));
+
+ if (bisect_find_all) {
+ traverse_commit_list(&revs, show_commit, show_object);
+ printf("------\n");
+ }
+
printf("bisect_rev=%s\n"
"bisect_nr=%d\n"
"bisect_good=%d\n"
"bisect_bad=%d\n"
"bisect_all=%d\n",
- sha1_to_hex(revs.commits->item->object.sha1),
+ hex,
cnt - 1,
all - reaches - 1,
reaches - 1,
diff --git a/log-tree.c b/log-tree.c
index 62edd34..3763ce9 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -15,7 +15,7 @@ static void show_parents(struct commit *commit, int abbrev)
}
}
-static void show_decorations(struct commit *commit)
+void show_decorations(struct commit *commit)
{
const char *prefix;
struct name_decoration *decoration;
diff --git a/log-tree.h b/log-tree.h
index e82b56a..b33f7cd 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -12,5 +12,6 @@ int log_tree_diff_flush(struct rev_info *);
int log_tree_commit(struct rev_info *, struct commit *);
int log_tree_opt_parse(struct rev_info *, const char **, int);
void show_log(struct rev_info *opt, const char *sep);
+void show_decorations(struct commit *commit);
#endif
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* [PATCH 0/9] Bisect skip
From: Christian Couder @ 2007-10-22 5:47 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
Hi all,
Here is the "bisect skip" patch series.
It's just a rename from "dunno" to "skip" compared to the previous "dunno"
patch series that was in Shawn's pu branch.
In fact there is no change in the first 3 patches and trivial changes in the
other patches.
Thanks,
Christian.
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-22 5:38 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710211703060.12998@asgard.lang.hm>
On Oct 22, 2007, at 2:05 AM, david@lang.hm wrote:
>
> by the way, I am not saying that my suggestion is the right way for
> things to be (especially long term), but I'm trying to figure out a
> work-around for the short term.
And I'm saying your proposed workaround is dangerous and doesn't
work reliably.
> I'm very interested to see the logn-term suggestions, becouse I
> suspect that modt of them could be leveraged for the metastore jobs.
I'd prefer this, too.
Steffen
^ permalink raw reply
* Re: [PATCH] "git help -a" should search all exec_paths and PATH
From: Shawn O. Pearce @ 2007-10-22 5:30 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <20071021214846.GI16291@srparish.net>
Scott R Parish <srp@srparish.net> wrote:
> Currently "git help -a" only searches in the highest priority exec_path,
> meaning at worst, nothing is listed if the git commands are only available
> from the PATH. It also makes git slightly less extensible.
...
> extern char **environ;
> static const char *builtin_exec_path = GIT_EXEC_PATH;
> -static const char *current_exec_path;
> +static const char *argv_exec_path;
>
> -void git_set_exec_path(const char *exec_path)
> +void git_set_argv_exec_path(const char *exec_path)
> {
> - current_exec_path = exec_path;
> + argv_exec_path = exec_path;
> }
I'd rather see a rename isolated from a logic change. I find
it easier to review.
> +const char *git_argv_exec_path(void)
> +const char *git_builtin_exec_path(void)
> +const char *git_env_exec_path(void)
And yet later you then build the same priority array as already used
by execv_git_cmd(). Why not just make a function that builds the
array for the caller, so both execv_git_cmd() and list_commands()
can both use the same array?
> +static unsigned int list_commands_in_dir(const char *dir, const char *prefix)
> {
> + int start_dir = open(".", O_RDONLY, 0);
...
> + if (!dirp || chdir(dir)) {
> + fchdir(start_dir);
fchdir() isn't as portable as Git currently is. Thus far we have
avoided using fchdir(). Requiring it here for something as "simple"
as listing help is not a good improvement as it will limit who can
run git-help. Why can't you stat the individual entries by joining
the paths together?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-cherry-pick: improve description of -x.
From: Ralf Wildenhues @ 2007-10-22 5:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Frank Lichtenheld, git
In-Reply-To: <20071022051453.GM14735@spearce.org>
* Shawn O. Pearce wrote on Mon, Oct 22, 2007 at 07:14:53AM CEST:
>
> I think you are right that the current behavior of -x *not*
> including the prior commit SHA-1 in the case of a conflict is wrong.
> The problem however is that git-commit.sh doesn't get the data
> necessary to preseve the original author name/email/date/tz unless
> you use the "-c $id" option.
But the note added by -x is even missing when I add "-c $id" to
the git-commit command! That's the point I was trying to make,
and really the only thing that seemed weird to me.
Cheers,
Ralf
^ permalink raw reply
* Re: [PATCH] git-cherry-pick: improve description of -x.
From: Shawn O. Pearce @ 2007-10-22 5:14 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: Frank Lichtenheld, git
In-Reply-To: <20071021093618.GC12794@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> * Shawn O. Pearce wrote on Sat, Oct 20, 2007 at 05:19:17AM CEST:
> > Frank Lichtenheld <frank@lichtenheld.de> wrote:
> > > On Fri, Oct 19, 2007 at 07:41:34PM +0200, Ralf Wildenhues wrote:
> > > >
> > > > Is that by design (because there were conflicts) or an omission?
> > > > In case of the former, maybe the description of -x should mention this.
> > >
> > > git commit currently doesn't know that you commit a cherry-pick. The -c
> > > only says to use the commit message of the original commit. So this is
> > > currently by design.
> >
> > Ralf, can you submit an updated version of this patch that describes
> > the current behavior better, given the "by design" remark above
> > from Frank?
>
> Here it goes. Still makes me wonder whether that is the ideal mode of
> operation or not.
Thanks.
I think you are right that the current behavior of -x *not*
including the prior commit SHA-1 in the case of a conflict is wrong.
The problem however is that git-commit.sh doesn't get the data
necessary to preseve the original author name/email/date/tz unless
you use the "-c $id" option. There's some work here to store the
necessary information into a file that git-commit.sh could pickup,
and then making sure stale versions of those files get cleaned up
properly, etc.
At least the current behavior is now documented. Maybe someone
will be bothered enough by it to try and submit a patch that changes
the behavior.
--
Shawn.
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Shawn O. Pearce @ 2007-10-22 5:01 UTC (permalink / raw)
To: david; +Cc: Steffen Prohaska, git
In-Reply-To: <Pine.LNX.4.64.0710210204580.4818@asgard>
david@lang.hm wrote:
> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
> >If a .gitattributes is in the work tree and we checkout a
> >different head, the .gitattributes of the head we are switching
> >to must have precedence.
> >
> >Maybe the gitattributes of a file should be part of the per-file
> >flags in the index. Thus we could verify if the flags changed and
> >if so, adjust the work tree accordig to the new flags. I'm
> >lacking a deeper insight into the git internals. Therefore, I
> >can't really say if the index is the right place. But it looks
> >to me as if changing an attribute should be treated similar to a
> >changing sha1, as far as the work tree is concerned.
>
> the problem with this is that each attribute ends up needing it's own
> flag, which severely limits extending things (see the discussions on file
> permissions for examples). it's also much harder to manipulate them then
> in a file.
Yea, you really don't want to copy .gitattributes into the per-file
records in the index. That's not going to scale as more types of
attributes are defined.
Fortunately the .gitattributes file format was designed to be
readable even when there's merge conflicts; that is it is a
very simple line-oriented record format. One could difference
the old .gitattributes currently found in the index against the
.gitattributes we are switching to (from the target tree-ish),
scan the lines removed/added, find which files those match against
in the target tree-ish, and just add those files to the list of
things we need to checkout.
If any of those files is dirty then we just refuse the checkout,
just as if the file was modified and we were switching branches.
The user then needs to decide how to continue (probably stash the
file and then restart the checkout).
Rather simple IMHO. Of course I haven't gone into that part of
read-tree recently, and the .gitattribute parser reads from the
working directory, so you need to make sure you checkout the target
.gitattributes file before anything else in the "to process list".
--
Shawn.
^ permalink raw reply
* Re: how to deal with conflicts after "git stash apply"?
From: Scott Parish @ 2007-10-22 4:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710212338200.25221@racer.site>
> You should have a look into Documentation/diff-format.txt (section
> "combined diff format") to learn more.
Ah, thanks for the pointer; i hadn't realized that this wasn't
standard diff format. With this and what Shawn said, it all makes
sense now.
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: how to deal with conflicts after "git stash apply"?
From: Shawn O. Pearce @ 2007-10-22 4:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Parish, git
In-Reply-To: <Pine.LNX.4.64.0710212338200.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 21 Oct 2007, Scott Parish wrote:
>
> > How is the intended way to deal with "git stash apply" conflicts?
> > If i just edit the file and remove the conflict, "git diff" gives
> > some really messed up output. Documentation for other commands and
> > conflicts suggest "git commit" after cleaning up the conflict, or
> > "git add", but in the case of "stash apply" i'm not ready for a
> > commit yet, and "git add" keeps "git diff" from showing any output.
>
> You are probably seeing combined diffs.
>
> This show not only the differences of the working tree relative to HEAD,
> but also of the changes stored in the stash.
The reason Scott is seeing a combined diff here is merge-recursive
left the different versions of the file in the higher order stages
of the index when it found conflicts during the apply. You need
to use git-add to stage the resolved file and replace the higher
order stages with just the normal stage 0.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Shawn O. Pearce @ 2007-10-22 4:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Parish, git
In-Reply-To: <Pine.LNX.4.64.0710212256270.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Earlier, we tried to find the git commands in several possible exec
> dirs. Now, if all of these failed, try to find the git command in
> PATH.
...
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 9b74ed2..70b84b0 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -36,7 +36,8 @@ int execv_git_cmd(const char **argv)
> int i;
> const char *paths[] = { current_exec_path,
> getenv(EXEC_PATH_ENVIRONMENT),
> - builtin_exec_path };
> + builtin_exec_path,
> + "" };
So if the user sets GIT_EXEC_PATH="" and exports it we'll search
$PATH before the builtin exec path that Git was compiled with?
Are we sure we want to do that?
I'm going to throw this into pu tonight just so I don't lose it,
but I have a feeling we want to amend it before merging.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
From: Shawn O. Pearce @ 2007-10-22 4:00 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: René Scharfe, git
In-Reply-To: <20071021103132.GA25741@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
> On Sun, Oct 21, 2007 at 09:23:49AM +0000, René Scharfe wrote:
> > > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > > ---
> > > builtin-apply.c | 2 +-
> > > builtin-archive.c | 2 +-
> > > diff.c | 4 ++--
> > > entry.c | 2 +-
> > > strbuf.h | 8 +++++++-
> > > test-delta.c | 3 ++-
> > > 6 files changed, 14 insertions(+), 7 deletions(-)
> >
> > I have a feeling this is going in then wrong direction. Shouldn't
> > we rather use size_t everywhere? malloc() takes a size_t, and it's
> > the basis of strbuf and also of the file content functions.
>
> I agree, Junio was working on a patch that generalized use of size_t's
> when unsigned long where used and size_t meant, I suppose he didn't had
> the time to push it.
Yea, you guys convinced me to go with René's patch. I'm
replacing mine and will put it into next tonight.
I actually had started with what René wrote but changed it to
what you saw before posting it to the list. :-)
--
Shawn.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Miles Bader @ 2007-10-22 3:39 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Petr Baudis, Jari Aalto, git
In-Reply-To: <dbfc82860710180439j6d02651foff9c0c84623a9cf1@mail.gmail.com>
"Nikolai Weibull" <now@bitwi.se> writes:
> To change the subject, let me point out that the percent symbol should
> be juxtaposed with the number, that is, write "99%", not "99 %", in
> English.
Hmm, but what if one uses a tab?
-miles
--
My books focus on timeless truths. -- Donald Knuth
^ permalink raw reply
* [PATCH] gitweb: Provide title attributes for abbreviated author names.
From: David Symonds @ 2007-10-22 0:28 UTC (permalink / raw)
To: pasky, spearce; +Cc: git, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
gitweb/gitweb.perl | 34 +++++++++++++++++++++++++++++-----
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b2bae1b..119ad55 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3461,9 +3461,15 @@ sub git_shortlog_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 10);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"" . esc_html($co{'author_name'}) . "\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
# git_summary() used print "<td><i>$co{'age_string'}</i></td>\n" .
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>";
print format_subject_html($co{'title'}, $co{'title_short'},
href(action=>"commit", hash=>$commit), $ref);
@@ -3511,9 +3517,15 @@ sub git_history_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ # shortlog uses chop_str($co{'author_name'}, 10)
+ my $author = chop_str($co{'author_name'}, 15, 3);
+ if ($author ne $co{'author_name'}) {
+ "<span title=\"" . esc_html($co{'author_name'}) . "\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- # shortlog uses chop_str($co{'author_name'}, 10)
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 3)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>";
# originally git_history used chop_str($co{'title'}, 50)
print format_subject_html($co{'title'}, $co{'title_short'},
@@ -3667,8 +3679,14 @@ sub git_search_grep_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 15, 5);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"" . esc_html($co{'author_name'}) . "\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}), -class => "list subject"},
esc_html(chop_str($co{'title'}, 50)) . "<br/>");
@@ -5181,8 +5199,14 @@ sub git_search {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 15, 5);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"" . esc_html($co{'author_name'}) . "\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}),
-class => "list subject"},
--
1.5.3.1
^ permalink raw reply related
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