[sane-devel] Git repositories are up

[Julien BLACHE]

Chris Bagwell <chris at cnpbagwell.com> wrote:

Hi,

> Perhaps an additional set of tips for us first timers trying to simulate cvs
> operations.  It may save you a few minutes of searching.

I intend to write another mail to cover a few basic things, but I'm a
bit short on time :/ (why do things have to come in all at the same
time?)

> - "git pull" is like "cvs update".

In the simple case, yes. That doesn't hold for the more complicated
cases, though.

git pull is git fetch + git merge.

When you clone a git tree, you're effectively creating a new branch of
this tree - each working copy is a new branch. Your working copy
contains one or more branches named origin/* which correspond to the
branches in the tree you cloned from.

origin/master is thus the master branch from the remote tree you
cloned from.

git fetch will fetch the remote branches and update the corresponding
origin/* branches in your working copy.

git merge will then merge the current branch with its parent branch,
so if your current branch is master it will merge in the changes that
happened in origin/master.

In the simple case, that is, your working copy is up to date wrt its
origin/* counterpart, the merge is a fast-forward, ie there is nothing
to merge and your working copy's HEAD now points to the same commit
its origin/* counterpart points to.

In the more complicated case, your working copy is behind and with
changes, which means both your working copy and its origin/*
counterpart have evolved since your last pull.

In this case, git merge will merge both branches and create one or
more merge commits.

Merge commits are useless noise in most cases and they should be
avoided as much as possible in this context. So in this case, what you
should do is (assuming you're working on the master branch):
 - git fetch origin/master
 - git rebase origin/master

This will rebase your local master branch on top of the remote master
branch. That means your local commits will now be on top of the remote
branch's current HEAD. Conflicts may occur, which you'll have to
resolve. Commits being rebased are applied one after the other and git
rebase will stop at each conflicting commit, so you can fix the commit
and then continue (git rebase --continue).

So you had:

 o denotes origin/master commits
 c denotes local commits
 H denotes origin/master's HEAD
 h denotes local HEAD

 -o-o-o-c-c-c-c-h
      \-o-o-o-o-o-H

After the git rebase you'll have

 -o-o-o-o-o-o-o-o-H-c-c-c-c-h

And this means your history is now flat, free of merge commits, and
you can push that out to the shared repository.

Why are merge commits "bad"? They're a pain when reading the history,
as not everything in the commit will be obvious, and they're an
absolute PAIN when bisecting. It's hard to decide what to do when
bisecting a merge commit.

And, above all, they're useless as you just have to rebase before
pushing out.


If you are afraid of losing data when doing a complex operation, git
tag is your friend. Add a temporary tag on your current HEAD and
you'll always be able to go back easily. Delete the tag once you're
done so as to not leave around a lot of useless tags.

(if there are any git hardcore users lurking around, yes, the
terminology I used is not always very git-y)


The git manpages are usually quite good with examples and
illustrations and all. The manpage for git blah is git-blah.

> - The two step operation of "git commit -a" followed by "git push" is
> similar to "cvs commit".
> - Seems the standard protocol for commit messages is:
>
> [ one line summary of change ]
> [ empty line ]
> [ multi-line description of change if required. ]

Yes that's it. The first line is like the Subject: of a mail, it's the
one-liner that describes the commit. You can elaborate on the changes
after that if you feel like it.

> And a few possible issue that I'm sure your aware of Julien.
>
> - I didn't receive a commit email.  Could be mail server not sending to
> sender.

I'll need to debug that. I wrote and tested the commit scripts back in
January and everything was working OK :(

> - Sane webpage still points to cvs on download page.

Yes that needs to be done, thanks for the reminder.

(Damn that mail took more time than I had :)

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb at jblache.org>                                  GPG KeyID 0xF5D65169