Re: [RFC/PATCH] git-what: explain what to do next

Johannes Schindelin [off-list ref] writes:

quoted

quoted

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.

On Tue, May 27, 2008 at 10:51 PM, Junio C Hamano [off-list ref] wrote:

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.

This is the job of the git-what, so it first call "git rebase --what"
and then "git am --what", and the individual "git cmd --what" can be
declared internal.

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.

I think it does, it is exactly what my patch does, IMHO.

Santi