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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 12, 2011, 00:11 UTC
Message-ID: <7vhb2aqjwu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20111111182109.GB16055@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> On Fri, Nov 11, 2011 at 08:43:34AM -0800, Junio C Hamano wrote:
>
> I agree the naming is awkward (but then, I think the "needs update"
> message is awkward ;) ). But my interpretation was: if you want the
> index to be in sync with the working tree, you must do this. Hence:
>
>   $EDITOR file             ;# triggers needs_update
>   git update-index file    ;# and do update in index
>   rm file                  ;# triggers needs rm
>   git rm --cached file     ;# and do rm in index

The word "update" at the plumbing level simply means "update the path in the index". At the Porcelain level you have to use "git add" or "git rm" depending on different kind of "needs update", which may be argued an inconsistency, but at the plumbing level everything is done with the same update-index command, and "needs update" is the word that matches your interpretation.

I however think the topic was about updating the Porclain-ish output that is similar to "status -s" output. And at that level, paths marked with M/T and D are dealt differently by end users ("add" vs "rm").

And the ? : expressions the patch is touching is about mapping the state of the path to your "you must do this" interpretation. What is being mapped is the state, so it would be more natural to have the variable "modified_fmt" hold the result of the mapping "you must do...", instead of calling the variable in terms of "you must do this if you were working at the plumbing level", which is where the original needs_update_fmt naming comes from.

Show 6 quoted lines

>> An obvious solution would be to rename all of them to be based on "what
>> happened to the path". E.g. "modified_fmt" would be set to either "M" or
>> "needs update", and "removed_fmt" would be set to either "D" or "needs
>> update", etc.
>
> 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.

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