[cairo] Use of git

[Antoine Azar]

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:
>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:
>
>         [cairo] Plans (and motivation) for moving cairo from CVS to git
> 
>http://lists.cairographics.org/archives/cairo/2006-February/006255.html
>
>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:
>
>         A tour of git: the basics
>         http://cworth.org/hgbook-git/tour/
>
>My rationale for working on that is here:
>
>         Git is easy to learn
>         http://cworth.org/hgbook-git/
>
> > 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:
>
>http://www.flickr.com/photos/malcolmtredinnick/1516857444/
>
>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:
>
>         git clone git://anongit.freedesktop.org/git/cairo
>         cd cairo
>         # hack, hack, hack
>         git diff > feature.patch
>         # 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:
>
>         git commit -a
>         git format-patch origin
>         # 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:
>
>         git commit -a
>         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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20080110/b2231f85/attachment.htm