git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Subject: Re: [PATCH v2 3/3] archive: do not read .gitattributes in working  directory
Date: Thu, 9 Apr 2009 20:53:27 +1000	[thread overview]
Message-ID: <fcaeb9bf0904090353s4ec770bfk3cd3f6559c367a20@mail.gmail.com> (raw)
In-Reply-To: <7vws9u2ov4.fsf@gitster.siamese.dyndns.org>

2009/4/9 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>
>> @@ -168,6 +171,22 @@ int write_archive_entries(struct archiver_args *args,
>>       context.args = args;
>>       context.write_entry = write_entry;
>>
>> +     /*
>> +      * Setup index and instruct attr to read index only
>> +      */
>> +     if (!args->worktree_attributes) {
>> +             memset(&opts, 0, sizeof(opts));
>> +             opts.index_only = 1;
>> +             opts.head_idx = -1;
>> +             opts.src_index = &the_index;
>> +             opts.dst_index = &the_index;
>> +             opts.fn = oneway_merge;
>> +             init_tree_desc(&t, args->tree->buffer, args->tree->size);
>> +             if (unpack_trees(1, &t, &opts))
>> +                     return -1;
>> +             git_attr_set_direction(GIT_ATTR_INDEX, &the_index);
>
> Why use unpack_trees with oneway_merge?  You won't be doing "is this file
> up-to-date in the work tree?", and you won't be writing the index out
> either, so there is nothing gained by keeping the cached stat information
> fresh, which is the major justification of using that mechanism.  I think
> using tree.c::read_tree() would be more appropriate.

Because I'm more familiar with unpack stuff than read-tree (or to be
honest, haven't touched tree stuff at all). Will look at read_tree().

>> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
>> index 0713bca..69a93fc 100644
>> --- a/builtin-tar-tree.c
>> +++ b/builtin-tar-tree.c
>> @@ -36,6 +36,11 @@ int cmd_tar_tree(int argc, const char **argv, const char *prefix)
>>               argv++;
>>               argc--;
>>       }
>> +     if (2 <= argc && !strcmp(argv[1], "--fix-attributes")) {
>> +             nargv[nargc++] = argv[1];
>> +             argv++;
>> +             argc--;
>> +     }
>
> I am not sure if it is worth backporting this new option to tar-tree which
> is an essentially backward-compatibility interface, and worse yet, doing
> it poorly (i.e. --fix-attributes must come after --remote= for unexplained
> reason).

It's because git-tar-tree is used in tests and I don't want to migrate
all to git-archive. I don't want to change too much in a deprecated
command. Maybe just remove the option and make --fix-attributes
default for git-tar-tree. In other words, keep git-tar-tree's current
behaviour.

> It would affect a bit more tests, but I think you would want to test both
> the new "normal" mode of operation (generate archives with "git archive"
> and "git tar-tree" without options and compare, for example), instead of
> adding --fix-attributes everywhere.

There is a new test to test the new "normal" mode. I'll think of more.
-- 
Duy

  reply	other threads:[~2009-04-09 10:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-09  7:01 [PATCH v2 0/3] support "in-tree attributes" for git-archive Nguyễn Thái Ngọc Duy
2009-04-09  7:01 ` [PATCH v2 1/3] archive: add shortcuts for --format and --prefix Nguyễn Thái Ngọc Duy
2009-04-09  7:01   ` [PATCH v2 2/3] attr: add GIT_ATTR_INDEX "direction" Nguyễn Thái Ngọc Duy
2009-04-09  7:01     ` [PATCH v2 3/3] archive: do not read .gitattributes in working directory Nguyễn Thái Ngọc Duy
2009-04-09  8:49       ` Junio C Hamano
2009-04-09 10:53         ` Nguyen Thai Ngoc Duy [this message]
2009-04-11 19:22           ` Junio C Hamano
2009-04-13 10:41           ` René Scharfe
2009-04-13 12:18             ` René Scharfe
2009-04-13 13:08               ` René Scharfe
2009-04-14  5:11                 ` Junio C Hamano
2009-04-14 21:15                   ` René Scharfe
2009-04-16  0:26                     ` Junio C Hamano
2009-04-09  8:47   ` [PATCH v2 1/3] archive: add shortcuts for --format and --prefix Junio C Hamano
2009-04-09 10:38     ` Nguyen Thai Ngoc Duy

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=fcaeb9bf0904090353s4ec770bfk3cd3f6559c367a20@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=rene.scharfe@lsrfire.ath.cx \
    /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).