On Saturday 03 September 2011, Raphael Manfredi wrote: > And is it possible then to have these cloned repositories sync > directly from the public server, not from the local clone?
As Jeroen pointed out, you can add a second remote target for the shared repo if you want to push to it. It is also possible to configure Git to use that as default. The more straight-forward way, IMHO, would be to edit the URL of the "origin" target after cloning, though. That way you can have all your local repos set up identically, so that you don't have to remember to use a different remote name depending on which of your clones you are working on. You can use "git config" on each clone to edit the config file for you: git config remote.origin.url https://github.com/gtk-gnutella/gtk-gnutella This is the the scenario where you do _not_ have a local master clone, but all your clones are considered equal. For the opposite scenario, see next. > I want some clones to push back to the local master clone (for > integration purposes) Beware of dragons. Although it is, with some tweaks, technically possible to push into a repository that has a checkout attached to it, it is certainly not what you should so. If you want to push into a local shared repo from a bunch of "slaves", you should setup your shared repo as a so-called "bare" repository. These are repositories that only consist of what is normally the .git directory, without a checked-out working tree. These are the ones you push into. You can create a bare repository by cloning with the --bare switch. (The usual naming convention suggests to name the root folder of such a bare repository "projectname.git" as opposed to just "projectname" for the non-bare clones.) The real Git way for such a "hierarchical" code flow, however, is to use pull instead of push. In such a case, your local integration repo is a normal (i.e. non-bare) clone, and you pull the different development branches into it. > 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 have technical reasons to keep different directories, it's perfectly fine to do so. That would be just as if you were several persons, which is OK, of course. I just wanted to point out that, with Git, the source code management system is not one of those technical reasons in itself. > 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). That's the SVN way of thinking, because, with SVN, "checking in" involves both committing and pushing in one step. With Git, you commit early and often, even if you would be ashamed to share the result with anyone. Commits are local. Noone else can see them as long as you don't push. Make lots of commits, try things out, do silly things. Revert things. Eventually, after 20 commits or so, the result will be ready to be shared with other developers. Only _then_ you push. You can also, before you push, retroactively streamline your history of 20 commits to look more like a straight-forward development process without all those little bugfix commits, if you like. > 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). If your changes happen to be completely orthogonal to everything since the two branches departed, Git will simply re-apply the changes after the switch. But in general, you should either commit (which, since it is local to the clone you are working on (see above), does _not_ defeat anything), or use a special feature to temporarily store those changes away, called "git stash". > 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. I'm not quite sure how to understand your question. Either you merge the changes from sandbox X into the master branch, because X is done. If you then rm -rf the X directory, nothing is lost, because you have it in the master branch (including history). Or you don't merge, because you realize that all you did in X was a mistake. In that case, losing everything from X is exactly what you want, right? Perhaps I simply misread your problem. > 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. I don't think you "have to" adapt. I'm sure you will soon see it as a relief. Keep every habit that is really useful for development (so keep your sandboxes if you wish). Only throw away habits that originated from the limitations of centralized source code management. Sometimes it's hard to remember where a habit really came from, though :-) Bye, Hauke ------------------------------------------------------------------------------ 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
