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

Re: [PATCH] user-manual: mention git gui citool (commit, amend)

From
Steffen Prohaska <prohaska@zib.de>
Date
Aug 5, 2007, 12:26 UTC
Message-ID
<D17F92F4-3FF9-46CD-9E55-449C07DE2820@zib.de>
In-Reply-To
<20070804062010.GQ20052@spearce.org>
On Aug 4, 2007, at 8:20 AM, Shawn O. Pearce wrote:
Show 11 quoted lines
>>
>> Though I'd like to keep the main body of the manual focused on the  
>> major
>> command line tools, I'd have no objection to a separate chapter (or
>> appendix?) devoted to git-gui; then you could point directly at that.
>> Would that make sense?
>
> Yea, that makes a lot of sense.  git-gui isn't a full replacement
> for the command line anyway, so I would never suggest a wholesale
> rewrite of the user manual to slant the entire thing towards git-gui.
> Doing so would only point out the many shortcomings in git-gui.  :)
I partially disagree.

When users start to learn git they are mostly interested in how to achieve a specific goal, e.g. how to create a commit. I think most users either accept a command line or a gui, whatever is the easiest and fastest way to do something.

I strongly believe that the sections in the manual should be organized along the tasks that users want to solve and discuss available approaches. Obviously each chapter should start with simple tasks and simple tools (the commandline) and only later add advanced usage scenarios. But I don't think it makes sense to put git gui into a separate chapter.

I personally use the command line for most of my work, but for adding single diff hunks to the index I use git gui. It's much simple than 'git add -i'.

In the chapter on history browsing, the manual pretty early states

"The best way to see how this works is using the gitk(1) command; running gitk now on a git repository and looking for merge commits will help understand how the git organizes history."

which makes absolutely sense to me. If a gui is the best tool to do the job 'understanding history', then there's no reason to first restrict the manual to the command line tools, like 'git log'.

	Steffen
Previous: J. Bruce Fields
Message 34 of 34 in “user-manual: mention git gui citool (commit, amend)”
  1. user-manual: mention git gui citool (commit, amend)Steffen Prohaska, Jul 30, 2007
  2. Shawn O. PearceJul 31, 2007
  3. J. Bruce FieldsAug 2, 2007
  4. Steffen ProhaskaAug 2, 2007
  5. J. Bruce FieldsAug 2, 2007
  6. Steffen ProhaskaAug 3, 2007
  7. J. Bruce FieldsAug 3, 2007
  8. user-manual: mention git gui citool (commit, amend)Steffen Prohaska, Aug 5, 2007
  9. Johannes SchindelinAug 5, 2007
  10. Steffen ProhaskaAug 5, 2007
  11. Johannes SchindelinAug 5, 2007
  12. David KastrupAug 5, 2007
  13. Steffen ProhaskaAug 5, 2007
  14. Johannes SchindelinAug 6, 2007
  15. Steffen ProhaskaAug 6, 2007
  16. Steven GrimmAug 6, 2007
  17. Johannes SchindelinAug 6, 2007
  18. J. Bruce FieldsAug 5, 2007
  19. J. Bruce FieldsAug 5, 2007
  20. Johannes SchindelinAug 6, 2007
  21. J. Bruce FieldsAug 6, 2007
  22. Robin RosenbergAug 6, 2007
  23. J. Bruce FieldsAug 6, 2007
  24. Shawn O. PearceAug 3, 2007
  25. J. Bruce FieldsAug 3, 2007
  26. Shawn O. PearceAug 4, 2007
  27. Steffen ProhaskaAug 5, 2007
  28. Junio C HamanoAug 3, 2007
  29. Shawn O. PearceAug 3, 2007
  30. J. Bruce FieldsAug 3, 2007
  31. Shawn O. PearceAug 4, 2007
  32. David KastrupAug 4, 2007
  33. J. Bruce FieldsAug 4, 2007
  34. Steffen ProhaskaAug 5, 2007

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.