From: Jeff King <peff@peff.net>
Date: Mon, 05 Jul 2010 20:56:52 GMT
Subject: Re: 'git commit --short' without touching index?
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:

> 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