Short HOWTO on using git for Samba development

[Alan DeKok]

simo wrote:
> The only downside of this is forgetting, missing parts.

1) commit
2) push commits to a different server.

  What's to forget?

  If you still want to send patches, use a "trunk" and a "branch".  Then
create the patch by diff'ing the two.

>> The other advantage of using something like git is that
>> branch maintenance is reduced as individuals no longer
>> have to checkin to multiple branches.  The SAMBA_3_0_*
>> branches we have in svn will simply go away.  Of course,
>> the patch release model doesn't go away, but the responsibility
>> shifts.
> 
> Uhmm how this is true? I mean, in some case the code need to be
> different between 2 trees, who will adjust the patches to apply
> cleanly ?

  Someone has to pull the changes from one branch to another.  If the
changes don't merge cleanly, they are edited, committed, and then pushed.

> Ahh so more people can commit on the same tree?

  In git/mercurial, each checkout *is* a tree.  All commits are local,
so there's no problem.  Then, commits are pushed to a central tree.
That tree can have multiple people pushing to it.

> I didn't understand this, if that works then I guess we could end up
> with the best mix between centralized and distributed development,
> sounds interesting.

  I've used mercurial in a number of projects.  It's much better than
anything else I've used, and the repositories are smaller than git,
too!.  It's simple, easy to use, and the tool just doesn't get in the way.

> Ok, but to really test the D in DSCM we need to be more than one and
> test how the exchange of patches between individual trees works.

  "very well" is my experience.

  If N people are working on a project, it's usually useful to set up a
central repository for them, separate from the main tree.  That way they
can commit to their local trees, and they still have a central point of
coordination.  This subgroup tree can also have a copy of the main
trunk, so that merges from trunk to development branch happen only once.

  Then, when development finishes, you can push the changes or a patch
back to the main trunk, knowing that you're in sync, and that everything
works.

  Alan DeKok.