Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> > However, I think it would make sense to push for that >> > .dotest,.git/.dotest-merge -> .git/rebase change _before_ having >> > anything like git-whazzup.sh. >> >> That's a problem of the single command approach. > > Sure it is. But cluttering up the commands for something that is not > really proven to be wanted by many is IMO inferior. I do not necessarily see them as cluttering, although I'd agree that changes to some scripts may look a bit too intrusive. You _could_ argue that the handling of --what option is part of the protocol for commands that want to implement a workflow with sequencing elements, just like we have a protocol for commands that want to work from a subdirectory is to call setup_git_directory() to have it cd up to the top of the work tree and prepend the prefix to all user supplied paths. However, that new protocol this patch introduces need to be documented clearly. It's the new contract "git-what" wants to impose on commands with sequencing elements. But a problem I see with the patch as an implementation of "git-what" is that some commands use other commands as their internal implementation details. For example, when you are in the middle of a "git rebase" session, which might be using "git am" as its internal implementation detail, if you ask the "are you in the middle of doing something, and if so how can I continue?" question (which is what the "git-cmd --what" is all about) to "git am", before you ask the same question to "git rebase", "am" could say "Yeah, I have applied a few patches successfully but gave control back to the user to resolve conflicts while applying this patch", which may be a truthful statement from "git am"'s point of view, but is not a useful information from the end user's point of view, as all s/he typed was "git rebase". In addition, if Porcelain X uses Porcelain Y as its internal implementation, the series of commands that need to be followed to continue from a particular sequence point might be different between the case where the toplevel request was Y and the case where it was X. Not just X needs to know that it uses Y, Y also needs to know that the toplevel command the end user gave could be X which called it and behave differently. So a nice "each command knows what its doing" separation cannot really solve everything in practice. In other words, "git-X --what" could give a guidance to the "I've done X, now what can I do?" situation, but it by itself cannot be used as a basis of "git-what" to answer "I'm totally lost and I do not know what I was doing. Where was I and what should I do next?" question. -- 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
