<html> <body> Thanks Baz and Carl for your informative messages. I'll definitely check out those links. Offline functionality indeed can be very useful, and I don't think it's possible with Perforce or SVN. I have more experience with Perforce; I used to work in a gaming company, our engine was in Perforce and each developer had his own private branch to work in. Once the feature was tested and the branch compiled, a dev would integrate his change into the root branch. I found that development model very easy and safe. I do realize it might not be adapted for more de-centralized development though. Carl: Yes, the commands you listed are what I used as of now. But I still have a few gripes (which might be answered by the info on the links you provided): -I'm on Windows, and it's already been somewhat painful installing and getting Git to run. Nevermind you get cryptic error messages about index.lock when your repository is on FAT32. -I edited a makefile but it's a hack I want to keep without submitting it. So I don't want to commit the change and submit it later on by mistake. How can I exclude a file from getting committed while still getting any updates from the original repo? The folks on the IRC git channel recommended doing another branch for that one change but I don't think it's the right solution. -So now I'm careful about which files get committed because I want to exclude that makefile. I just edited stuff in the perf/ folder. So I go in the perf/ folder and type git commit -m "message" * Git tries to commit every file in perf/ even untracked ones I never asked it about. So reading the doc I see the -a flag should do the job. But then the -a flag affects every modified file in the repo and ignores the path I'm currently in. I would've thought Git would apply -a only to the files I'm currently asking it about (in perf/). So it seems my only option is to type the name of all the individual files I modified and want checked in on the commit command line. 20 minutes later I still don't have a good solution for this simple operation that takes 2 clicks in Perforce (create a new changelist and move the modified makefile there). -I then find out I can do this with git reset. It seems like git reset can either undo a commit or mark a file for not being included at the next commit? those are two very different functionalities in my mind. -Seemingly no good way of doing a 3-way diff when I do a merge or review a patch, at least on Windows? -Definitions in the doc: checkout, staged, unstaged, and other terms seem used all over the doc without definitions. For a VSS/Perforce user, a checkout is making files writeable and telling the SC that you'll be editing them In Git, it seems checking out is switching branches. I'm still unclear about staged and unstaged. It seems to mean whether a file will be committed at the next commit operation, but I couldn't find a definition in the doc. -Some commands don't seem symmetrical: for example, git add will either add a file to the index or mark a modified file for the next commit. I'd expect git-rm to either remove a file from the index OR unmark it form the next commit. Instead git-rm removes a file from the index and the working tree. You have to use git reset for unmarking files from next commits. So the opposite of git add is either git rm or git reset depending on what you do. -In switching branches, it seems that you can't have any uncommitted changes? So if you want to switch to branch B while working on something in branch A, your changes get to branch B, might get checked in by mistake in that branch, and then when you switch back to branch A, you lost the changes? I think I read about this scenario in the Git doc but I can't find it now. -I just miss a good GUI like Perforce's one to see in a glance everything about your project. I appreciate using a source control software intuitively without thinking too much about it. I could do that my first week with Perforce. Right now I find myself spending almost as much time reading the Git doc as working on code. Source control should really be as much of a transparent tool as possible. Anyways, these might all be "Git newbie" issues, but the fact that I didn't encounter these issues with other SC software suggests that Git is indeed harder to use. I do appreciate though it might have unique features that make it the only tool for the job. My experience might be also worse because I'm using it on Windows through Cygwin and can't use any of the GUIs available. Antoine At 11:53 AM 1/10/2008, Carl Worth wrote: <blockquote type=cite class=cite cite="">On Thu, 10 Jan 2008 03:22:15 -0500, Antoine Azar wrote: > Slightly off-topic, but I was just curious as to why we use git for > Cairo's source control? Here's the original message I sent out proposing the switch from cvs to git nearly two years ago: <x-tab>        </x-tab>[cairo] Plans (and motivation) for moving cairo from CVS to git <x-tab>        </x-tab> <a href="http://lists.cairographics.org/archives/cairo/2006-February/006255.html" eudora="autourl"> http://lists.cairographics.org/archives/cairo/2006-February/006255.html</a> I think the concepts and motivation I introduced there are still current. And my hopes for git have all played out very well. I've been very pleased with the increased productivity that it affords. The things that have changed since I wrote that are that the user interfaces and tutorials for git have improved dramatically. For example, here's something I put together showing how easy git can be to learn: <x-tab>        </x-tab>A tour of git: the basics <x-tab>        </x-tab> <a href="http://cworth.org/hgbook-git/tour/" eudora="autourl"> http://cworth.org/hgbook-git/tour/</a> My rationale for working on that is here: <x-tab>        </x-tab>Git is easy to learn <x-tab>        </x-tab> <a href="http://cworth.org/hgbook-git/" eudora="autourl"> http://cworth.org/hgbook-git/</a> > I'm admitedly a total beginner with git, but > it seems to me the only advantage it has over something like Perforce > is the ability to generate and email patches. Other than that, I find > it much less intuitive than other solutions such as Perforce or SVN, > which can be just as easily "distributed" by creating branches off > repositories. Uhm, no. The word "branch" doesn't make something distributed. And particularly the incredibly broken concept of "branch" that svn provides, (simply parallel directories). What makes git distributed is the following characteristics:   * Disconnected operation, (make commits on an airplane, for     example).   * Not just creating branches, but *merging* them, (at the level of     multiple merges per day with zero pain).   * Everywhere the code lives is a full-fledged repository, just as     functional as any other, (unlike the very distinct notions of     "repository" and "working copies" like svn has). There's *no*     notion of a "central" repository in any technical sense. I'm quite certain that svn has none of those characteristics, (I have no knowledge of perforce, so I can't comment on it). The modes of development made possible by a distributed system just don't exist with a centralized setup like svn. And if you haven't experienced it yet maybe it's just hard to appreciate it. Here's a random screenshot I googled, ("gitk screenshot"), that might give some of a feel for the kind of regular branching/merging that happens everyday when you're using git and that would be unthinkably hard with any of the centralized systems: <a href="http://www.flickr.com/photos/malcolmtredinnick/1516857444/" eudora="autourl"> http://www.flickr.com/photos/malcolmtredinnick/1516857444/</a> I will confess that the "write a single-feature and mail a patch" mode that you've found yourself in so far doesn't really showcase much of the great features of git. But then again, this mode can be really simple to: <x-tab>        </x-tab>git clone git://anongit.freedesktop.org/git/cairo <x-tab>        </x-tab>cd cairo <x-tab>        </x-tab># hack, hack, hack <x-tab>        </x-tab>git diff > feature.patch <x-tab>        </x-tab># send email Clearly, that's no harder than any centralized system, right? And I'd be fine if an initial contributor to cairo did no more than that. Now, afterwards, if this contributor wanted to submit more later, I would encourage and teach more. For example, it's much better to replace the "git diff" step with: <x-tab>        </x-tab>git commit -a <x-tab>        </x-tab>git format-patch origin <x-tab>        </x-tab># send email with the commit-message.patch Since this gives the author a chance to write the commit message describing the patch, and that's really important. I will admit that the format-patch command-line is fairly ugly. Ironically, at the next stage the commands get a bit simpler. When the contributor reaches this point I'll encourage the contributor to start pushing commits directly to cairo's central repository. The emailing of patches will still often happen for sake of review, but the actual git commands necessary for pushing the changes out become simply: <x-tab>        </x-tab>git commit -a <x-tab>        </x-tab>git push So I'm curious what you see as not being intuitive here. Is there something that's not intuitive about the above command set? Or was it more that it was hard to find a description providing something like this list of commands? -Carl </blockquote></body> </html>