@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
Sintsov<questpc(a)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
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]