Re: reset reports file as modified when it's in fact deleted

From: Jeff King <peff@peff.net>
Date: Nov 14, 2011, 22:50 UTC
Message-ID: <20111114225056.GA27370@sigill.intra.peff.net>
In-Reply-To: <7vhb2aqjwu.fsf@alter.siamese.dyndns.org>

On Fri, Nov 11, 2011 at 04:11:29PM -0800, Junio C Hamano wrote:

Show 11 quoted lines

> > I'm happy to make that change. What do you think of the feature overall?
> 
> The "feature" is more or less "Meh" to me; I do not mind differentiating M
> and D there because the necessary information is already there in the
> codepath, but if we were to really do that, then the variables must be
> renamed. We shouldn't name them after "you must do this at the plumbing
> level" like we have done so far, and instead use "the path is in this
> state". This is even more so if we were to further split a single "state"
> that plumbing layer considers the same and gives the same "needs X" to
> different states that Porcelains would give different messages in the
> future.

I admit I don't care all that much either, but it's easy to do, and I think it is less surprising to users. Patches are below.

Show 6 quoted lines

> > And should typechanges also be handled here (it's no extra work for git
> > to detect them; we just have to pass the TYPE_CHANGED flag back up the
> > stack)?
> 
> As long as "pass ... back up the stack" does not result in too much
> ugliness in the code, I am OK with it.

It ended up pretty simple, but I split it out from the deletion case so you can see it more clearly (and can drop the latter half of the series if we don't want it).

  [1/4]: refresh_index: rename format variables
  [2/4]: refresh_index: mark deletions in porcelain output
  [3/4]: read-cache: let refresh_cache_ent pass up changed flags
  [4/4]: refresh_index: notice typechanges in output

(If I were sure we wanted the typechange output, I think a more reasonable ordering would be 1, then 3, then squash 2 and 4 into a single patch. But see my comment in 4/4).

-Peff