Re: git patch

[Johannes Schindelin]

Hi,

On Wed, 6 Dec 2006, John Mandereau wrote:

> Johannes Schindelin wrote:
> 
> > On Tue, 5 Dec 2006, John Mandereau wrote:
> > 
> > > I can easily do all common operations (including push), except that I 
> > > don't know what should be the best way to merge branches in order to 
> > > push them to git.sv.gnu.org (but Erik will certainly tell us in his 
> > > tutorial ;-)
> > 
> > Suppose you have set up a shortcut for git.sv.gnu.org like this (in the 
> > lilypond working directory):
> > 
> > $ git repo-config remote.gnu.url git://git.sv.gnu.org/lilypond.git
> > 
> > you can merge the master easily with
> > 
> > $ git pull gnu master
> > 
> > which means that you pull (=fetch & merge) the branch "master" from the 
> > remote "gnu".
> 
> Thanks!

You're welcome! After all, I feel guilty I am the reason that the LilyPond 
developers looked into git. So I try to make up for it!

> I usually use "cg-branch-{ls,add,chg}" to manage remote branches and "cg
> update <remote branch>" to pull, and I'm happy with that.

That is okay. I do not use cogito since a long time (portability problems 
drove me away from it), but as long as you are happy, I will not complain. 
You said you pull a remote branch? IIRC a cg-update actually updates your 
local branch, i.e. it merges the remote branch.

> > BTW what were the most difficult things for you to learn about git, and 
> > what things would you like to have explained?
> 
> git is much more complex and powerful than cvs, so it takes time to 
> understand all git concepts. I haven't read all git documentation, I 
> just wanted to get quickly started, so I don't want to complain :-)

I am a bit biased, of course, but I do not think git is all that hard. I 
agree that there is not enough "QuickStart"/"Crash course"-ish 
documentation around, but at least we try...

One of my favourite things about git is that it does not hide, but 
promotes the underlying concepts.

For example, the "index". Git's index is the staging area. With CVS, you 
could do partial commits, i.e. commit only part of the modified files. In 
Git, you can see the intermediate stage (where all to-be-committed files 
are), if you want, and this is also the area in which merges happen.

Another very powerful concept of Git is how it handles branches. In CVS, a 
branch is a complex thing, and difficult to handle. In Git, a branch is 
just a pointer into a commit graph. Thus, branching is _very_ cheap.

> The only thing I'd like to have explained is the best way of merging 
> remote branches, for example on LilyPond git repository. I don't think 
> I'll need to do that, though (that's rather the developers' work, but 
> I'm just curious about it).

It is easier than you think: you can already do it by calling

$ cg-update git://git.sv.gnu.org/lilypond.git#master

if I remember correctly. Cogito tries to hide many good concepts from you, 
for simplicity's sake. Thus, in one working directory, you can only work 
on one branch. You can track multiple branches, but the checked out state 
represents the tip of just one branch. And "#master" just means: the 
branch-to-be-merged is called "master" in the remote repository.

With Git, you are _encouraged_ to switch branches. For example, if you 
want to test what is in Han-Wen's branch called "hanwen", just do

$ git checkout hanwen

Of course, you should have a clean state to begin with, i.e. no 
uncommitted changes. But if you had that, and checked out another branch, 
_only_ those files were updated that really were different. Thus, 
switching branches is _cheap_.

I think I already talked enough about Git for today, but feel free to ask 
questions. Remember: the dumb questions are those never asked.

Ciao,
Dscho