Talk:Git

Further expanding the article

Here's a list of some things that we can use to further expand the article:

• example screenshot of some git log output of the Linux kernel, showing an example of git commit hash and commit messages
• example screenshot of git diff output to show how Git is tracking changes
• example visual screenshot/diagram of a Git tree that visually shows git branches as lines and commits as dots, how branches are created when the line splits, and how branches are merged when the lines converge
• PGP/GnuPG signing commits and tags, and purpose of signing
• history of commit "sign-off" feature and relevance to SCO lawsuit
• Developer Certificate of Origin and "Signed-off by:" used for Linux kernel
• workflow that patches sent through email, and how that compares to the use of Git hosting services
• why Git ignores are used, and commonly used .gitignore file
• emphasis on push, fetch, pull, merge, etc. commands with patches and pull requests
• how "master" branch has references to slavery
• a sentence explaining use of "master" commonly used to explain concepts in computing (e.g. master and slave devices)
• relevance of "master" branch to racism awareness and Black Lives Matter movement in countries such as the US and examples of some notable projects that have renamed "master" branch to "main" branch

These last three are ememplars of the ignorance that pervades among people with regard to this hypersensitivty to and policing of language.

"Master" here does not reference slavery. It has the same semantics as having a master (that is primary) recording, the one from which all others are copies. This has nothing to do with racism except to a bunch of virtue signaling ignoramuses so intent of "cleansing" our language of content they find, again out of deep ignorance, objectionable, and without any knowledge of the actual meaning or etymology of the words. I personally change "main" back to "master" in my new repositories exactly because the former does _not_ have the same semantics as the latter. — Preceding unsigned comment added by 50.74.108.114 (talk) 18:15, 5 February 2024 (UTC)

Dear 50.74.108.114: Over-sensitive much? Passive aggressive much? You come off as icky jerk. Besides, "main" is shorter. Live an let live. The world needs more compassion; less of what you're yelling. Stevebroshar (talk) 00:13, 15 May 2024 (UTC)

What you're ranting on about is something largely irrelevant to Git itself. Although it's a widespread change in the free software community, GitHub, then after it GitLab, are the services who mainly adopted the practice (after a suggestion from the Software Freedom Conservancy amid the 2020 unrest), while Git's default, if not otherwise specified, remains master. TappyTurtle [talk | contribs] 17:54, 15 May 2024 (UTC)

Please feel free to contribute! Somerandomuser (talk) 15:15, 17 July 2021 (UTC)

I've created a todo list that is shown as a banner on this talk page. Somerandomuser (talk) 17:32, 21 July 2021 (UTC)

Changing opening header to be more inclusive eliminating the demographic statement from summary

While git is "usually used for coordinating work among programmers collaboratively developing source code during software development" it is gaining momentum in other industries. Perhaps this proposition could be eliminated in the header and included elsewhere because in essence it reads that git is for programmers. I don't know if I am the only one who would favour more inclusive language in the header so more people might be inclined to use git or not feel excluded by that statement. If we describe other software pages such as the [Word] page we do not see a statement of demographics regarding to the use of the software.

Jtm-lis (talk) 19:50, 2 November 2021 (UTC)

Maybe change to "generally used for coordinating collaborative work among parties whose work is mostly textual in nature, like source code development"?

I add "mostly textual in nature" because Git doesn't really work really well with graphics. Why do I say that? Because there is this video game mod I play, follow and contributed to that was shared through GitHub and it took quite a while to download everything and I believe it is because Git doesn't delta compress images and the like.

Digitalsurfer-0 (talk) 01:56, 15 December 2021 (UTC)

Talking about limitations WRT binary files would be a good addition. I don't like changing the second phrase/sentence to "generally used for coordinating collaborative work among parties whose work is mostly textual in nature, like source code development" since although not wrong is awkward. Parties is awkward. Talking about the binary file thing so early on is awkward. It's a thing, but not important enough for the first paragraph. Stevebroshar (talk) 00:27, 15 May 2024 (UTC)

GUI clients

There should be a section about it. It's popular, and even mentioned on the official website of Git. Galzigler (talk) 16:40, 27 January 2024 (UTC)

I agree.

I thought there was a "comparison of" article comparing git clients (mostly GUI git clients), but perhaps I am mis-remembering Comparison of version-control software (which does have a brief list of GUI clients for git in the "user interfaces" section).

I recommend generalizing to "git clients", so we can mention both text-oriented clients (TUI clients) -- such as Magit and Tig -- which are apparently notable enough for Wikipedia -- as well as graphical clients (GUI clients). --DavidCary (talk) 21:41, 1 March 2024 (UTC)

Bold 166.181.250.213 (talk) 05:48, 4 May 2024 (UTC)

Graphical interfaces

@Emunah00 The new section on graphical interfaces is a bit of a dumpster fire. It was added along with a giant notice that it needs work. Why add something like that? Add it when you have complete work.

Also, interfaces is not a great term. I think graphical client is what the author is getting at. Interestingly, above is a talk topic on 'GUI clients'. Maybe that's what Emunah00 is addressing.

Thing is, why limit to graphical/gui clients? The CLI client is important too. How about naming the section Client.

FWIW and IMO, the section Git server should be Server. Stevebroshar (talk) 16:12, 19 June 2024 (UTC)

@Stevebroshar I agree with all your points, except for I don't consider that section a dumpster fire; a stub section is much better than a non-written section; if I didn't bring this up, it could take longer to someone write a section for both CLI, TUI and GUI clients.

TLDR: IMO, not perfect is better than non-existent Emunah00 (talk) 06:05, 20 June 2024 (UTC)

Disagree. I don't think a WP article should be a workspace; a place for incomplete work. I think every version of an article should be a complete work. ... There is no such thing as perfect. But, what you added was incomplete as indicated by the inclusion of the needs-work notice. IMO, it's better to add/change boldly and without qualification -- in the article. If you feel more is needed, then add that to talk. ... IMO, the audience of an article is a reader. If you want to address writers, use talk. ... WRT TLDR, what's the part that I didn't read? Is the first part the DR part? If so, put the TLDR first so that I can skip the long part :) ... and it's only a small fire :) Stevebroshar (talk) 15:42, 21 June 2024 (UTC)