git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

  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).