On Tue, 13 May 2014 10:42:37 -0700 (PDT)
Alain <raf.n...@gmail.com> wrote:

> > (Bare repositories, which usually exist only for
> > storage/rendez-vouz purposes -- as opposed to development -- do not
> > have the work tree and contain what the ".git" subdirectory or a
> > normal repository contains.) 
> i not sure at 100% what do you mean by "rendez-vous folders",

You see, I have never used the word "folder".  And I sincerely suggest
you to stop doing this either: Git is not about tracking folders, it's
about tracking whole projects.  If you won't get the idea of folders
out of your head, you might later get troubles with understanding how
Git works.  Git only ever tracks whole projects; it is even unable to
track empty directories (!) -- you can only add files under its
control, and directories containing them become tracked purely as a
byproduct of this.

> but in VSS i used to have only files/folders syncing with valuable
> data for dev or relative to dev.
> i 'm not used to sync data (files+folders) as backup :D if this is
> what you mean by "rendez-vous" folders.

A "rendez-vouz repository" (*not* folder!) is one of the terms to
describe a central repository everyone uses to synchronize their
work -- that is, everyone eventually pushes their work into it and
fetches from it to see the work done by others.
What makes this "special" is that with Git, there's no need to have a
central repository as no one prevents you from directly contacting
personal repositories of other folks on your team (well, I mean,
logically; techincally there might be obstacles like the absense of
direct network connectivity between machines on which these
repositories are located).

> > You have to understand several simple things up front: 
> >
> > * Any Git repository is self-contained and self-sufficient. 
> >   It may communicate with any number of other Git repositories 
> >   (by fetching commits from them and pushing commits to them) 
> >   but they are not required to do so. 
> >
> this i understood, that's why i asked if to have a "work tree" where 
> several repositories are is not the best solution.

This cannot be a solution as this is simply not possible: a work tree
is a property of its repository -- a single repository.

Well, techincally it's possible to create a synthetic work tree which
contains checkouts out of different Git repositories intermixed but
this would be a highly specialized and unusual setup; no one does this
for development.

> You sync only what you work on and like that you can have 1 master
> branch per project, and not 1 master branch for all files/folders of
> all projects. at least this is how i see the best solution but maybe
> i'm wrong. 

You are perfectly able to keep all your files and folders of all your
projects in a single repository, just this is not too convenient
because it obviously creates more problems than it solves (and what
problems does this solve anyway?).
Typically people maintain one repository for one project.
But this is not a dogma: say, if a program Foo uses a library libfoo,
which is not used by anything but that program Foo, that's okay to keep
both in the same repository.

Conversely, if you want project A to depend on projects B and C, and
they are all relatively generic (to also be used by other projects),
you might make B and C available to A by using the so-called
"submodules".  Your Git book must have a chapter on this so read on.

> > * Since data exchange between different Git repositories is only 
> >   concerned with commits (and other objects they reference), 
> >   filesystem hierarchy of the project the source Git repository 
> >   tracks does not came into play at all.  That is, you can't push 
> >   the series of commits touching "documents" but not push those 
> >   touching "website1"; you can only push branches and tags, and all 
> >   these objects refer to the whole project's history. 
> >
> > yes this is the purpose of everything or nothing... atomicity in
> > fact :D

Uhm... What I actually wanted to convey is that the data
synchronization model Git implements makes it impossible to selectively
push/fetch only the changes made to a set of files/directories.

I mean, it's not like in Subversion where you can commit only changes
made to a single folder (and have the server create a synthetic state
for you, which consists of the old state of the project plus the
changes you've just sent); Git can't do that.  I'm highlightling this
because I felt you're a bit obsessed with folders. ;-)

May be "atomicity" is a sutable word to describe this, I dunno.
Usually this wording is invoked when we talk about fixating certain
changes in the repository, like you can't retarget a branch to point to
another commit if all the objects reachable from that commit are not in
the repository yet, and the things like this.

> And be sure to read up on "remotes" and "remote branches" before 
> > embarking on colaborating via a rendez-vouz repository (what you're 
> > about to do).  The crucial bit of understand is that the local 
> > repositories of you and your colleagues are not somehow subordinate
> > to your central repository -- they are all free standing and 
> > self-contained, even though they track the same project and keep
> > mostly the same history.  Understanding this paradigm will help you 
> > understanding the way repositories communicate. 
> as far as i understood what Linus T. told they are in fact after
> commits (or should be) identical... no master, no slave... like 2
> identical copies of the same content... 
> he told that since he developed it, he has no more backup as every
> time someone from his team can "reload" files or he can return in
> past using Git :D
> so till now the repositories on bitbucket, on my laptop, on laptop of
> my friend and soon on my NAS, are 4 identical copies after committing
> every changes....
> this is how i understood the philosophy :-)

You've got the philosophy right but again that's not what I wanted to
convey.  Many people coming to Git from a centralized (client/server)
VCS -- be it VSS or Subversion or whatnot -- consistently get bit by
the mindset they bring with themselves.

A typical case:  you create a local repository, start develop in it,
create five branches -- all with commits on them -- push everything to a
centralized repo then go to another machine, clone that centralized
repo and then have a "WTF?!" moment having found only the single branch
named "master" in the resulting clone.  Re-training your brain to
understand that the clone's branch "foo" is not the same as the central
repository's branch "foo" and it's not the same as the branch "foo" in
the Joe's local repository even though all these three repositories
logically track the same project, is crucial.

I'm not going to dive into full explanations here as I'm not writing a
book; just have my advice to make yourself comfortable with the idea of
remote branches and their interaction with local branches -- when you
will be reading the relevant material.  Do that *before* you'll get
serious on collaborating.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to