On Tuesday, May 13, 2014 8:29:21 PM UTC+2, Konstantin Khomoutov wrote: > > On Tue, 13 May 2014 10:42:37 -0700 (PDT) > Alain <raf....@gmail.com <javascript:>> 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. > > ok, i will give a try to forget this word "folder" :D anyway i'm not taking it like that.... i take Git as a tool for sharing between people (not necessary located in the same country) a project and to let team members to always have source code up to date (if commits/fetchs are correctly done) so projects includes files and "folders" :( but i understand it as a collection of items that form a project)
> > 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). > > yes for sure and this is the way as i understood it. i just want to use an online git supplier as we (with my friend) are not necessary online at the same time so to avoid to wait 1 or 2 days delay for getting code up to date, we would use a 24/7 online git repository to avoid such issue. Later and if our goal is reached, we will have our home git repository solution 24/7 so no more need of such external git repository supplier. for sure if we were both online during the same time almost, we could directly from each other sync. > > > [...] > > 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. > > this is something i didn't catch firstly and i have to pay attention about that... because i expected branches to be identical...and based on what you say, in fact it looks like cloning does only a "snapshot" of last/up to date branch and "renames" it as master branch... if i can allow myself to simplify what you said. so thanks for that info, i will keep it in mind and take care about this part :-) -- 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.
