git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: "Robin H. Johnson" <robbat2@gentoo.org>,
	"Marc Branchaud" <marcnarc@xiplink.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Michał Górny" <mgorny@gentoo.org>, "Jeff King" <peff@peff.net>,
	"Lars Schneider" <larsxschneider@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [RFC PATCH] checkout: Force matching mtime between files
Date: Mon, 30 Apr 2018 08:56:15 +0900	[thread overview]
Message-ID: <xmqqpo2hzhwg.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180426184411.GA6844@duynguyen.home> (Duy Nguyen's message of "Thu, 26 Apr 2018 20:44:11 +0200")

Duy Nguyen <pclouds@gmail.com> writes:

> Target revision should be available in the index. But this gives me an
> idea to another thing that bugs me: sending the list to the hook means
> I have to deal with separator (\n or NUL?) or escaping. This mentions
> of index makes me take a different direction. I could produce a small
> index that contains just what is modified, then you can retrieve
> whatever info you want with `git ls-files` or even `git show` after
> pointing $GIT_INDEX_FILE to it.

That's somewhere in between a tail wagging the dog and a hammer
looking like a solution even when you have a screw.  By passing a
temporary index, you may be able to claim that you are feeding the
necessary information without corruption and in a readable and
native format of Git, and make it up to the reader to grab the paths
out of it, but

 (1) the contents, and probably the cached stat information, in that
     temporary index is duplicated and wasted; you know from the
     time you design this thing that all you want to convey is a
     list of paths.

 (2) it is totally unclear who is responsible for cleaning the
     temporary file up.

 (3) the recipient must walk and carefully grab the path, certainly
     has to "deal with separator (\n or NUL?) or escaping" anyway,
     especially if the reason you use a temporary index is because
     "they can use ls-files on it".  They need to read from ls-files
     anyway, so that is no better than feeding ls-files compatible
     input from the standard input of the hook script.

no?

  reply	other threads:[~2018-04-29 23:56 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 17:01 [RFC PATCH] checkout: Force matching mtime between files Michał Górny
2018-04-23 20:07 ` Robin H. Johnson
2018-04-23 23:41   ` Junio C Hamano
2018-04-25  7:13     ` Robin H. Johnson
2018-04-25  8:48       ` Junio C Hamano
2018-04-25 15:18         ` Marc Branchaud
2018-04-25 20:07           ` Robin H. Johnson
2018-04-26  1:25           ` Junio C Hamano
2018-04-26 14:12             ` Marc Branchaud
2018-04-26 14:46             ` Michał Górny
2018-04-28 14:23               ` Duy Nguyen
2018-04-28 19:35                 ` Michał Górny
2018-04-26 16:43           ` Duy Nguyen
2018-04-26 17:48             ` Robin H. Johnson
2018-04-26 18:44               ` Duy Nguyen
2018-04-29 23:56                 ` Junio C Hamano [this message]
2018-04-30 15:10                   ` Duy Nguyen
2018-04-27 17:03           ` Duy Nguyen
2018-04-27 21:08             ` Elijah Newren
2018-04-28  6:08               ` Duy Nguyen
2018-04-29 23:47               ` Junio C Hamano
2018-04-27 21:08             ` Marc Branchaud
2018-04-28  6:16               ` Duy Nguyen
2018-04-27 17:18           ` Michał Górny
2018-04-27 19:53             ` Ævar Arnfjörð Bjarmason
2018-04-25  8:41     ` Ævar Arnfjörð Bjarmason
2018-04-26 17:15       ` Duy Nguyen
2018-04-26 17:51         ` Robin H. Johnson
2018-04-26 17:53         ` SZEDER Gábor
2018-04-26 18:45           ` Duy Nguyen
2018-04-24 14:41 ` Marc Branchaud
2018-04-25  6:58 ` Robin H. Johnson
2018-04-25  7:13   ` Michał Górny
2018-05-05 18:44 ` Jeff King
2018-05-06  3:37   ` 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

  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=xmqqpo2hzhwg.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=larsxschneider@gmail.com \
    --cc=marcnarc@xiplink.com \
    --cc=mgorny@gentoo.org \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=robbat2@gentoo.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.
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).