@speed issues Git itself is quite fast. Claims of it being "slow" are not git itself, but on Windows the posix emulation layers it has to go through to do it's job. I'm unsure about the current state, it's possible speed has improved or the mysgit project may be more mature.
@gui Personally I use the command line for all branching operations, merges, and 99% of the time for push/pull, but git-gui while lightweight is very nice for constructing an actual commit. I prefer thinking of the gui has a helper to make some things easier, rather than a complete replacement for the cli. I haven't used it myself since I switched to Ubuntu before I ended up getting interested in git but there is a TortoiseGit project someone might want to look at for those who have been spoiled by TortoiseSVN: http://code.google.com/p/tortoisegit/
@repo breakdown I thought about that to at one point. Perhaps git submodules? git submodules are somewhat like svn:externals except they actually are built in a useful way.
To create a submodule you run: git submodule add repourl path Then you commit. This will checkout that repo to path, add the repo to .gitmodules, and tag the latest commit. Committing this will result in a submodule pointing to a specific commit in that repo being inside the repo.
When someone clones your repo submodules are not automatically checked out. You first init submodules using: git submodule init This adds the submodule repo urls into your local config. ((A very handy note here, you can actually edit the url in your config at this point, this means that while you have a public url inside the setup for submodules, individual users are free to edit the repo url for themselves and instead of the public url point their clone to a repo url where they have the ability to push to)) Then after that you run: git submodule update And it will clone all the submodules from the specific commit. Rather than cloning everything it's actually possible to use `git submodule update path` to only clone a specific repo.
To update the commit you cd into path, git pull to update to a new version, back at the root you `git add path` (be careful NOT to use a trailing / or you'll end up adding the contents of the repo into the local repo instead of updating the commit id) and commit. People can again use `git submodule update` to update everything.
submodules are probably actually faster than svn:externals and you have the option to pick and chose what you want to use.
As a thought we could probably structure it something like this: - We have a phase3 repo for MediaWiki itself - Each extension gets it's own git repo - Inside the phase3 repo we add extensions as submodules inside the extensions/ directory. -- Side note, this means we're no longer limited to a central repo for extensions. Anyone can host their extension anywhere they want and all we do is point to that repo, so we don't need to arbitrarily require they be in Wikimedia's repo for support. - On releases we create rel#_## branches in the phase3 repo. In these branches we can nicely tag commits of extensions that are stable for that version. -- This has a similar workflow as releases had in svn. When you branch the master branch to make a release it will use the commit ids that are currently there, thereby locking the commit ids for extensions in that branch just like how it works when brion svn copies phase3 and extensions to a release branch. -- As a side, it's perfectly reasonable for an extension author to go in and decide to update the commit id for an extension in a release branch if that newer commit is still stable on that version of MW. - If we don't want to bother updating commit ids inside of master (trunk) we could always just have a simple script which loops through extensions/* and for each one runs `git pull origin master` in that directory, runs git add on the paths, then commits that updating them all at once. -- Whether or not we do this, or they checkout master or a branch, anyone who checks out the repo and uses submodules to checkout extensions, they are free to use `git pull origin master` to update specific extensions to their latest trunk commit.
Under this setup someone who wanted to checkout rel1_15 MediaWiki:
git clone phase3repourl mediawiki/
MediaWiki's core code is now inside of a mediawiki/ directory
cd mediawiki/ git checkout rel1_15
We have switched to the 1_15 release
git submodule init
Submodule information added to .git/config
git submodule update extensions/
All extensions are now checked out into the extensions directory (or instead)
git submodule update extensions/ParserFunctions
Just the ParserFunctions extension is checked out
cd extensions/ParseFunctions git pull origin master
ParserFunctions is updated to it's latest alpha
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Hay (Husky) wrote:
On Sat, Aug 29, 2009 at 3:07 PM, Dmitriy Sintsovquestpc@rambler.ru wrote:
Some local coder told me that GIT is slower and consumes much more RAM on some operations than SVN. I can't confirm that, though, because I never used GIT and still rarely use SVN. But, be warned. Dmitriy
I'm not a git expert, but afaik Git was designed from the ground up by Linus Torvalds to be *very fast*, even on large operations. It runs the Linux project, so i guess it can't be *that* slow :)
Chad wrote:
It's _ok_. The command line usage is pretty solid and I haven't encountered any issues there. The GUI interface sucks and is a complete waste of time.
There aren't any real good interfaces for SVN on Mac and Linux too. Windows users are spoiled by having such a great app as Tortoise for free. I guess most Mac and Linux SVN users simply learn to use the command line, which isn't a bad thing at all.
-- Hay