Quoting Hauke Lathus <h...@pansensack.de> from ml.softs.gtk-gnutella.devel: :There are different answers to that question. The short one is probably :this: Make the second (and third etc.) clone not from the shared :repository over the network, but directly from your first clone through :the local filesystem. Git will then create all its immutable object files :as hard links. You may notice by the speed of the operation that the :contents of the object files are never physically copied.
And is it possible then to have these cloned repositories sync directly from the public server, not from the local clone? I want some clones to push back to the local master clone (for integration purposes) and some other clones to have direct access to the network copy. :That said, keeping checkouts of different development branches in :different folders is a practice that is much less useful with Git than :with SVN, because it is (in many cases) essentially a work-around for a :problem that doesn't exist in Git. With SVN, you often keep one checkout :folder for every branch you're working on, because switching between :branches is otherwise a tedious server operation. You don't do that with :Git. Most people have only _one_ clone, even when they are working on :ten different branches. That's because switching between branches goes :within the blink of an eye. Most of the time, it is done before you can :release the "enter" key after typing the "git checkout" command. :You create a new local branch for every little feature you develop, and :you change between these branches back and forth all the time. So when you change branches with git, how is it handling "unchecked-in" changes to files? Or do you have to always check in before changing branches? (that would defeat the way I'm using multiple sandboxes). Also, changing branches within the same directory requires updating "cscope", the tags, etc.... So even if it's fast at the GIT level and it handles pending changes (non-committed) easily, there's always the cost of re-updating these files. :If you say that you want to have 15 different instances of gtk-gnutella :_running_ simultaneously, that doesn't necessarily mean that you want to :_compile_ them all at the same time, do you? If not, you don't need 15 :instances of source code, because you only need it while compiling or :editing, not while running. And you can only _edit_ one copy at a time :anyway. 15 is somewhat exagerated. I have routinely 3-4 sandboxes with different changes in them. For instance, currently I have a "DOVE" sandbox, an "IPv6-Reeady" sandbox, a "maintenance" sandbox, a "Windows" sandbox and a "gtk2" sandbox. The gtk2 and Windows sandbox are likely to no longer be needed so I'll remove them (rm -rf). How do you remove a sandbox with git? If I "rm -rf" it, it will lose all its local history. The "DOVE", "IPv6-Ready" sandboxes both have non-committed work (I only check work in when it's working, not in the middle of changes). I'll have to adapt my work habits to GIT, that's sure, but I don't think I can give away the "sandbox" concept. Raphael ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
