threads / patch / 2679

patch, 4 partsRepository format version check series.

Subject: [PATCH 0/4] Repository format version check series.

## tl;dr

8 messages between Nov 26, 2005 and Nov 29, 2005. Diffs are folded; open one to read it.

replies: 7people: 4as markdown or json

Junio C Hamano· Nov 26, 2005, 01:15 UTC · lore

This series is what I've been cooking for the past several days, partly based on patch from Martin Atukunda but with hopefully smaller impact.

[PATCH 1/4] Repository format version check. [PATCH 2/4] Check repository format version in enter_repo(). [PATCH 3/4] init-db: check template and repository format. [PATCH 4/4] setup_git_directory(): check repository format version.

The first in the series adds the core.repositoryformatversion configuration item. The current repository format version is defined as version 0, and is the same as not having that in the configuration file.

The second one adds a repository format version check to enter_repo(). This function is used to verify the path given by the user, either from the command line or over the network, is a valid git repository by daemon, upload-pack (which runs on the other end when you run fetch-pack or clone-pack), and receive-pack (which runs on the other end when you run send-pack).

The third one makes sure we do not reinitialize a repository whose format version we do not understand, do not copy template files from unmatching version into a new repository, and record the repository format version in a newly created repository.

The last bit in the series adds the same check code to setup_git_directory(). Along with the earlier change to git-sh-setup that uses git-var to verify the repository, this gives the shell scripts the same repository format version check.

I'll push this out to the "master" sometime over the weekend, and hopefully merge it into "maint" and cut the next 1.0rc on Wednesday. Let's hope that will be the last 1.0rc.

Junio C Hamano· Nov 27, 2005, 10:56 UTC · re: Junio C Hamano · lore

What's in master and pu (aka when will 1.0rc4 be out)

Junio C Hamano <junkio@cox.net> writes:
Show 8 quoted lines
> This series is what I've been cooking for the past several days,
> partly based on patch from Martin Atukunda but with hopefully
> smaller impact.
>
> [PATCH 1/4] Repository format version check.
> [PATCH 2/4] Check repository format version in enter_repo().
> [PATCH 3/4] init-db: check template and repository format.
> [PATCH 4/4] setup_git_directory(): check repository format version.

And they are now in the master branch, along with a couple of bugfixes I received in the last couple of days. I've given them some testing and believe they are in good enough shape for 1.0 futureproofing. Bug reports with reproduction recipe and/or patch are most welcomed.

Cooking in the proposed updates branch is the 8-series "work from subdirectory" patch I posted yesterday, with some polishing based on suggestion from Linus. The ls-tree rework is not included at this point, neither is the git-sh-setup, both of which unfortunately have wider impact than I feel comfortable to swallow in one day.

I am hoping to base the next "maint" branch update, probably on Wednesday, on what is in "pu" tonight, with safer updates I will receive from the list (Documentation fixes and updates, and archimport updates from Eric and Martin are the candidates). That will be tagged as 1.0rc4 and hopefully be the last 1.0rc, which means no more major feature/semantics changes after that until 1.0 --- famous last words.

So I anticipate that many of the barebone Porcelain commands that insist on running from the toplevel will ship the way they are in 1.0. If you run "git grep git-sh-setup 'git*sh'", you will notice that most of them are whole-tree operations anyway, so not much is lost [*1*].

[Footnote]

*1* Bisecting only in a subdirectory might be an interesting thing to do, hunting down a bug in a subsystem, but usually a subsystem has at least two relevant subdirectories (source and include file trees) ;-).

I suspect that it would be trivial to convert whole-repository operations such as count-objects, prune, and repack to work from subdirectory, although the value of that is dubious.

Timo Hirvonen· Nov 27, 2005, 13:11 UTC · re: Junio C Hamano · lore

Re: What's in master and pu (aka when will 1.0rc4 be out)

On Sun, 27 Nov 2005 02:56:21 -0800 Junio C Hamano <junkio@cox.net> wrote:

> *1* Bisecting only in a subdirectory might be an interesting
> thing to do, hunting down a bug in a subsystem, but usually a
> subsystem has at least two relevant subdirectories (source and
> include file trees) ;-).
Hmm.. would something like 
    git-bisect --include drivers/char/drm/ --include include/ ...

be easy to implement? That command would limit bisecting to only the commits that have changed files under those two directories.

-- 
http://onion.dynserv.net/~timo/
Linus Torvalds· Nov 27, 2005, 19:32 UTC · re: Timo Hirvonen · lore

Re: What's in master and pu (aka when will 1.0rc4 be out)

On Sun, 27 Nov 2005, Timo Hirvonen wrote:
Show 7 quoted lines
> 
> Hmm.. would something like 
> 
>     git-bisect --include drivers/char/drm/ --include include/ ...
> 
> be easy to implement?  That command would limit bisecting to only the
> commits that have changed files under those two directories.
Heh.
It was surprisingly easy to do.
The syntax is
	git bisect start <pathspec>
followed by all the normal "git bisect good/bad" stuff.

Almost totally untested, and I guarantee that if your pathnames have spaces in them (or your GIT_DIR has spaces in it) this won't work. I don't know how to fix that, my shell programming isn't good enough.

This involves small changes to make "git-rev-list --bisect" work in the presense of a pathspec limiter, and then truly trivial (and that's the broken part) changes to make "git bisect" save away and use the pathspec.

I tried one bisection, and a "git bisect visualize", and it all looked correct. But hey, don't be surprised if it has problems.

		Linus
---
Show changes to 2 files +17 −11

git-bisect.sh, rev-list.c

diff --git a/git-bisect.sh b/git-bisect.sh
index d92993b..2455f00 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -33,7 +33,6 @@ bisect_autostart() {
 }
 
 bisect_start() {
-        case "$#" in 0) ;; *) usage ;; esac
 	#
 	# Verify HEAD. If we were bisecting before this, reset to the
 	# top-of-line master first!
@@ -57,7 +56,8 @@ bisect_start() {
 	rm -f "$GIT_DIR/refs/heads/bisect"
 	rm -rf "$GIT_DIR/refs/bisect/"
 	mkdir "$GIT_DIR/refs/bisect"
-	echo "git-bisect start" >"$GIT_DIR/BISECT_LOG"
+	echo "git-bisect start $@" >"$GIT_DIR/BISECT_LOG"
+	echo "$@" > "$GIT_DIR/BISECT_NAMES"
 }
 
 bisect_bad() {
@@ -121,7 +121,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") || 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
@@ -131,7 +131,7 @@ bisect_next() {
 	    git-diff-tree --pretty $rev
 	    exit 0
 	fi
-	nr=$(eval "git-rev-list $rev $good" | wc -l) || exit
+	nr=$(eval "git-rev-list $rev $good -- $(cat $GIT_DIR/BISECT_NAMES)" | wc -l) || exit
 	echo "Bisecting: $nr revisions left to test after this"
 	echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
 	git checkout new-bisect || exit
@@ -142,7 +142,7 @@ bisect_next() {
 
 bisect_visualize() {
 	bisect_next_check fail
-	gitk bisect/bad --not `cd "$GIT_DIR/refs" && echo bisect/good-*`
+	gitk bisect/bad --not `cd "$GIT_DIR/refs" && echo bisect/good-*` -- $(cat $GIT_DIR/BISECT_NAMES)
 }
 
 bisect_reset() {
diff --git a/rev-list.c b/rev-list.c
index e17f928..8020d97 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -350,7 +350,8 @@ static int count_distance(struct commit_
 
 		if (commit->object.flags & (UNINTERESTING | COUNTED))
 			break;
-		nr++;
+		if (!paths || (commit->object.flags & TREECHANGE))
+			nr++;
 		commit->object.flags |= COUNTED;
 		p = commit->parents;
 		entry = p;
@@ -362,6 +363,7 @@ static int count_distance(struct commit_
 			}
 		}
 	}
+
 	return nr;
 }
 
@@ -382,15 +384,20 @@ static struct commit_list *find_bisectio
 	nr = 0;
 	p = list;
 	while (p) {
-		nr++;
+		if (!paths || (p->item->object.flags & TREECHANGE))
+			nr++;
 		p = p->next;
 	}
 	closest = 0;
 	best = list;
 
-	p = list;
-	while (p) {
-		int distance = count_distance(p);
+	for (p = list; p; p = p->next) {
+		int distance;
+
+		if (paths && !(p->item->object.flags & TREECHANGE))
+			continue;
+
+		distance = count_distance(p);
 		clear_distance(list);
 		if (nr - distance < distance)
 			distance = nr - distance;
@@ -398,7 +405,6 @@ static struct commit_list *find_bisectio
 			best = p;
 			closest = distance;
 		}
-		p = p->next;
 	}
 	if (best)
 		best->next = NULL;
Junio C Hamano· Nov 27, 2005, 21:08 UTC · re: Linus Torvalds · lore

Re: What's in master and pu (aka when will 1.0rc4 be out)

Linus Torvalds <torvalds@osdl.org> writes:
Show 5 quoted lines
> The syntax is
>
> 	git bisect start <pathspec>
>
> followed by all the normal "git bisect good/bad" stuff.

I love how I can just say "this might be interesting" and find your message in my mailbox next morning [*1*] ;-).

This would be useful to cut down the number of bisection needed to reach the culprit if the initial guess is correct as to which part of the tree is involved.

[Reference] *1* http://marc.theaimsgroup.com/?l=git&m=111669620826189

Junio C Hamano· Nov 28, 2005, 01:51 UTC · re: Linus Torvalds · lore

[PATCH] bisect: quote pathnames for eval safety.

Linus Torvalds <torvalds@osdl.org> writes:
> Almost totally untested, and I guarantee that if your pathnames have 
> spaces in them (or your GIT_DIR has spaces in it) this won't work. I don't 
> know how to fix that, my shell programming isn't good enough.

Like this? I've placed the bisect patch with this in the proposed updates.

---
 git-bisect.sh |   16 ++++++++++++----
 1 files changed, 12 insertions(+), 4 deletions(-)

applies-to: 7da44ab45773e0a424c1e08c838c1f6deeb6ceb2 82c8f5bed2ae61f1f368cfca84f6b0194b1ad208

Show changes to git-bisect.sh +12 −4
diff --git a/git-bisect.sh b/git-bisect.sh
index 2455f00..d4196f9 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,9 +1,16 @@
 #!/bin/sh
 . git-sh-setup
 
+sq() {
+    for x
+    do
+	echo "$x" | sed -e "s/'/'\\\\''/g" -e "s/^/'/" -e "s/\$/'/"
+    done
+}
+
 usage() {
     echo >&2 'usage: git bisect [start|bad|good|next|reset|visualize]
-git bisect start		reset bisect state and start bisection.
+git bisect start [<pathspec>]	reset bisect state and start bisection.
 git bisect bad [<rev>]		mark <rev> a known-bad revision.
 git bisect good [<rev>...]	mark <rev>... known-good revisions.
 git bisect next			find next bisection to test and check it out.
@@ -56,8 +63,8 @@ bisect_start() {
 	rm -f "$GIT_DIR/refs/heads/bisect"
 	rm -rf "$GIT_DIR/refs/bisect/"
 	mkdir "$GIT_DIR/refs/bisect"
-	echo "git-bisect start $@" >"$GIT_DIR/BISECT_LOG"
-	echo "$@" > "$GIT_DIR/BISECT_NAMES"
+	sq git-bisect start "$@" >"$GIT_DIR/BISECT_LOG"
+	sq "$@" >"$GIT_DIR/BISECT_NAMES"
 }
 
 bisect_bad() {
@@ -142,7 +149,8 @@ bisect_next() {
 
 bisect_visualize() {
 	bisect_next_check fail
-	gitk bisect/bad --not `cd "$GIT_DIR/refs" && echo bisect/good-*` -- $(cat $GIT_DIR/BISECT_NAMES)
+	not=`cd "$GIT_DIR/refs" && echo bisect/good-*`
+	eval gitk bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
 }
 
 bisect_reset() {
---
0.99.9.GIT
Junio C Hamano· Nov 28, 2005, 02:12 UTC · re: Junio C Hamano · lore

Re: [PATCH] bisect: quote pathnames for eval safety.

Junio C Hamano <junkio@cox.net> writes:
Show 8 quoted lines
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> Almost totally untested, and I guarantee that if your pathnames have 
>> spaces in them (or your GIT_DIR has spaces in it) this won't work. I don't 
>> know how to fix that, my shell programming isn't good enough.
>
> Like this?  I've placed the bisect patch with this in the
> proposed updates.
Not like that ;-).  Fixed one is in pu.
Martin Atukunda· Nov 29, 2005, 06:42 UTC · re: Junio C Hamano · lore

Re: [PATCH 0/4] Repository format version check series.

On Fri, Nov 25, 2005 at 05:15:02PM -0800, Junio C Hamano wrote:
Show 8 quoted lines
> This series is what I've been cooking for the past several days,
> partly based on patch from Martin Atukunda but with hopefully
> smaller impact.
> 
> [PATCH 1/4] Repository format version check.
> [PATCH 2/4] Check repository format version in enter_repo().
> [PATCH 3/4] init-db: check template and repository format.
> [PATCH 4/4] setup_git_directory(): check repository format version.

This is just to confirm that this patch series passed the tests on my end. Good work.

- Martin -
-- 
Due to a shortage of devoted followers, the production of great leaders has been discontinued.

← back to recent threads