From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Thomas Gummerer" <t.gummerer@gmail.com>,
"Jan Keromnes" <janx@linux.com>,
git@vger.kernel.org, "Ingo Brückl" <ib@wupperonline.de>,
"Edward Thomson" <ethomson@edwardthomson.com>
Subject: Re: `make profile-install` fails in 2.9.3
Date: Thu, 01 Sep 2016 15:16:38 -0700 [thread overview]
Message-ID: <xmqqh99zuuyh.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160901215810.ez47lqwmfmahyvc7@sigill.intra.peff.net> (Jeff King's message of "Thu, 1 Sep 2016 17:58:10 -0400")
Jeff King <peff@peff.net> writes:
> Yeah, I think we should _always_ act on the --chmod, no matter if the
> file is racy or not, or whether it has a content change or not. I.e.,
> the race is not the problem, but rather the behavior of 4e55ed32. Your
> second proposal there sounds more like the right approach.
Yeah, you two are absolutely right. The second "git add --chmod=+x"
in
$ git add .
$ git add --chmod=+x .
should still find _all_ the non-executable paths and flip their
executable bit in the index, making them all up-to-date in the
index.
Which means that piggybacking this on the "run 'git diff' limited to
the pathspec to find the paths that needs updating" logic usually
done in "git add" can not be reused [*1*].
What was I thinking while reviewing the patch X-<. Sigh.
[Footnote]
*1* I guess we _could_, by first flipping all the regular file
blob's executable bit for paths that are inside the pathspec and
then by running "git diff" against that modified index, limited
to the pathspec, to find the paths that need to be added.
It sounds ugly, but may conceptually be cleaner. We first start
from an ideal end-result, and then re-hash what needs to be
updated to match the ideal.
next prev parent reply other threads:[~2016-09-01 22:16 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 16:08 `make profile-install` fails in 2.9.3 Jan Keromnes
2016-09-01 16:25 ` Dennis Kaarsemaker
2016-09-01 20:07 ` Thomas Gummerer
2016-09-01 21:58 ` Jeff King
2016-09-01 22:16 ` Junio C Hamano [this message]
2016-09-01 22:20 ` Jeff King
2016-09-01 22:38 ` Junio C Hamano
2016-09-04 11:39 ` [PATCH 0/4] git add --chmod: always change the file Thomas Gummerer
2016-09-04 11:39 ` [PATCH 1/4] add: document the chmod option Thomas Gummerer
2016-09-05 7:44 ` Johannes Schindelin
2016-09-05 19:22 ` Thomas Gummerer
2016-09-07 16:44 ` Junio C Hamano
2016-09-04 11:39 ` [PATCH 2/4] update-index: use the same structure for chmod as add Thomas Gummerer
2016-09-04 11:39 ` [PATCH 3/4] read-cache: introduce chmod_index_entry Thomas Gummerer
2016-09-04 11:39 ` [PATCH 4/4] add: modify already added files when --chmod is given Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 0/4] git add --chmod: always change the file Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 1/4] add: document the chmod option Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 2/4] update-index: use the same structure for chmod as add Thomas Gummerer
2016-09-11 22:28 ` Junio C Hamano
2016-09-12 19:30 ` Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 3/4] read-cache: introduce chmod_index_entry Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 4/4] add: modify already added files when --chmod is given Thomas Gummerer
2016-09-12 21:08 ` [PATCH v3 0/4] git add --chmod: always change the file Thomas Gummerer
2016-09-12 21:08 ` [PATCH v3 1/4] add: document the chmod option Thomas Gummerer
2016-09-12 21:08 ` [PATCH v3 2/4] update-index: use the same structure for chmod as add Thomas Gummerer
2016-09-12 21:59 ` Junio C Hamano
2016-09-12 21:08 ` [PATCH v3 3/4] read-cache: introduce chmod_index_entry Thomas Gummerer
2016-09-12 21:08 ` [PATCH v3 4/4] add: modify already added files when --chmod is given Thomas Gummerer
2016-09-12 22:23 ` Junio C Hamano
2016-09-14 21:07 ` [PATCH v4 0/4] git add --chmod: always change the file Thomas Gummerer
2016-09-14 21:07 ` [PATCH v4 1/4] add: document the chmod option Thomas Gummerer
2016-09-14 21:07 ` [PATCH v4 2/4] update-index: add test for chmod flags Thomas Gummerer
2016-09-14 21:07 ` [PATCH v4 3/4] read-cache: introduce chmod_index_entry Thomas Gummerer
2016-09-14 21:46 ` Junio C Hamano
2016-09-14 22:54 ` Junio C Hamano
2016-09-15 18:49 ` Thomas Gummerer
2016-09-14 21:07 ` [PATCH v4 4/4] add: modify already added files when --chmod is given Thomas Gummerer
2016-09-14 21:54 ` Junio C Hamano
2017-08-07 21:40 ` René Scharfe
2017-08-12 12:30 ` Thomas Gummerer
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=xmqqh99zuuyh.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=ethomson@edwardthomson.com \
--cc=git@vger.kernel.org \
--cc=ib@wupperonline.de \
--cc=janx@linux.com \
--cc=peff@peff.net \
--cc=t.gummerer@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).