On Tue, 2 Aug 2011 11:35:30 -0700 (PDT)
Redeux <redeu...@gmail.com> wrote:
> Hello, i have Problems understanding the basic idea behind DVCS.
> In CVCS you commit into central repository, which is up-to-date.
> In DVCS you use a local repository for commit. If other developers
> want to use your data, they have to pull the data from your repository
> or from a central repository.
> I have problems understanding the advantage, because if you want to
> have the actual data, it produces extra work.
> They have to pull data from every developer whos data they are using
> or every developer has to push into central repository (that means
> they have to commit AND push).
> For example, A, B and C are working together on a software project. If
> A wants to have the actual data, he has to pull the data from B and C.
> And if they use central repository B and C have to push into central
> repository (after every commit to guarantee that the central
> repository is up to date) and A has to pull the data from central
> Using a CVCS results in simple committing and update?
> Am I right or is there anything i misunderstood?
While Thomas already cleared up some of the points, I'd like to add.
First, the word "distributed" routinely provides certain misconseption
among people first looking at the thing because they tend to imply
you're somehow forced to go distributed. This is simply not true: if
your team of N people uses a DVCS for development, this does not mean
everyone in the team has to set up N-1 links with the other members of
the team--you can happily use a centralized "reference" repository
everyone pushes to and effectively have a "star" linking scheme as with
CVCS. In reality, the "distributed" term refers to a neat property of
these systems: instead of using abstract "versioning" on files or whole
repositories (cf. CVS and SVN) they use the concept of unique
identifiers on commits (snapshots of the whole repository state) and
objects these commits refer to. This allows minimal selective
transfers of required lines of development from one repository to
another. To understand the idea, it's best to start from reading "The
Git Parable"  which explains this in the simplest way possible.
Second, while DVCSes indeed differentiate between committing and
pushing your changes, there are two points to be made:
1) That way of operation is not necessarily cast in stone. For
instance, cool little Fossil  by default works in the so-called
"autosync" mode, in which before each commit, an attempt to fetch is
performed to see if our leaf diverged from its "remote" version,
and after each commit an automatic push is performed. So it
basically works no different from Subversion. This can be turned on
or off anytime. Git, to my knowledge does not have built-in support
for such kind of thing but I suspect it either can be emulated
or at least some working policy could be adopted.
2) I think the fear of needing to manually push what has been committed
is mostly rooted in the CVCS-incurred mindset in which you do lumpy
gross commits implementing big changes--simply because it's hard to
do it another way. In Git, you have tools to make small, atomic,
incremental commits, implementing changes which are small, localized
in space and/or thought process. Hence, when in a CVCS you would
have one big commit, in Git that same changeset would consist of
several commits. Suddenly, separation between committing and pushing
starts to make sense: you're pushing *series* of changes implementing
features (or fixing bugs or whatever), not mere commits. This makes
even more sense after your read about history re-writing which
allows you to first hack a series of not so beautiful commits and
then transform it to something more digestible by peer reviewers
and then push this prettified series throwing away the original one.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at