git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
May 27, 2008, 20:51 UTC
Message-ID
<7vwslfzd0i.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<alpine.DEB.1.00.0805271411520.30431@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 8 quoted lines
>> > 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.

Previous: Junio C HamanoNext: Santi Béjar
Message 10 of 14 in “git-what: explain what to do next”
  1. git-what: explain what to do nextSanti Béjar, May 27, 2008
  2. Johannes SchindelinMay 27, 2008
  3. Santi BéjarMay 27, 2008
  4. Johannes SchindelinMay 27, 2008
  5. Santi BéjarMay 27, 2008
  6. Stephen R. van den BergMay 27, 2008
  7. Santi BéjarMay 27, 2008
  8. Steven WalterMay 27, 2008
  9. Junio C HamanoMay 27, 2008
  10. Junio C HamanoMay 27, 2008
  11. Santi BéjarMay 28, 2008
  12. Christian CouderMay 29, 2008
  13. Junio C HamanoMay 29, 2008
  14. Jon LoeligerMay 29, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.