Re: Git hosting

[Behdad Esfahbod <behdad behdad org>]

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.


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


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


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

Cheers,
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759