[cairo] Use of git
cairo at antoineazar.com
Thu Jan 10 16:04:24 PST 2008
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.
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
>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
> A tour of git: the basics
>My rationale for working on that is here:
> Git is easy to learn
> > 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.
>The word "branch" doesn't make something distributed. And particularly
>the incredibly broken concept of "branch" that svn provides, (simply
>What makes git distributed is the following characteristics:
> * Disconnected operation, (make commits on an airplane, for
> * 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:
>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
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cairo