I'm sorry if I'm saying something that was already said, since I joined this group just a day or so ago...
On Sat, Jan 3, 2009 at 3:17 AM, Victor <[email protected]> wrote: > All suggestions have been very welcome and appreciated! Thank you for > pointing out my erroneous statement that providing a password is > mandatory! I didn't even consider that that was connected to when I > created the key itself. The password aspect works like this: (1) there's a password that github requires from you, to allow access to your private repo; I dont use this method; it's too tedious (2) to avoid that tedium, you give github your public key (I did this when I signed up, you may have done it too). Your local machine has the corresponding private key, which is used to authenticate you every time you connect to your private repo on github (3) this private key of yours -- when you first create it using ssh-keygen or eqvt -- can be specified to have a password to protect it. Choose a good one. Preferably a pass"phrase", not just a password --- at this point every operation which requires that private key will prompt you for the passphrase to unlock it so that ssh can send it out to the other side. (4) to avoid that you use ssh-agent or something eqvt. I dont have Windows but I've been told on Windows there is something called "pageant" that comes with putty; sorry for being a little vague on this. What ssh-agent does is that it takes your passphrase one time, and then handles all requests for it from programs that are directly or indirectly under its control. The simplest way to run ssh-agent on Unix-ish boxes is to say: ssh-agent bash which will ask for your passphrase, and then start bash as a child process. Within that bash session, and any other programs spawned by it, all requests to the passphrase-protected-private key are mediated by ssh-agent without bothering you to keep typing in stuff. When you exit out of that bash session, ssh-agent exits and your passphrase is forgotten, your system is secure again. This lets you limit the duration for which your system has the unprotected private key hanging around in memory (it's never written to disk even in this mode though, so a sudden power failure does not compromise it). There are other ways -- my current KDE setup uses something called keychain, which works even more globally (across an entire KDE session), but the minimal stuff above is good enough for most hack-hack-hack-commit-push-pull-repeat purposes. Please note that so far we're still talking about ssh, with your private repo on github merely being an ssh server you wish to access. In particular, nothing above is specific to git -- it applies to any access that requires ssh. > However, I'd still like to set up my git configuration to pull and > fetch from the public URL of my repository and to push to the private > one (with @ and : in it). Perhaps by fiddling with my origin reference > somehow? Is this possible? Is this question GitHub-related enough? :) Now we come to the git part. Normally the same "remote" is used for both push and pull, but since you can't push to the public URL, you use the private one for both anyway. In you care, if I understand you correctly, you want git push # uses private URL git pull # uses public URL This is doable, and I've just tried it (locally, using a file:// url as the private url and an ssh:// url as a public one) To start with, note that "git push" defaults to the "remote" called origin, so first do this: git remote add origin <your-private-url> At this point a git push should just work (modulo all the password stuff above) Now you need a different "remote" for the public part, so: git remote add puborigin <your-public-url> A "git pull" will use the following two config variables to fetch and merge, if no arguments are given, so set those up (they're documented in git help config, not git help pull or git help merge): git config branch.master.remote puborigin git config branch.master.merge refs/heads/master ("master" is the branch here; if your normal work is in some other branch you should substitute that instead). Now a git pull will use "puborigin" while a git push will use origin, and since they're the same repo, it'll all work fine. There may be other/better ways of achieving this, but this worked fine in my testing. I hope this helps... Sitaram --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
