Re: Git hosting
- From: Olav Vitters <olav bkor dhs org>
- To: Behdad Esfahbod <behdad behdad org>
- Cc: gnome-sysadmin <gnome-sysadmin gnome org>, GNOME Infrastructure <gnome-infrastructure gnome org>
- Subject: Re: Git hosting
- Date: Wed, 5 Mar 2008 16:01:18 +0100
On Wed, Mar 05, 2008 at 03:33:35PM +0100, Behdad Esfahbod wrote:
> On Wed, 2008-03-05 at 11:37 +0100, Olav Vitters wrote:
> > On Wed, Mar 05, 2008 at 05:44:07AM +0100, Behdad Esfahbod wrote:
> > > > > GTK+ hackers (everyone in Imendio for example) has been using git-svn
> > > > > already, which makes perfect sense, because it allows a company/hacker
> > > > > to have an internal GTK+ tree they work on. The pain currently only
> > > > > lies when they want to push the stuff upstream. chpe also has been
> > > > > using git-svn to do branches involving tens of commits and make them
> > > > > available to me for review, for gnome-terminal and gucharmap. These all
> > > > > make me think, if we are using it, why the pain of the bridge?
> > > >
> > > > Switching seems good. I don't want to rush things though. Once you have
> > > > converted one module, there isn't a way to go back.
> > >
> > > Well, for individual modules, it's much easier to check sanity, so after
> > > the switch, there really shouldn't be any reason to want to go back.
> > > Federico converted the entire Gtk+ history for example, and many hackers
> > > will be looking at it and inspecting it:
> > >
> > > http://www.gnome.org/~federico/news-2008-03.html#full-gtk-history
> > GTK+ is a well managed module. Try something like gnomeweb-wml. Modules
> > where /trunk was svn mv'ed, etc. Maybe the release-notes module I
> > created.
> Right. The point is still valid: when a module is converted, tested,
> and switched over to, not being able to go back to SVN is not a big
> > > > > I assume the merits of nextgen VCS tools are not disputed. I personally
> > > > > prefer git because that's widespread on fd.o and many of us around GTK+
> > > > > stack already use it.
> > > >
> > > > Heh. I like that approach (known + used by fd.o). I'd still like other
> > > > requirements. Meaning: what is really needed? Or do you think all DVCS
> > > > are currently basically the same -- or some that aren't will be in ~6
> > > > months?
> > >
> > > I really don't know. I have only used git. Elijah should know better.
> > > While reading the comments on Elijah's post, I recognized a clear
> > > pattern of prominent hackers (Havoc, Jeremy Katz, Company) essentially
> > > saying the same thing: "for git, the learning curve may be steep, but
> > > when you do get it, it becomes natural and you can't move away from it."
> > > And at least some of the comments seems to be saying such a thing even
> > > compared to Mercurial. I don't know how accurate they are.
> > Years ago I read some magazine that had a different view on learning
> > curves. Steep was good, you learned a lot in a short while. Flat was
> > bad, took way to long to learn something.
> > My view on Git is that the learning curve is as good as flat -- I've
> > read through various documents and didn't feel like I understood
> > anything.
> > IMO calling Git difficult is a great compliment to the current state.
> > I understand that after minimum required 6 months you'll at one point
> > greatly improve -- after all, Git has a command for everything. However,
> > I don't believe people will have the patience for this (I do not -- I
> > have better things to do).
> > Yes, some prominent hackers love it. But ehr, give me something simple
> > I don't mean trying to ignore the 'extras' -- I tried that while reading
> > through the documentation. In the current state it feels like either
> > you're useful when you understood *everything* or nothing at all.
> > Elijah used VCS systems a lot more than me -- and it IMO it took him way
> > too long to figure out. I'm thinking of avoiding the 'total loss'
> > feeling within a few days at most (I recall having this when starting
> > wanting to do the first CVS commit.. the 'I don't want to fuck this
> > up' + 'wtf is this doing / I am supposed to do'). The part in the post
> > about 'if they have an unusually large level of patience and motivation'
> > is what worries me. I don't have the need to learn it.
> > e.g. Git != like learning a bike. I feel I'd forget everything if you
> > don't use it every day.
> > My view ATM is: Every VCS is crap. Choose the one with the least
> > drawbacks.
> Well, donno. For me git is like vim: I have my own 10 git commands that
> I use and simply ignore the rest. Sure, I do some things the hard way,
> but it works. Lemme summarize my git experience as quickly as possible.
> See if this is not enough as a simple git tutorial:
> First thing: clone the repository so you have something local to work
> git clone repo-url
> Branch management:
> See what branches you have:
> git branch
> Checkout a branch:
> git checkout
> Copy the current branch into a new one and switch to it:
> git checkout -b new-branch-name
> After you hack and you want to commit everything:
> git add new-files
> git commit -a
> If just want to commit some of the modified files:
> git commit list-of-files ...
> To amend fixes to the last commit:
> git commit --amend ...
> Removing, moving, ...
> git rm
> git mv
> Get a log:
> git log
> git log branch-name
> Get a diff:
> git diff
> git diff branch/commit/tag-name
> git diff branch/commit/tag-name1 branch/commit/tag-name2
> See a commit:
> git show commit-hash
> GUI tool:
> gitk (Tcl/Tk tool)
> gitk --all (shows all branches)
> giggle (Gtk-based tool)
> - Commit all changes locally, such that git diff returns nothing
> - Get remote changes:
> git fetch
> - Rebase your changes on top of remote changes:
> git rebase origin/master (different for other branches)
> - Push it out:
> git push origin
> Applying patches:
> - When someone emails a git-generated patch to cairo-list, I just save
> it to a file in Evo, then do:
> git am email-file
> Other hackers' repos:
> - Adding someone's personal repo:
> git remote add irc-nick repo-url
> - Seeing "remote" branches:
> git branch -r
> - Reviewing someone's branch:
> gitk/giggle/... irc-nick/branch-name
> - Merging someone's branch:
> git merge irc-nick/branck-name
> Cherry-picking commits to stable branch:
> - Checkout stable:
> git checkout 1.4
> - Go over all commits in the devel branch:
> gitk master
> - Choose commits to cherry-pick do:
> git cherrypick commit-hash
> (gitk copies the commit-hash into PRIMARY when you select a commit)
> Revising history:
> - Undo commit, changes the commit into local changes, so I can modify
> and recommit:
> git reset before-commit-hash
> - Throw away changes after some commit:
> git reset --hard before-commit-hash
> That's pretty much all I use with (and mostly all I know about) git.
> > Git is something like:
> > + swiss army knife.. great hackers will be loads more productive
> > + really fast
> > - usability is crap (names of the commands, good *easily understandable* documentation)
> > - due above: lesser hackers/wannabees will not benefit at all and likely
> > are left out
> > - (sane/Python) scriptability is crap
> > - windows support is still bad
> > But all DVCS systems have drawbacks. Hg where you (IIRC) tag using some
> > file, so you get merging problems there (forgot specific, just thought
> > 'sucks'). Bzr.. not a swiss army knife.
> > My original plan was to leave everything for another year or so.. see
> > what the result is after that (progress made).
> > > > I know Git has something like:
> > > > git://git.gnome.org/~username/myrepos
> > > >
> > > > Is such a thing wanted? IMO I'd rather have real repositories (like any
> > > > SVN user can create repositories ATM). For pet projects that aren't
> > > > suitable as a general GNOME repository, use something other than GNOME
> > > > to host it.
> > >
> > > Oh definitely yes. Those are the main reason of the whole D in "DVCS"
> > > thing. You may get away without providing it, it would just mean that
> > > people will have to find another host for it. The reason? Lets see:
> > I don't understand this. Why not make a branch in cairo then? It is
> > hosted by the same thing, so you already have access to it.
> If everyone has commit access to the central module, yes, branches may
> do the same thing, at the expense of leaving tens if not hundreds of
> visible stale branches on your central repo. Something that didn't work
> with CVS. Not sure it's desired with any system. We sure don't like it
> in cairo. Our central repo only has branches for each stable series
> (named 1.0, 1.2, 1.4, ...).
> > Also wonder what happens when you have 1000+ users, all with different
> > repositories.
> I don't think even the Linux kernel has 1000+ users all with their own
We'll have something like that on one server.
> > > Here is the central cairo repository, the "upstream", the "Linus tree"
> > > of cairo:
> > > http://gitweb.freedesktop.org/?p=cairo;a=summary
> > Down ATM. :-(
> > oh no.. gitweb just takes 2 minutes to load (!)
> Weird. Takes less than 10sec here.
Maybe the proxy server or somethin
> > > This is Carl's cairo tree, holding branches with series of patches he
> > > has written that are undergoing review, or otherwise still not merged.
> > > Note that some branches were last modified more than a year ago:
> > > http://gitweb.freedesktop.org/?p=users/cworth/cairo;a=summary
> > >
> > > This is Chris Wilson's, another core cairo hackers:
> > > http://gitweb.freedesktop.org/?p=users/ickle/cairo;a=summary
> > > A series of commits by him typically holds more than twenty commits.
> > > Imagine submitting those to bugzilla for review...
> > >
> > > All major cairo developers have such trees.
> > >
> > > With a scheme like the above, I locally clone the upstream cairo repo,
> > > then I add:
> > >
> > > git-remote add cworth url-to-carl's-tree
> > > git-remote add ickle url-to-chris-wilson's-tree
> > > ...
> > >
> > > Then when I want to review a series of patches from ickle, called
> > > malloc-testing, I do:
> > >
> > > git-fetch ickle
> > > gitk ickle/malloc-testing
> > >
> > > gitk gives me a visual tool where I can see all commits in cairo's
> > > history plus the new commits in ickle's malloc-testing branch, syntax
> > > highlighted and all...
> > Can you give me the full commands to repeat above? Then I'll try to
> > figure this out.. hopefully. Btw: I do hope 'gitk' uses GTK+ right?
> gitk doesn't, but giggle does.
> Commands for above:
> git-clone git://anongit.freedesktop.org/git/cairo
> cd cairo
> git-remote add cworth git://people.freedesktop.org/~cworth/cairo
> git-fetch cworth
> git-remote add ickle git://people.freedesktop.org/~ickle/cairo
> git-fetch ickle
> See all remote branches:
> git-branch -r
> Inspect a remote branch:
> git log cworth/path-extents
> gitk cworth/path-extents
> > > Your changes look accurate, at least to me. Regarding git having to be
> > > installed on the remote server, I don't understand, isn't that the case
> > > for all systems? You sure need cvs server installed to serve CVS.
> > With e.g. bzr you can use normal sftp, it is just a lot slower. Not sure
> > if Git allows the same (no loss of functionality). Hg is actually pretty
> > nice. Does all sorts of things to make it faster (e.g. might compress
> > things differently, etc).
> Right. With git you have:
> http: slowest, anonymous, no port needed
> ssh+git: fast, secure, ssh port needed
> git: fastest, anonymous, port (and running daemon?) needed
http is even slow when it was pushed with git? E.g. for SVN we use
svn_dav/dav_svn and http is fast. For Git we'd need ssh+git and git
right? Might cause some problems with firewalls (sysadmin POV).
> > > > Note: tailor is *not* suited for converting GNOME modules! The DVCS
> > > > should have tools for this (SVN->DVCS).
> > >
> > > > - translator things:
> > > > - only checkout a file (highly preferred) / dir (like SVN)?
> > >
> > > This is not possible with git as it works with commits as a whole, not
> > > files. Two orthogonal ways of looking at the repo.
> > Does it always get the whole history? Others allow e.g. only doing a
> > minimal checkout and using the remote server for missing info (saves
> > lots of diskspace).. that is bzr.. Hg I still need to investigate (I
> > really hate that file merge thingy).
> Like Elijah responded, some sort of shallow clones were added.
Nice :-) Have to look into this.
btw: I might appear dismissive.. but that is just due to all the bad git
experiences compared to e.g. reading Bzr manual.
] [Thread Prev