Talk:Git/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

VCS percentage use chart, using EasyTimeline (draft)

Based on the data at

• https://www.openhub.net/repositories/compare (JavaScript chart)
• https://www.openhub.net/repositories/chart (raw data)

[["Bazaar",13003],["CVS",62756],["Git",256959],["Mercurial",17994],["Subversion",325597]]

This is based loosely on Template:EP election results graph (percentage)

Question: Is there some way to use {{#expr:}} inside <timeline>?

71.41.210.146 (talk) 21:12, 4 December 2014 (UTC)

Too technical for non-geek readers

I'm a reasonably technical reader for a novice programmer, but even I found a lot of the detail in this article hard to follow. It would be great if someone who understands the granular details well could rewrite in more lay language. Thanks. --Strypey — Preceding unsigned comment added by 27.252.112.32 (talk • contribs) 02:34, 13 May 2015

Information for readers with huge repositories

Could somebody please add a note that Git is optimized for non-huge repositories? Linus said: "So git scales really badly if you force it to look at everything as one _huge_ repository." http://osdir.com/ml/git/2009-05/msg00051.html — Preceding unsigned comment added by Jonw2 (talk • contribs) 19:12, 16 June 2015 (UTC)

On a related note, this article and some comments above are completely ignoring the non-Linux/open-source market. That's fine when talking about git itself, since that's its focus. So in the Adoption section, it sounds like Git is the market leader, but when you get outside of the Eclipse community and include things like Clearcase for large enterprises, the story could be much different. Nerfer (talk) 23:19, 17 November 2015 (UTC)

Woe to someone who wants an easy overview.

Like so many Wikipedia articles, this one is a fanboy's wet dream, not a useful introduction to a topic.

Please, writers, keep your audience in mind. The vast majority of people who read this article come to it looking for a brief introduction to Git, because a colleague at work or a friend is using it, but they aren't personally familiar with it.

Here's one clue that the article organization and approach is way off: "History" should never be the first section of a technology article. If anything, it should be the last.

Just my two cents.108.33.72.18 (talk) 16:21, 30 December 2015 (UTC)

The history of the notable version control systems is important, because it's what makes them significant (Different to WP:Notable). The significant ones came into being because they addressed a previous shortcoming in the existing systems and they innovated some particular new feature to do it. This is also a useful way to explain what's different about these new products. Of course there are plenty that don't have any such innovations, but they're ones that have marginal status for WP:N too.

WP:HOWTO is a problem for tech articles generally, particularly when there's a shortage of editors competent to write explanations well, and an over-supply of bureaucrats more interested in finding a reason to revert them. Andy Dingley (talk) 21:36, 31 December 2015 (UTC)

I think the article is good except for the tags at the top (lead too short/subjective promotion). Adding a section with examples for using git would be OK too.Michael9422 (talk) 19:34, 13 January 2016 (UTC)

The fundamental issue is that it's a version control system. If someone is familiar with them, contrasting with other VCSes is helpful. But if one is not, it's very hard to give an introduction to the genre without swamping the git-specific part.

The result is that "overview" is somewhat poorly defined.

That gets particularly nasty with examples, where details can't be glossed over. What would one want an example of? Git-specific syntax for completely generic VCS operations seems like the worst kind of WP:HOWTO.

One of git's most notable distinguishing features is its smooth handling of merges, but the absence of a conflict is awkward to point out, while the presence of one would make for a long-winded example. 71.41.210.146 (talk) 20:02, 15 January 2016 (UTC)

Non-linear?

The article talks about non-linear design and non-linear workflow. That must be explained or defined. --HelgeStenstrom (talk) 14:42, 9 February 2015 (UTC)

I guess this refers to workflows based on branches, where different people can work on the same files concurrently, and later everyone's changes can be merged back into the source code. As opposed to a linear workflow where you wait on other people to be done with the part of the code you're interested in, an only then can make your changes.

I'm not sure how correct that is, and where to put an explanation of that, though. Mlkj (talk) 21:08, 31 December 2015 (UTC)

I also dislike the description "non-linear development". Your explanation seems to be more like "asynchronous".Michael9422 (talk) 19:57, 13 January 2016 (UTC)

I never heard of "non-linear development" of software. The term implies someone could do "exponential development," "discrete development," or maybe "circular development." If we have an RS for the term in software development, let's use it and let the RS explain it. If there is no RS, we don't use it. As it is now, it hangs like a "sky hook." Grammar'sLittleHelper (talk) 23:05, 15 January 2016 (UTC)

"Circular development"? Sounds like the outward spiral model, so you'll be wanting Steve C. McConnell's well-written but dated Rapid Development which covers it in depth.

"Non-linear" isn't a development model, it's a VCS model as exemplified by Git or Mercurial, or "that which Subversion struggles with". It has nothing to do with "asynchronous". Subversion can do asynch, as it supports CMM (Checkout - Modify - Merge) - multiple editors can check the same things out, modify them and then commit them back, even with overlapping (i.e. asynch) changes. The point about the non-linear VCS generation is that they support multiple branching VCS paths with transparent re-merging, the thing that SVN can't do. Andy Dingley (talk) 00:00, 16 January 2016 (UTC)

I see that the terminology "non-linear" is used in the git documentation and on the mailing list, so I withdraw my objection.Michael9422 (talk) 21:07, 17 January 2016 (UTC)

Addition to Git Server section

My name is Robert Outlaw and I work for Microsoft in the Cloud and Enterprise division. I declare a clear conflict of interest, but my goal is to suggest a neutral addition to this article, backed with a citation from a source that I believe meets reliability criteria, to make the section more complete.

I would like to add the following into the "Git server" section of this article. The addition is in the same form and near the same word count as the other entries in this section.

Visual Studio Team Services

Visual Studio Team Services is a software as a service that can host Git repositories. It has a web interface for managing source code along with collaboration tools to help teams build software.

References

• Thank you for your frank introduction and admirable constraint, User:Rloutlaw. That looks like a reasonable request, but your source is a little weak. Maybe I am just missing the key words, but I don't see it saying what you say here. Also, your wording is in present tense, but the source seems to say release is planned for next November. Grammar'sLittleHelper (talk) 18:50, 10 March 2016 (UTC)

Starting on the wrong foot?

The second paragraph currently has "every Git working directory is a full-fledged repository with complete history". This is incorrect. A more correct way to put it could be "every Git (local) repository clone can be a full-fledged repository with complete history". I admit it's a bit difficult to phrase this both technically correct and understandable for people not intimate with git, but as "working directory" has a pretty specific meaning in git I felt it worth comment on this.

Additionally, I think it could be worth to really early point out the data-flow:

• Remote
• Local
  • the "store" (committed)
  • the INDEX (added but not yet committed. Also called the staging area, or sometimes really wrong "cache")
  • the working directory (local tree)

The section "Data structures" is really nonsense when read from a programmers POV (git has way more than two structures). Perhaps "Data hierarchies" could make it more understandable?

The introduction of "blob" in this article may be the wrong place. Perhaps a page "Git_OnDiskFormat" or something like that would be a better place for it? 83.252.253.240 (talk) 13:49, 14 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Git (software). Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

• Attempted to fix sourcing for http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 03:17, 29 March 2016 (UTC)

Git clients

I noticed this article is missing a "Git clients" section to go along with the "Git servers" section. The page on Mercurial has one, and the information for the article can technically be found at Comparison of version control software, although it's hard to find. Is it a good fit here or perhaps moved to a separate page such as Subversion? 70.190.187.159 (talk) 04:09, 19 April 2016 (UTC)

Coloring Mistake in Table

The color for "Latest preview version" in the table in section "History" is wrong. (I don't know how to fix this.) — Preceding unsigned comment added by McGucket (talk • contribs) 23:16, 23 April 2016 (UTC)

Sudden move

Um, can we move this article back to where it was? Contrary to the edit a peice of version control software is not the most common usage of "git", which remains an actual word in the English language. Artw (talk) 19:18, 7 August 2016 (UTC)

the articles appear to have moved back to their original locations. Artw (talk) 21:24, 8 August 2016 (UTC)

Uh, what. Lots of things are "actual word(s)" in the English language". That's not how we decide primary topics. In this case, the inbound links pretty clearly shows what inbound links are looking for. We optimise for those, irrespective of anything else (especially the weird assertion you made at Talk:Git (slang) that this had something to do with the professions of editors). I'll be moving this back (and thus fixing all those inbound links) shortly unless an argument that has something to do with our actual naming guidelines is forthcoming. Chris Cunningham (user:thumperward) (talk) 14:49, 29 August 2016 (UTC)

As there's been no response to this at all, I've moved things back again. Chris Cunningham (user:thumperward) (talk) 21:12, 11 September 2016 (UTC)

It was, as you noted, moved back, so I thought the matter was done with. Sorry I didn't reply to your note, with all the unnesary page moves it can be be easy to lose track of all the talk pages. I have to ask why you think it is necessary to cause so much confusion? You seem to be wasting everybodys time here. Artw (talk)

web interfaces

I just added that. Contributions welcome. User:ScotXW^t@lk 08:22, 16 March 2017 (UTC)

@ScotXW: maybe also add references or wikilinks? --Slashme (talk) 12:38, 16 March 2017 (UTC)

Yeah, and other existent web interfaces. User:ScotXW^t@lk 13:09, 16 March 2017 (UTC)

"There are at least webgit and cgit." - I have no idea what this sentence means. For non-techie folks like me, who want to learn what the heck 'Git' is, it is important to explain such terms. It's a very good article overall though, and I trust this section can be expanded soon. :O)   - Mark D Worthen PsyD (talk) 00:58, 22 April 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Git. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20060113122252/http://revctrl.org/CrissCrossMerge to http://revctrl.org/CrissCrossMerge

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:31, 18 October 2017 (UTC)

Data Sources Section

The following line at the end of Data Structures section is out of place: Git servers typically listen on TCP port ...

I recommend removing this line as there are many other ways to determine ports for git rather than this article

--Davidgreystahl (talk) 15:29, 7 September 2018 (UTC)

Is git's usage of sha1 a problem / a security threat?

Thue proposed to state in the article that git's usage of sha1 "is a problem because SHA-1 is no longer considered secure" and that the source he mentioned "prominently mentioned Git as a possible target for attacks". I don't see how either is the case, especially in regards to his source. If you, Thue, or someone else thinks that the source you used or any other reliable source states this, please discuss it in this section. McGucket (talk) 16:57, 25 February 2017 (UTC)

The linked PDF mentions Git in the very second paragraph? How is that not prominently saying the SHA-1 compromise could be a problem for Git? Thue (talk) 23:27, 25 February 2017 (UTC)

It just says that sha1 despite being deprecated (Deprecated for what usage?) is used by git, not that git's usage of it constitutes a problem. A collision of sha1 having been found doesn't mean that git commit or object hashes will now randomly collide and cause problems or that it's even remotely feasible that someone deliberately finds another commit with the same hash as an existing commit. Note that finding a second preimage is much more difficult than finding a collision. McGucket (talk) 23:50, 25 February 2017 (UTC)

See https://lwn.net/Articles/715722/ and https://lwn.net/Articles/715716/ . It is considered a real problem by people who understand the technical details, which is why they are preparing to migrate. Thue (talk) 14:19, 1 March 2017 (UTC)

Is there any reliable source which states that there is or anytime soon (up to 2050, maybe) will be a significant risk of a successful second-preimage attack? Quoting a mailing list message which states that "Linus is right, that's an impractical attack." or referring to a paper which found a hash collision (which is a completely different thing as there are literally many orders of magnitude between them, in most cases) doesn't exactly make that appear plausible. McGucket (talk) 18:13, 2 March 2017 (UTC)

The following response from github seems to indicate that the SHA-1 collision attack can be thwarted - https://blog.github.com/2017-03-20-sha-1-collision-detection-on-github-com/ for collisions being used in the wild to infect others.

Using SHA-1 for an SSL certificate would not meet best practice in security. However as a developer using SHA-1 as a way to hash an object and produce an almost unique name that is tightly related to the content of the object is not a security issue, but instead is a hashing issue which could cause issues in extreme cases (see github article) but this is true of any non-perfect hashing function (see http://interactivepython.org/runestone/static/pythonds/SortSearch/Hashing.html and https://wiki.riteme.site/wiki/Hash_function). I think the confusion comes in because the hashing function Linus Torvold chose for git was also a cryptography hash, but the purpose of a version control or file system is to share the content - so the source text is visible to all, so unlike a cryptography use where the hash obscures the content, in this case there is nothing being obscured. The article itself mentions this in passing in the security section.

There are security issues with distributed version control systems, namely how does a user trust what is in a git repository (regardless of whether the user is getting the content from a clean or a corrupt deliberately SHA-1 collision exploited repository). Using software written by someone else requires trust - and unfortunately there are many ways for malicious actors to introduce malware into a source repository. A person using a distributed version control system to download and build software systems would need to inspect / validate that the software generated does not contain malware, I would imagine by running malware detection systems (which are limited and can only identify already known malware exploits). If I can find published articles about open source trust and validation I'll add a reference in the article's security section

--Davidgreystahl (talk) 01:27, 8 September 2018 (UTC)

The use of platform in the infobox

THe use of platoform attribute in the infobox seems uneeded and also misses a lot of platforms that git runs on and adding all of them would use to much space, I also see no need to state what Processor architectures git runs on. Also, loooking at the Articles of other simular software like GNU Bazaar, Mercurial and BitKeeper do not have the Platform attribute or any mention of what processor architectures the software runs on. --Ioangogo (talk) 11:23, 5 June 2018 (UTC)

Agreed - thanks for pointing this out. Done. ★NealMcB★ (talk) 19:32, 5 October 2018 (UTC)

References in sub section title

Sub section "Releases" has references in the title ("[27][28]"):

Releases[27][28]

Can we get rid of it?

--Mortense (talk) 15:20, 1 December 2019 (UTC)

Removed. Headings should not contain any reference. – Ammarpad (talk) 15:39, 1 December 2019 (UTC)

GitHub

I once put a link to an example of something in a WikiPedia article and it was called spam and removed. It was nothing I had any relationship with, I thought it was relevant to the article. Now GitHub is a commercial product, right? GitHub is separate from Git, correct? So why is GitHub in this article yet I can't do the same thing in other articles? I understand the relevance of GitHub to Git but rules are rules. GitHub is listed as a repository in the menu in the right side; that is quite an advertisement. GitHub is listed as a service but no where else in this article is it made clear that GitHub is a commercial product separate from Git. I don't have anything against GitHub; I only resent that my other contribution was called spam as emphatically as it was. Sam Tomato (talk) 20:47, 4 November 2018 (UTC)

I see this is resolved now. Phoe6 (talk) 16:50, 21 December 2019 (UTC)

Reasoning behind reverting go-git Git implementation edit

Hello everyone, I would like to understand the reasoning behind undoing the contribution of adding go-git implementation of Git in Go as well as the reason why it would be marked as "spam".

It is indeed one of the most popular implementations of Git as shown in the referred URLs, in one of the most popular computer languages nowadays, with many open source contributors from all around the world under different backgrounds. So there's no reason it should not be listed in this article.

If the issue is with one of the references rather than the content itself, let's discuss that specifically on how to improve or fix it, rather than just undoing the full contribution content without detail. Thank you. KDEWolf (talk) 13:49, 19 April 2019 (UTC)

@KDEWolf: An external link in the article body is almost always considered spam. For details see the Wikipedia policy on external links at Wikipedia:External links. Statements like "one of the most popular open-source implementations of Git" are also usually spam/promotion. If there were multiple independent reliable sources with a reputation for fact checking that actually claim that then it would be acceptable, but a link to a misleading github search (obviously misleading since the primary git-scm.com implementation is not even listed) is not. See Wikipedia:Verifiability, Wikipedia:Reliable sources, and Wikipedia:No original research for further information on these policies. -LiberatorG (talk) 17:57, 19 April 2019 (UTC)

@LiberatorG: Thanks for the prompt reply with very informative and actionable advice! Given that go-git is cited by the primary implementers at git-scm.com itself, would it be reasonable to:

(1) remove the external link to the project's GitHub page and keep it plain text

(2) remove the claim about its popularity: I understand that the primary implementation might be missing, but since libgit2 and Dulwich are listed in the article and are just above & below go-git, the idea was to show that it is popular/notable.

(3) add the git-scm.com citation to introduce this implementation

(4) fine tune the citation references to be more neutral

The final result would be:

go-git is an open-source implementation of Git written in pure Go. It is currently used for backing projects as a SQL interface for Git code repositories and providing encryption for Git.

In the end the two examples of usage that were provided to be more akin to the examples provided in the JGit paragraph, that mentions Gerrit, EGit and Ecplise. Also, the article in general has mentions to non-open-source or even commercial references, so I did not consider this a problem. I guess removing one or both of them would make the article edit poorer, but even more neutral.

Thanks again for the useful and friendly advice. Looking forward for your and other's opinions on it.

— Preceding unsigned comment added by KDEWolf (talk • contribs) 18:48, 19 April 2019 (UTC)

References

@KDEWolf: This looks ok to me, except for the minor style issue that the period should be before the reference (see MOS:CITEPUNCT). Also remember to sign your talk page comments by typing ~~~~ at the end; otherwise no reply notification will be sent. -LiberatorG (talk) 20:45, 19 April 2019 (UTC)

@LiberatorG: alright, thanks again for the tip. With this last fix the final result is:

go-git is an open-source implementation of Git written in pure Go. It is currently used for backing projects as a SQL interface for Git code repositories and providing encryption for Git.

Will make the edit as above! All the best, KDEWolf (talk) 08:01, 22 April 2019 (UTC)

References

I see this is resolved too. This conversation can be archived. Phoe6 (talk) 16:53, 21 December 2019 (UTC)