Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:49:05

On Mon, Jul 05, 2010 at 01:10:43PM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help