Re: Git hosting

[Olav Vitters <olav bkor dhs org>]

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.

> > > 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.

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.

Also wonder what happens when you have 1000+ users, all with different
repositories.

>   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 (!)

>   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?

> > Questions:
> > - What is the DVCS version of svn:external(s?)
> 
> Umm, I'm sure git has this feature.  Carl tells me about it all the
> time.  Don't remember the name right now.

Note: subprojects (something like that) is crap. Not implemented
correctly (this I investigated). Bzr has some plans, but nothing that
works (AFAIK). Hg: no idea.

But perhaps we can avoid that svn:externals? Although that would require
someone looking into existing usage and finding a solution (I'll try --
but I don't pretend to understand build systems).

> > - I know Git is preferred because most know it. However, what is the
> >   main requirements of an DVCS?
> >   - fast enough (I know Git is the fastest, but IMO fast enough should
> >     do)
> 
> I add to that: Have entire project history offline.  Or at least have a
> usable option to do so.

Isn't that with any DVCS?

> >   - ehr.. distributed? ;-)
> 
> Definitely, see above. ;-)
> 
> >   - I've edited http://live.gnome.org/DistributedSCM.. could you please
> >     go over that? Please keep it 'post' integration. e.g. the SVN link
> >     is not important. Only that you can reliably convert the repository
> 
> 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).

> >     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).

> >   - same for documentation things
> >   - *very* easy to commit to e.g. gnome-2-22 branch, 'trunk', etc
> 
> One can write shell scripts that make it very easy to do so...  We can
> even write shell scripts and a simple custom service, to checkout fa.po
> for gnome-2-22 branch of gucharmap, let me translate it, and commit upon
> completion.  That really holds with any VCS.  For example, with SVN,
> tagging (and branching too) is REALLY HARD.  I use the following script:

Maybe integrate with damned-lies. That knows the .po files (not always
in the same place, sometimes multiple in a repos, etc). Just need
something that makes it simpler.

I don't think there are scripts that change git --> usable though.

> #!/bin/bash
> if test x$# != x3; then
> 	echo gnome-tag module tag release
> 	exit
> fi
> svn copy svn+ssh://svn.gnome.org/svn/$1/trunk svn+ssh://svn.gnome.org/svn/$1/tags/$2 -m "Tagged for release $3."
> 
> Yes, having to remember/type URLs is really hard, when compared to
> "vcs-name tag tag-name".

I know, branching/merging/tagging is crap. Mostly the merging/tagging
part.

> > - I *really* *really* like something with good and easily usable Python
> >   bindings (better that SVN one.. feels like C in Python)
> 
> Well, this one git is definitely (far) behind competition.

I know :-(

> > - All DVCS can do something like svn export
> >   $vcs://$vcs.gnome.org/repos/path/$FILE right?
> 
> Humm.  Not so sure.  Sounds like git-checkout really.

Hrm. Don't understand why all those commands have to have a different
meaning in Git. Reset that isn't reset, etc.

-- 
Regards,
Olav