git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>
Cc: "Miklos Vajna" <vmiklos@frugalware.org>,
	"Junio C Hamano" <gitster@pobox.com>, "Jeff King" <peff@peff.net>,
	"Karl Chen" <quarl@cs.berkeley.edu>,
	git@vger.kernel.org
Subject: Re: [PATCH] git diff/diff-index/diff-files: call setup_work_tree()
Date: Tue, 26 Aug 2008 16:58:09 -0700	[thread overview]
Message-ID: <7vprnvuy5q.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <fcaeb9bf0808250826l2f1a0f3l94fff1b702e69c5d@mail.gmail.com> (Nguyen Thai Ngoc Duy's message of "Mon, 25 Aug 2008 22:26:07 +0700")

"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:

> On 8/25/08, Miklos Vajna <vmiklos@frugalware.org> wrote:
>>  diff --git a/builtin-diff.c b/builtin-diff.c
>>
>> index 7ffea97..57da6ed 100644
>>
>> --- a/builtin-diff.c
>>  +++ b/builtin-diff.c
>>
>> @@ -279,6 +279,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
>>         diff_no_index(&rev, argc, argv, nongit, prefix);
>>
>>         /* Otherwise, we are doing the usual "git" diff */
>>  +       setup_work_tree();
>>         rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
>>
>>         if (nongit)
>
> At least builtin_diff_blobs() and builtin_diff_tree() won't need
> worktree, so NACK again. Anyway I'm not familiar with diff*. Junio
> should know these better.

How about doing it this way then?

 * diff-files is about comparing with work tree, so it obviously needs a
   work tree;

 * diff-index also does;

 * no-index is about random files outside git context, so it obviously
   doesn't need any work tree;

 * comparing two (or more) trees doesn't;

 * comparing two blobs doesn't;

 * comparing a blob with a random file doesn't;

What could be problematic is "git diff --cached".  Strictly speaking, it
compares the index and a tree so it shouldn't need any work tree.  The
same obviously applies to "git diff-index --cached".

While it is theoretically possible to have an index in a bare repository
and build your history using it without using any worktree, I do not think
it is a use case worth worrying about.  As long as setup_work_tree() does
not complain and die in such a setup, "diff --cached" itself won't look at
the work tree (whereever random place setup_work_tree() sets it) at all,
so probably it is a non issue.  I dunno.

I do not have a test environment that uses a separate worktree settings,
so this is obviously untested.

Perhaps people who are interested in keeping core.worktree alive can add
test scripts in t/ somewhere to help salvaging the feature?

---

 builtin-diff.c |    3 +++
 git.c          |    4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git i/builtin-diff.c w/builtin-diff.c
index 7ffea97..06c85da 100644
--- i/builtin-diff.c
+++ w/builtin-diff.c
@@ -114,6 +114,8 @@ static int builtin_diff_index(struct rev_info *revs,
 			      int argc, const char **argv)
 {
 	int cached = 0;
+
+	setup_work_tree();
 	while (1 < argc) {
 		const char *arg = argv[1];
 		if (!strcmp(arg, "--cached"))
@@ -207,6 +209,7 @@ static int builtin_diff_files(struct rev_info *revs, int argc, const char **argv
 	int result;
 	unsigned int options = 0;
 
+	setup_work_tree();
 	while (1 < argc && argv[1][0] == '-') {
 		if (!strcmp(argv[1], "--base"))
 			revs->max_count = 1;
diff --git i/git.c w/git.c
index 37b1d76..a8e730d 100644
--- i/git.c
+++ w/git.c
@@ -286,8 +286,8 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "count-objects", cmd_count_objects, RUN_SETUP },
 		{ "describe", cmd_describe, RUN_SETUP },
 		{ "diff", cmd_diff },
-		{ "diff-files", cmd_diff_files, RUN_SETUP },
-		{ "diff-index", cmd_diff_index, RUN_SETUP },
+		{ "diff-files", cmd_diff_files, RUN_SETUP | NEED_WORK_TREE },
+		{ "diff-index", cmd_diff_index, RUN_SETUP | NEED_WORK_TREE },
 		{ "diff-tree", cmd_diff_tree, RUN_SETUP },
 		{ "fast-export", cmd_fast_export, RUN_SETUP },
 		{ "fetch", cmd_fetch, RUN_SETUP },

  reply	other threads:[~2008-08-26 23:59 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-22  4:14 [PATCH] Support "core.excludesfile = ~/.gitignore" Karl Chen
2008-08-22 16:58 ` Eric Raible
2008-08-22 17:56   ` Bert Wesarg
2008-08-22 21:10 ` Junio C Hamano
2008-08-24  8:40   ` Karl Chen
2008-08-24 18:11     ` Junio C Hamano
2008-08-24 22:08       ` Jeff King
2008-08-24 22:59         ` Junio C Hamano
2008-08-24 23:13           ` Jeff King
2008-08-24 23:40             ` Junio C Hamano
2008-08-24 23:51               ` limiting relationship of git dir and worktree (was Re: [PATCH] Support "core.excludesfile = ~/.gitignore") Jeff King
2008-08-25  0:30                 ` Dropping core.worktree and GIT_WORK_TREE support (was Re: limiting relationship of git dir and worktree) Junio C Hamano
2008-08-25  2:00                   ` Miklos Vajna
2008-08-25  3:05                     ` Dropping core.worktree and GIT_WORK_TREE support Junio C Hamano
2008-08-25 12:52                       ` Miklos Vajna
2008-08-25 13:52                         ` Nguyen Thai Ngoc Duy
2008-08-25 14:43                           ` [PATCH] git diff/diff-index/diff-files: call setup_work_tree() Miklos Vajna
2008-08-25 14:46                             ` Nguyen Thai Ngoc Duy
2008-08-25 14:50                               ` Miklos Vajna
2008-08-25 15:11                                 ` Miklos Vajna
2008-08-25 15:26                                   ` Nguyen Thai Ngoc Duy
2008-08-26 23:58                                     ` Junio C Hamano [this message]
2008-08-28 13:02                                       ` [PATCH] diff*: fix worktree setup Nguyễn Thái Ngọc Duy
2008-08-25 21:21                         ` Dropping core.worktree and GIT_WORK_TREE support Junio C Hamano
2008-08-25 21:37                           ` Miklos Vajna
2008-08-26  7:35                   ` Dropping core.worktree and GIT_WORK_TREE support (was Re: limiting relationship of git dir and worktree) Michael J Gruber
2008-08-27  0:49                     ` Jeff King
2008-08-25 19:07               ` [PATCH v2] Support "core.excludesfile = ~/.gitignore" Karl Chen
2008-08-26  6:42                 ` Johannes Sixt
2008-08-27  0:25                 ` Jeff King
2008-08-27  3:12                   ` Karl Chen
2008-08-27  5:01                     ` Junio C Hamano
2008-08-28  9:09                       ` [PATCH v3] Expand ~ and ~user in core.excludesfile, commit.template Karl Chen
2008-08-29  3:26                         ` Jeff King
2008-08-29  4:08                           ` Junio C Hamano
2008-08-29  9:29                             ` [PATCH v4] " Karl Chen
2008-08-29 16:08                               ` Junio C Hamano
2008-08-29 19:01                                 ` Karl Chen
2008-08-29 19:28                                   ` Junio C Hamano
2008-08-29 22:34                                     ` Karl Chen
2008-08-30  5:31                                       ` Junio C Hamano
2008-08-30  6:02                               ` Jeff King
2008-08-29  7:00                         ` [PATCH v3] " Johannes Sixt
2008-08-27  3:18                   ` [PATCH v2] Support "core.excludesfile = ~/.gitignore" Karl Chen
2008-08-27  4:50                     ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=7vprnvuy5q.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=quarl@cs.berkeley.edu \
    --cc=vmiklos@frugalware.org \
    /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.
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 NNTP newsgroup(s).