From: Jeff King <peff@peff.net>
To: Thomas Gummerer <t.gummerer@gmail.com>
Cc: "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, 1 Sep 2016 17:58:10 -0400 [thread overview]
Message-ID: <20160901215810.ez47lqwmfmahyvc7@sigill.intra.peff.net> (raw)
In-Reply-To: <20160901200700.GA8254@hank>
On Thu, Sep 01, 2016 at 09:07:00PM +0100, Thomas Gummerer wrote:
> > Related problem: `t3700-add.sh` currently fails in 2.9.3. I can
> > provide more debug information if you don't already know this problem.
>
> I noticed this problem as well, when I'm compiling with USE_NSEC = 1
> in my config.mak.
I can replicate this even without USE_NSEC with my stress-tester[1].
That makes sense why it would show up with the profiling run; git runs
slower and therefore increases the chances of crossing the 1-second
boundary and losing the race.
[1] https://github.com/peff/git/blob/meta/stress
> Tracking this problem down a bit, it happens because the --chmod=[+-]x
> option introduced in 4e55ed32 ("add: add --chmod=+x / --chmod=-x
> options") only works if the file on disk is modified. When the test
> was changed to work on one single file, instead of doing chmod=+x on
> one file and chmod=-x on another file in b38ab197c ("t3700: merge two
> tests into one"), this test started breaking when the mtime of the
> file and the index file weren't the same (in other words, if the file
> was not racily clean and thus was not smudged).
That certainly sounds buggy. A less racy way of verifying this is just:
# guarantee not-racy state
echo content >file
test-chmtime -60 file
git add file
# now check --chmod; file will still be 100644!
git add --chmod=+x file
git ls-files -s
> One possible fix for the test is to smudge the entry as showed below,
> though I'm not sure it's the right fix. The other way I can think of
> is to change the file in the index regardless of whether the file was
> changed in some other way before issuing the git add command, as that
> might fit the user expectation better. Thoughts?
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.
-Peff
next prev parent reply other threads:[~2016-09-01 21:58 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 [this message]
2016-09-01 22:16 ` Junio C Hamano
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=20160901215810.ez47lqwmfmahyvc7@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=ethomson@edwardthomson.com \
--cc=git@vger.kernel.org \
--cc=ib@wupperonline.de \
--cc=janx@linux.com \
--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).