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 _______________________________________________ Gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
