[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What a modern collaboration toolkit looks like

From: David Kastrup
Subject: Re: What a modern collaboration toolkit looks like
Date: Thu, 03 Jan 2008 11:32:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

>     There would be no need to have write access at all.  I can alway commit
>     to my repository (even when I'm offline, a fact that should be a big
>     plus for Richard) and synching happens whenever something important has
>     be done and some core dev reviewed it.
> I am having trouble understanding what it _means_ to say that you can
> do a "commit" into your own repository.  That must be something very
> different from a "commit" in CVS terms.  Perhaps it is so different that
> the two are not comparable at all.

No, they are pretty similar, except that everybody has his own private
repository.  The repositories get synchronized not by commit and
checkout (those happen only locally), but by pushing and pulling.  These
operations are very much optimized to deal with merge conflicts and to
figure out what changes were already committed remotely.

Apart from "remote tracking branches" which you can set up (but don't
need to), the histories of various repositories tend to be different.
Before pushing something out (or sending around patches), you will
likely "rebase" on the repository your patch is referring to.  Rebasing
means rewinding the history to a common ancestor, applying all the
patches from the remote repository, then reapplying all local patches
that are not in the remote repository.  Merge conflicts may need to get
resolved then.  Afterwards, your branch history reads like just your
local changes on top of the branch/repo/state you rebased on.

One tends to rebase local branches from time to time.  For branches
which are distributed to others, it is nicer to just merge with other
repositories/branches since that saves the others from having to do any
rewinds leading to possibly repeated merge resolutions.  While you can
tell git to keep records of past merge resolutions (so that it will
resolve the identical problem automatically the next time), it is nicer
not to force this.

So basically, commit and checkout (and merges, though with an external
source) happen locally.  Synchronization with others happens directly
between repositories by pushing and pulling, and patch distribution.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]