Talk:Git/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Projects considering to migrate to git?

There are numerous high profile OSS multi-platform projects considering to eventually migrate to git-based SCM once git works also reasonably well (and easily) for the major non-nix platforms (i.e. Win32), this might deserve special mention given that the decision to migrate to git due to its powerful feature set has often already been made but only been postponed due to lack of full Win32 support. What do you guys think?--Parallelized (talk) 13:44, 3 November 2008 (UTC)

Doesn't sound encyclopedic to me.   Also new sections should go at bottom of talk page.   Daniel.Cardenas (talk) 14:17, 3 November 2008 (UTC)

The topic title is not good - it sound like rumors, but discussing difficulties with expanded use of the tool is. Seanblanton (talk) 16:53, 5 February 2009 (UTC)

Bad idea. "Considering" means just evaluation and speculation (and sometimes flamewars). An encyclopedia is not a place for such content. And what's the motivation anyway? To fuel the DVCS war? —Preceding unsigned comment added by 80.220.180.181 (talk) 05:06, 21 March 2009 (UTC)

image request

Can one or more people do a screen shot of git doing something common and upload it? We can then add it to the article.   Thx, Daniel.Cardenas (talk) 19:06, 24 January 2009 (UTC)

The famous "Git UI is a bunch of shell scripts"

There is this famous claim that Git's user interface is nothing but shell scripts around low-level tools. As everyone (?) knows Git started like that but the important tools have been reimplemented in C once they have been considered mature enough.

Below is the current situation (2009-01-25). Please update when needed.

$ ls -1 git-*.{sh,perl}          # git://git.kernel.org/pub/scm/git/git.git
git-add--interactive.perl
git-am.sh
git-archimport.perl
git-bisect.sh
git-cvsexportcommit.perl
git-cvsimport.perl
git-cvsserver.perl
git-filter-branch.sh
git-instaweb.sh
git-lost-found.sh
git-merge-octopus.sh
git-merge-one-file.sh
git-merge-resolve.sh
git-mergetool.sh
git-parse-remote.sh
git-pull.sh
git-quiltimport.sh
git-rebase--interactive.sh
git-rebase.sh
git-relink.perl
git-repack.sh
git-request-pull.sh
git-send-email.perl
git-sh-setup.sh
git-stash.sh
git-submodule.sh
git-svn.perl
git-web--browse.sh

—Preceding unsigned comment added by 80.220.180.181 (talk • contribs) 06:59, 25 January 2009

What about TortoiseGit and other gui interfaces? Daniel.Cardenas (talk) 17:26, 25 January 2009 (UTC)

Comes from another project, but does not belong to git itself. --88.130.85.137 (talk) 17:23, 26 May 2011 (UTC)

Ruby

Currently the article says that Ruby "ruled out" moving to Git, which sounds as if there were no chance of that ever happening. But the discussion this refers to was in 2006, Git has improved a lot since, now the most important Ruby projects are on Git, and Ruby core developers including Matz are considering a migration and working on it[1][2]. So "ruled out" is not accurate.--87.162.47.155 (talk) 17:18, 31 January 2009 (UTC)

Licensing Info Needed

Licensing is an important part of any free software project. It should be a standard section. I had to mine several forums to find out that licensing is GPL v2.0, according to word-of-mouth. Need a real reference. Seanblanton (talk) 16:51, 5 February 2009 (UTC)

Is there a reason not to reference the license text itself?

Note that the only valid version of the GPL as far as this project

is concerned is _this_ particular version of the license (ie v2, not

v2.2 or v3.x or whatever), unless explicitly otherwise stated.

(http://git.kernel.org/?p=git/git.git;a=blob_plain;f=COPYING;hb=HEAD)

— DataWraith (talk) 13:58, 6 February 2009 (UTC)

Details why C over C++ based implementation

You might enjoy this read, maybe the thread should be incorporated, here? :-) --Parallelized (talk) 11:07, 21 May 2009 (UTC)

Linus likes C and that is why C was chosen. If the lead guy liked C++ then C++ would have been chosen and would have laughed at any suggestion to use solely C.   Daniel.Cardenas (talk) 15:02, 21 May 2009 (UTC)

The Situation re Windows Support is improving

• http://dobbscodetalk.com/index.php?option=com_myblog&show=Git-Getting-Stronger.html&Itemid=29 —Preceding unsigned comment added by Parallelized (talk • contribs) 19:19, 2 June 2009 (UTC)

This may be true, but programs like msysgit are still very buggy and are even self-described as preview versions. Previously someone had indicated that msysgit is acceptable in a production environment, which is false. Javaman411 (talk) 21:54, 14 November 2011 (UTC)

Improving the intro?

This article gives the overview which I was looking for and could not find in user-manual.txt. Thanks a lot! However the "one-line description" could be improved: emphasis on being fast is not as important as the idea of (also) tracking content locally versus main-repository based systems which track only central repos. And to me author and original idea etc. belongs further down in the text. (I am very unsure on these.)

Suggestion:

Git is a free distributed software source code management system. The basic idea is to track content of a local project and being able to synchronize with other (peer-)developers when work is stable. The two main abstractions are object database and current directory cache

From other CS-docs I have the notion of "four line description"; the one-liner only delineating the basic function, the "four-liner" explaining the most outstanding features or just the main feature of the object of the article.

Suggestion for extended introductory description, "four-liner":

Git has a strong identification of objects, once a file is committed (ie registered in the database) it is assigned a long globally unique key, like a digital fingerprint, so it can easily be verified that contents has not been changed. etc.

You should be able to mail me or contact me via my page if you like my suggestions. --d-axel (talk) 08:53, 19 July 2009 (UTC)

Git not an insult referring to Andrew Tridgell?

I'd always thought Linus had named Git in reference to the BitKeeper controversy caused by Andrew Tridgell. Is this not true, then? Sslaxx (talk) 14:27, 21 September 2009 (UTC)

Probably not true. If you have a reliable source to verify that information, then it might be considered notable. Otherwise it's just gossip (or libel). ~a (user • talk • contribs) 14:45, 21 September 2009 (UTC)

See https://git.wiki.kernel.org/index.php/GitFaq#Why_the_.27git.27_name.3F

Quoting Linus: "I'm an egotistical ***, and I name all my projects after myself. First 'Linux', now 'git'".

('git' is British slang for "pig headed, think they are always correct, argumentative").

173.81.161.138 (talk) 05:23, 28 December 2010 (UTC)

{{tooshort}} tag

I've been asked to explain my tagging of this article with {{tooshort}}. WP:LEDE says that the lede of an article should provide an adequate summary of all the article's key points. Presently, it does the bare minimum to describe the project. For instance, the second paragraph (nominally detailing the technical design of the system) reads in its entirety as follows:

Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

This is only one feature of the system, and certainly does not adequately summarise the whole. It does a reasonable job of summarising that one feature, but every other noteworthy part of the system should have the same treatment in the lede.

We're really looking for each of the present paragraphs (which are currently one or two short sentences long) to be fleshed out to full-length paragraphs, each summarising one part of the article. For instance, we want a full-length paragraph establishing notability and describing the project history, a full-length paragraph on system design and features, and a full-length paragraph on adoption and reception.

Chris Cunningham (not at work) - talk 08:46, 2 April 2010 (UTC)

Git hosting services

This was brought up on my talk, but it should be discussed here, especially as people are so keen on this link that they're adding it twice. The git wiki is not a reliable secondary source, and the list of git hosting services is not even particularly important information - it's trivia which serves as a nice portal or badge on the git website, but not particularly useful for an encyclopedia. If this list isn't mentioned in any reliable secondary sources then it should probably be removed - too often on Wikipedia we allow articles to ignore the referencing standards expected of the rest of the project in lieu of drawing material from user-generated sites or software home pages. This article should focus on that which is covered by reliable sources, rather than trying to duplicate the material found on the git website. Chris Cunningham (not at work) - talk 10:05, 3 April 2010 (UTC)

There will ever be a more reliable and up-to-date source for this than the Git wiki. But I agree that such a list is not really necessary here. We also have a Comparison of open source software hosting facilities, which we can link to. So I'm Ok with either leaving the list the way it was (without the citation needed tag), or deleting it entirely. --Drizzd (talk) 12:00, 4 April 2010 (UTC)

Parrot virtual machine?

Why is Parrot in the projects using Git section? According to this page they use Subversion. --Ævar Arnfjörð Bjarmason 11:03, 24 April 2010 (UTC)

Article inconsistencies

From the article:

• A blob object is the content of a file. Blob objects have no names, timestamps, or other metadata.
• A tree object ... contains a list of filenames, each with ... the name of a blob or tree object that is that file, symbolic link, or directory's contents. ....

How does a "tree object" include the name of a "blob object", if a blob object has no name or other metadata? —Preceding unsigned comment added by 207.114.132.30 (talk) 20:45, 6 July 2010 (UTC)

I replaced "Blob objects have no names" with "Blob objects have no filename". When the article talks about the name of an object that is the object's SHA-1 hash as explained in the subsequent paragraph. Hope this helps --Drizzd (talk) 17:24, 11 September 2010 (UTC)

Name

The article quotes Linus Torvalds:

      "I'm an egotistical [sic] bastard, and I name all my projects after myself. First Linux, now git."[5][6]

But why the "[sic]" after "egotistical" ? Is it not a bonafied word? My dictionary of choice, the venerable Merriam-Webster Collegiate, seems to feel it is. See it on-line at http://www.merriam-webster.com/dictionary/egotistical?show=0&t=1288893678) Toddcs (talk) 18:10, 4 November 2010 (UTC)

The word was often changed to egoistical, since people unfamiliar with the word egotistical thought it was a typo. Take a look at (some of) the article history to see how it came to be:

Diffs: 1 2 3 4 5 6

— DataWraith (talk) 08:03, 5 November 2010 (UTC)

I've left in the inline comment saying so, but removed the visible [sic] -- if it's grammatically correct, then there's nothing to warn about. Jpatokal (talk) 01:37, 12 November 2010 (UTC)

Emphasis on speed

I am apparently not the first one to bring this up on this talk page: The opening paragraph says that git's emphasis is on speed, but it isn't necessarily so. In various documents it claims to have emphasis on being distributed, on being secure, on being good with branches and merges - and also being fast. This part should be removed. Kurepalaku (talk) 13:34, 12 June 2011 (UTC)

I saw that Drizzd added a reference to the speed emphasis: http://marc.info/?l=linux-kernel&m=111288700902396

This reference is already quoted in the article, but it just says what emphasis Linus had when he started coding Git and not necessarily its current emphasis. This is good for the history, but I am not convinced about the opening paragraph. Kurepalaku (talk) 12:48, 19 June 2011 (UTC)

I provided a reference. It's your turn to provide something more solid than unfounded doubt. But it's so easy to find references for git's emphasis on speed that I must wonder where you are coming from. See for example [3] and [4]. Optimizations for speed are discussed regularly on the mailing list. Here are two from just this month: [5] [6]. Or check out git's many configuration and command line options aimed solely at execution speed, for example: core.ignoreStat, core.preloadindex, diff.renames, *.compression. As a long-time user of and small-time contributor to git I am certainly not impartial, but as far as I can tell git is famous for its speed. --Drizzd (talk) 09:51, 24 June 2011 (UTC)

Your first link here shows that speed is one of Git's goals, but not the only one. Your second link shows that Git is fast, but it also doesn't show that speed is Git's emphasis. I am not saying that Git is not fast. I am just saying that I still haven't seen proof that speed is Git's only or main emphasis.

There are discussion about speed on the mailing list of almost every software project, so this is also not a reference that Git's only emphasis is speed. --Kurepalaku (talk) 10:48, 24 June 2011 (UTC)

Ok, so we have established that git was initially developed to be fast, that its speed has since been improved continuously and that still more improvements are being discussed. And we also agree that git is fast, arguably not by accident. But if I understand correctly you believe there may be other aspects which have just as much emphasis and by comparison the focus on speed is not that relevant. Let's look at the ones you mention: 1. distributed version control, 2. security, 3. branching and merging.

1. I agree that the idea of distributed version control is at the heart of git. It is most definitely a distributed version control system. And that's exactly what the introduction says: Git is a distributed revision control system with an emphasis on speed. So I think we are not missing out there.
2. Security, especially data integrity, is something that git does well by design, and Linus said that he considered it vital. But that is obviously important to all version control systems. Some do a better job at it than others, and git is not more secure than most other distributed version control systems. Monotone, for example, puts much more emphasis on security than git does. I remember but a few discussions about information security and data integrity on the mailing list, mostly because the former is considered to be outside the scope of git, and the latter just works.
3. Branching and merging is something that is very easy with git. But is it better at it than other distributed version control systems? I think not. Does it put emphasis on branching and merging? No more than any other distributed version control system does. In fact, git's merge algorithm is trivial compared to other systems. Bram Cohen and Linus had a heated discussion about that very topic: [7]. A good example for emphasis on merging would be Darcs, which uses a rather complex algorithm. But the git developers do not care, because they do not consider it to be that important. It is good enough as it is.

Git's speed is its greatest competitive advantage to other version control systems, and not any of the points above. It is appropriate to hint at that in the introduction. --Drizzd (talk) 09:03, 26 June 2011 (UTC)

Your first source, progit.org puts "Strong support for non-linear development (thousands of parallel branches)" in the same list with "Speed". All my developer friends who like Git say that the easiness of managing branches is their favorite feature (although some mention speed, too). They don't represent all Git users, of course, but apparently there are some people who consider this to be the important thing and not the speed.

The other source you cited, wincent.com, confirms another goal mentioned at progit.org - Simple design. It says little about speed.

So, I am still not convinced that singling out speed in the opening sentence is the right thing. Maybe all five goals from progit.org can be listed. --Kurepalaku (talk) 15:13, 28 June 2011 (UTC)

I already explained that easy branching is not unique to git nor is it particularly emphasized compared to other distributed version control systems. After all, that is the very point of being distributed. And simple designs are the goal of every sensible engineer. Nobody would deliberately go for a design that is more complicated than it has to be.

Meanwhile you just keep re-stating your opinion while ignoring my argument. I believe I have made my point and I am done with this discussion. Thank you. --Drizzd (talk) 20:17, 28 June 2011 (UTC)

You didn't provide any source that says that Git is only focused on speed. You did provide a source that proves my point and says that speed is one of Git's goals and that gives "thousands of parallel branches" and "Fully distributed" as two other, separate, goals. (Not that anyone needs proof that being distributed and easy branching is not the same thing at all.)

As for not being focused on simplicity - again, the same page explicitly says that it is one of the goals. What you say about simplicity can be said about about speed too - nobody would deliberately go for a design that is slower than it has to be.

The last point in the progit.org list is scalability, which is also not just about speed. --Kurepalaku (talk) 20:47, 28 June 2011 (UTC)

Stable release link

The footnote for the "stable release" date in the template in the beginning is a long link that doesn't look so nice in the list of references. I wanted to fix it, but I can't find it anywhere. It's supposed to be the "latest_release_version" parameter in the template, but it's not there. Where is it hiding? Kurepalaku (talk) 13:49, 12 June 2011 (UTC)

Click on the version number or on the +/- link. They will take you to the template describing the current version number. You can perform the changes you think are required there - just don't forget to check the main article afterwards to ensure everything went well. Moocha (talk) 22:41, 16 June 2011 (UTC)

Done! Thank you. Kurepalaku (talk) 17:30, 17 June 2011 (UTC)

What does SCM mean?

The acronym SCM is used but never defined, nor is a link providing a definition available. — Preceding unsigned comment added by DaleEMoore (talk • contribs) 16:02, 3 March 2012 (UTC)

Software configuration management. I've updated the article to define the acronym on its first use (outside of a quotation). Mitch Ames (talk) 00:59, 4 March 2012 (UTC)

Staging area

The Pro Git Book (http://git-scm.com/book/en/) tells that the "Index" is now preferably referred to as the "Staging area". I suppose this article should be updated according to this? Lowbop (talk) 20:54, 31 August 2012 (UTC)

What does GIT stand for?

Can someone add this to the article? — Preceding unsigned comment added by 132.250.22.10 (talk) 18:51, 13 July 2012 (UTC)

Git (software)#Name explains the origins of the name. The first reference also says that git "can mean anything, depending on your mood". Mitch Ames (talk) 06:19, 14 July 2012 (UTC)

Git doesn't "stand for" anything: it's not an abbreviation. (So writing it as "GIT" is actually incorrect.) 194.60.38.10 (talk) 13:12, 22 November 2012 (UTC)

Results of Eclipse survey are used inconsistently

The Eclipse Community Survey results are cited in the "30% adoption" figure mentioned in the top of the article. Meanwhile, near the bottom of the article it's re-cited as "over 36%" which presumably adds the Git and Github figures together. We should settle on which one to use and make it clear in the page body what the figure is; User:Othtim also had some good input on this above.

Winterswift (talk) 04:55, 4 October 2013 (UTC)

30% market adoption

Regarding the comments that "git has 30% market adoption" ...

I think this is a misleading statement. As a reader I feel that it implies that 30% of source control in the world is Git. That is not the case. I think it would be better to say, "Based on a recent survey, 30% of Eclipse users use Git". But to be honest I think this line should be removed.

-Tim — Preceding unsigned comment added by Othtim (talk • contribs) 17:24, 17 September 2013 (UTC)

Agreed. Usage of Git in Eclipse is a bad metric. Dsavi (talk) 08:54, 18 October 2013 (UTC)

git-annex

Someone might want to add information about git-annex. "git-annex allows managing files with git, without checking the file contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, time, or disk space." from http://git-annex.branchable.com/ Apparently it's used in the gaming industry. http://www.reddit.com/r/programming/comments/1qr5hb/what_does_svn_do_better_than_git/cdfobla • Sbmeirow • Talk • 18:23, 16 November 2013 (UTC)

GitHub centric

This article seems to be decidedly GitHub focussed. The "official" website is one provided by GitHub, not by the Git project, and I believe the logo is similarly not endorsed by the Git project itself.

I think the GitHub content is useful, but it shouldn't be considered official.

The nearest thing I know of to an official website is https://git.kernel.org/cgit/git/git.git/, which appears to still use File:Git-logo-2007.svg as its logo.

—me_and 12:49, 23 January 2014 (UTC)

To me it seems that the wiki page on the kernel provides official information for developers https://git.wiki.kernel.org/index.php/Main_Page and here they mention specifically the user-oriented http://git-scm.com/ as the "Git website" where to get "current updates and information." So in the end, for Wikipedia readers it seems that http://git-scm.com/ is the official and the intended website to visit. I would thus suggest to leave the logo and the link as is. --hroest 09:09, 24 January 2014 (UTC)

ungit

ungit 78.35.203.149 (talk) 23:13, 30 January 2014 (UTC)

Pluggable merge strategies

The article mentions "Pluggable merge strategies" as one of the (design) characteristics of git. I am not sure I understand what "Pluggable" means. For me it would mean that it was possible to provide a third party merge strategy as a plug-in. Looking at the man page for git-merge, I don't see that this can be done. On the other hand, git does use different merge strategies in different situations, and it is possible to select from a predefined list of strategies when doing a merge. How about changing the heading to "Multiple merge strategies" instead? Also, there is an (incomplete) list of merge strategies further down in the article. I propose to include this in this description. Possibly also mentioning the "ours" and "subtree" strategies. Andreas.kagedal (talk) 06:21, 24 April 2014 (UTC)