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

Re: [PATCH 0/1] documentation: guide of best practices for GIT developer

From
Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>
Date
Apr 13, 2022, 14:36 UTC
Message-ID
<CAJyCBOS=xCEmX3yPduDEQfkVYUUiawQ7sYgNHi2dGe-R2W5r-g@mail.gmail.com>
In-Reply-To
<20220412202557.32101-1-cogoni.guillaume@gmail.com>

On Wed, Apr 13, 2022 at 7:29 AM COGONI Guillaume <cogoni.guillaume@gmail.com> wrote:

Show 6 quoted lines
>
> Hello,
>
> This patch has for purpose to introduce a file where GIT developers can share
> their own best practices, tools or workflows to the community in order to
> help the GIT developer.

Wouldn't there be a possibility that this doc can degrade into a list of personal taste? I think the rules that new developers *should* know have already been documented in 'MyFirstContribution.txt' or 'SubmittingPatches' and things like that. If there is a *common* recommended practice, if not "their own", I guess it can be added into existing documentations.

Show 12 quoted lines
> The discussion about this idea begin in this thread:
> Message-Id: <20220407204001.112287-2-cogoni.guillaume@gmail.com>
>
> Derrick Stolee and I agreed that is can be a good idea.
> And, I think, it can help a newcomer, but not necessarily people with a
> lot of experience on various projects. But, we can give it a try and
> see where it goes.
>
> PS:
> I do not believe it is a good idea to give detailed tutorials because there
> are a lot on the internet. However, give the reader pros, cons and curiosity
> to test those tools, practice or workflow can be really good.

The tools that people use can vary in an incredible way, thus the workflow defined by multiple tools can go even further. I think a workflow here is highly opinionated, and such a thing may disturb newcomers?

Wouldn't it be better to let people decide on their own tools and Git should stay respectful? Let alone most people come into the community as developer, if they are going to be "WorkingOnGit", so they may already be well-suited in their own workflow?

-- 
Thanks & Regards,
Shaoxuan
Previous: COGONI GuillaumeNext: Guillaume Cogoni
Message 3 of 17 in “documentation: guide of best practices for GIT developer”
  1. 0/1 documentation: guide of best practices for GIT developerCOGONI Guillaume, Apr 12, 2022
  2. 1/1 documentation: guide of best practices for GIT developerCOGONI Guillaume, Apr 12, 2022
  3. Shaoxuan YuanApr 13, 2022
  4. Guillaume CogoniApr 13, 2022
  5. 0/1 Documentation/ToolsOnGit.txt: gather information about toolsCOGONI Guillaume, Apr 16, 2022
  6. 1/1 Documentation/ToolsOnGit.txt: gather information about toolsCOGONI Guillaume, Apr 16, 2022
  7. Matthieu MoyApr 16, 2022
  8. Philip OakleyApr 16, 2022
  9. Junio C HamanoApr 16, 2022
  10. 0/1 Documentation/ToolsForGit.txt: Tools for developing GitCOGONI Guillaume, Apr 17, 2022
  11. 1/1 Documentation/ToolsForGit.txt: Tools for developing GitCOGONI Guillaume, Apr 17, 2022
  12. Matthieu MoyApr 17, 2022
  13. 0/1 Documentation/ToolsForGit.txt: Tools for developing GitCOGONI Guillaume, Apr 20, 2022
  14. 1/1 Documentation/ToolsForGit.txt: Tools for developing GitCOGONI Guillaume, Apr 20, 2022
  15. Junio C HamanoApr 20, 2022
  16. 0/1 Documentation/ToolsForGit.txt: Tools for developing GitCOGONI Guillaume, Apr 21, 2022
  17. 1/1 Documentation/ToolsForGit.txt: Tools for developing GitCOGONI Guillaume, Apr 21, 2022

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.