Op 3 sep 2011, om 08:59 heeft Raphael Manfredi het volgende geschreven: > 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.
The default is to pull and push to 'origin' however you can add aditional remotes, for example you could have an origin and local. If you want to sync local only you could do git pull local and if you want to sync from remote you could do git pull origin. > 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). Depends, files changes that are not in the current git repo are left alone. Files that are version controlled need to be either checked-in, stashed or over written. Stashing a commit is like putting your changes on a bookshelf and fetch them back when you want to continue. Ideal for modification that should not be committed but you don't want to get lost. I don't know if it is possible to auto stash on a checkout so it will put those changes away and automatic pop them when you switch back to that branch. > > 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. I don't know about that, and how long it takes. But if that is fast enough, you could use git hooks for example with a post-checkout hook. > 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. Sounds like perfect branches to me. That way you can keep your history more fine granular, and you also can easily revert to previous checkins on that branch. > > 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. Just remove the branch (git branch -d). Just don't publish your sandboxes / local branches to the public repo. - Jeroen
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ 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
