Nicolas Pitre <nico@xxxxxxx> writes:
> You're making assumption about work flows and using that to justify
> command implementation flaws. This is not exactly "user friendly".
I do not necessarily agree that making the command to follow a
BCP workflow is "user unfriendly", but that does not pertain
what I will end up saying in this message, which is to agree
with you.
> But a command that is called "status" should provide a "status" even if
> the file system is read-only nevertheless. The index updating business
> that is done behind the scene is and should be an opportunistic
> optimization, but it should not prevent status reporting.
Fair enough. That leaves us two options.
(0) Do nothing.
(1) We keep the current "git-status [-v] [-a] [[-i|-o] <paths...>]"
command line and do the necessary index manipulation
in-core without writing it out (see git-commit.sh for
details of what it involves).
(2) We drop the support for any command line parameter from
"git-status", apply my two patches for Marco to
"git-runstatus", and rename "git-runstatus" to
"git-status".
If I have to pick between the two, I would probably pick (2).
While (1) would essentially mean doing "git-commit" entirely
in-core without writing the index out until we really make the
commit, which is a good thing in itself in the longer term, it
is out of the question this late in the game for 1.5.0.
And now I think what Linus suggests also make sense -- we could
tweak (2) so that git-runstatus actually writes the refreshed
index out when it finds that it _can_ write it (and drop
subsequent internal refresh).
Now, I am heading out.
-
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