Re: Git hosting

[Olav Vitters <olav bkor dhs org>]

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
> deal.
> 
> 
> > > > > 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
> with:
> 
>   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
> 
> Hacking:
> 
>   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
> 
> Inspection:
> 
>   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)
> 
> Pushing:
> 
>   - 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
> repo.

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.

-- 
Regards,
Olav