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.
