On Fri, Nov 11, 2011 at 04:11:29PM -0800, Junio C Hamano wrote: > > 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html