git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Dmitry Ivankov <divanorama@gmail.com>
Cc: git@vger.kernel.org, David Barr <davidbarr@google.com>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	Andrew Sayers <andrew-git@pileofstuff.org>,
	Sverre Rabbelier <srabbelier@gmail.com>
Subject: Re: [PATCH 1/2] fast-import: be saner with temporary trees
Date: Thu, 8 Mar 2012 13:12:00 -0600	[thread overview]
Message-ID: <20120308191200.GA17903@burratino> (raw)
In-Reply-To: <1313489337-2523-2-git-send-email-divanorama@gmail.com>

Hi,

Dmitry Ivankov wrote:

> new_tree_entry/release_tree_entry manage a stack of tree_entry structs
> to use as temporaries. Initializing them is the responsibility of the
> caller,
[...]
> Do initialize entry->versions[0]. As of now, ls command can not list
> the topmost tree so this change is just to avoid surprises in case
> things will change around ls or tree_content_get.
>
> Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
> Acked-by: Jonathan Nieder <jrnieder@gmail.com>
[...]
> +++ b/fast-import.c
> @@ -2951,6 +2951,9 @@ static void parse_ls(struct branch *b)
>  	} else {
>  		struct object_entry *e = parse_treeish_dataref(&p);
>  		root = new_tree_entry();
> +		hashclr(root->versions[0].sha1);
> +		root->versions[0].mode = 0;
> +		root->versions[1].mode = S_IFDIR;
>  		hashcpy(root->versions[1].sha1, e->idx.sha1);

I don't remember what this patch was about or why I acked it, which is
a bad sign.  (If the above explanation doesn't make me want to ack it
again, how is it going to help someone in the future understand the
harm in reverting this patch if some other bug bisects to it?)

I think part of the problem is that the explanation seems to be
phrased in terms of implementation details (root->versions[0] fields,
calling store_tree, initializing entry->versions[0]) instead of the
higher-level logic that these implement.

It sounds ("avoid surprises") like this is meant to avoid scary
behavior from the programmer's perspective, so: what are the symptoms
without this patch, and why is this a good way to eliminate them?

On the other hand, if we squash this in with David's [1], it starts
to make perfect sense.  The explanation can say:

	There is a pathological Subversion operation that svn-fe handles
	incorrectly due to an unexpected response from fast-import:

	  svn cp $SVN_ROOT $SVN_ROOT/subdirectory

	When the following command is sent to fast-import:

	 'ls' SP ':1' SP LF

	The expected output is:

	 '040000' SP 'tree' SP <dataref> HT LF

	The actual output is:

	 'missing' SP LF

	This is because tree_content_get() is called but expects a non-empty
	path. Instead, copy the root entry and force the mode to S_IFDIR.

	In the 'ls <dataref> ""' case, this requires some care, because
	parse_ls currently uses an uninitialized temporary tree entry
	from the new_tree_entry/release_tree_entry stack in a quick and
	dirty way without initializing its fields well enough for
	functions like store_tree that might calculate its tree name.

Sensible?  Alternatively, we could rush in David's [1] with the
tweak below to dodge the 'ls <dataref> ""' case, and include your fix
as part of a patch that just addresses that case.

Thanks very much for the patch and the reminder.

Sincerely,
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/192517/focus=192520
---
 fast-import.c          |    2 +-
 t/t9300-fast-import.sh |   66 +++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/fast-import.c b/fast-import.c
index 8dbfd4cc..2748ced2 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -3019,7 +3019,7 @@ static void parse_ls(struct branch *b)
 			die("Garbage after path in: %s", command_buf.buf);
 		p = uq.buf;
 	}
-	if (*p) {
+	if (*p || root != &b->branch_tree) {
 		tree_content_get(root, p, &leaf);
 	} else {
 		leaf = *root;
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 2558a2ed..2f411fbb 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -1400,8 +1400,72 @@ test_expect_success \
 	 test_cmp expect.qux actual.qux &&
 	 test_cmp expect.qux actual.quux'
 
+test_expect_success 'N: root of unborn branch reads as present and empty' '
+	empty_tree=$(git mktree </dev/null) &&
+	echo "040000 tree $empty_tree	" >expect &&
+	git fast-import --cat-blob-fd=3 3>actual <<-EOF &&
+	commit refs/heads/N-empty
+	committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+	data <<COMMIT
+	read empty root directory via ls
+	COMMIT
+
+	ls ""
+	EOF
+	test_cmp expect actual
+'
+
+test_expect_success 'N: empty root reads as present and empty' '
+	empty_tree=$(git mktree </dev/null) &&
+	echo "040000 tree $empty_tree	" >expect &&
+	echo empty >msg &&
+	cmit=$(git commit-tree "$empty_tree" -p refs/heads/branch^0 <msg) &&
+	git fast-import --cat-blob-fd=3 3>actual <<-EOF &&
+	commit refs/heads/N-empty-existing
+	committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+	data <<COMMIT
+	read empty root directory via ls
+	COMMIT
+
+	ls ""
+	EOF
+	test_cmp expect actual
+'
+
+test_expect_success 'N: "ls" command can read subdir of named tree' '
+	branch_cmit=$(git rev-parse --verify refs/heads/branch^0) &&
+	subdir_tree=$(git rev-parse $branch_cmit:newdir) &&
+	echo "040000 tree $subdir_tree	newdir" >expect &&
+	git fast-import --cat-blob-fd=3 3>actual <<-EOF &&
+	commit refs/heads/N-subdir-of-named-tree
+	committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+	data <<COMMIT
+	read from commit with ls
+	COMMIT
+
+	ls $branch_cmit "newdir"
+	EOF
+	test_cmp expect actual
+'
+
+test_expect_failure 'N: "ls" command can read root of named commit' '
+	branch_cmit=$(git rev-parse --verify refs/heads/branch^0) &&
+	branch_tree=$(git rev-parse --verify $branch_cmit:) &&
+	echo "040000 tree $branch_tree	" >expect &&
+	git fast-import --cat-blob-fd=3 3>actual <<-EOF &&
+	commit refs/heads/N-root-of-named-tree
+	committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+	data <<COMMIT
+	read root of commit with ls
+	COMMIT
+
+	ls $branch_cmit ""
+	EOF
+	test_cmp expect actual
+'
+
 test_expect_success PIPE 'N: read and copy root' '
-	cat >expect <<-\EOF
+	cat >expect <<-\EOF &&
 	:100755 100755 f1fb5da718392694d0076d677d6d0e364c79b0bc f1fb5da718392694d0076d677d6d0e364c79b0bc C100	file2/newf	file3/file2/newf
 	:100644 100644 7123f7f44e39be127c5eb701e5968176ee9d78b1 7123f7f44e39be127c5eb701e5968176ee9d78b1 C100	file2/oldf	file3/file2/oldf
 	:100755 100755 85df50785d62d3b05ab03d9cbf7e4a0b49449730 85df50785d62d3b05ab03d9cbf7e4a0b49449730 C100	file4	file3/file4
-- 
1.7.9.2

  reply	other threads:[~2012-03-08 19:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-16 10:08 [PATCH 0/2] fast-import: allow more operations on root directory Dmitry Ivankov
2011-08-16 10:08 ` [PATCH 1/2] fast-import: be saner with temporary trees Dmitry Ivankov
2012-03-08 19:12   ` Jonathan Nieder [this message]
2011-08-16 10:08 ` [PATCH 2/2] fast-import: allow top directory as an argument for some commands Dmitry Ivankov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120308191200.GA17903@burratino \
    --to=jrnieder@gmail.com \
    --cc=andrew-git@pileofstuff.org \
    --cc=davidbarr@google.com \
    --cc=divanorama@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    --cc=srabbelier@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).