> (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", 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.
>
>
> 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. 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.
> * The filesystem hierarchy contained in the work tree of a Git
> repository matches one-to-one with the hierarchy maintained
> in that repository.
>
> This one is kind of obvious ("what you commit is what you get
> on checkout") but this removes the doubt about getting the same
> hierarchy in the repository you're about to push your commits to.
>
> * In Git, each commit in a repository refers to the whole state
> of the project that repository tracks.
>
> clear for me and i understood in that way.
> * 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
> As you can see, there's no point to be concerned with having the same
> hierarchy of files and directories in the target repository: if you
> push what you committed locally there, the receiving repository will
> have your exact history, and these commits will obviously represent the
> same series of states of the project your local repository tracks.
> Should someone clone that remote repository then, and check out the
> branch you've pushed, their work tree will contain the same directories
> and files you've committed.
>
> i meant to have the same to keep a logical sense and maybe more for us to
not be lost... maybe my mistake :-)
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 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.
