Re: 'git commit --short' without touching index?

From: Jeff King <peff@peff.net>
Date: Jul 5, 2010, 20:56 UTC
Message-ID: <20100705205651.GA32728@sigill.intra.peff.net>
In-Reply-To: <7veifhy9j0.fsf@alter.siamese.dyndns.org>

On Mon, Jul 05, 2010 at 01:10:43PM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > It would be nice if the index-refreshing code only wrote to the index if
> > there was something worth writing. I'm not sure how hard that would be
> > to implement, though.
> 
> Hmm, don't we already do that with "istate->cache_changed"?

Apparently not:

  $ stat .git/index | grep -i modify
  Modify: 2010-07-05 16:52:11.000000000 -0400
  $ git status
  # On branch master
  nothing to commit
  $ stat .git/index | grep -i modify
  Modify: 2010-07-05 16:53:09.000000000 -0400

and it is not just updating some stat-dirtiness. Doing it over and over will keep updating the index. It looks like we unconditionally do the lock and write in cmd_status, but I haven't looked further.

> In any case, we should diagnose "commit --short" (and "--procelain") as an
> error, perhaps by splitting option parsers for commit and status further.

I don't think it's an error. "commit --short" implies "commit --dry-run --short", which is actually a useful thing (well, _I_ don't find it useful, but I believe it was kept intentionally during the "status is no longer commit --dry-run" conversion).

-Peff