Re: [git-users] Re: how to change message of old commit

2012-07-21 Thread Konstantin Khomoutov 
On Sat, Jul 21, 2012 at 07:43:31AM +0530, Rustom Mody wrote:

  I suspect that you are in rebase mode. That is, you're in the middle of
  rewriting som history, and Git is waiting for you to type things like git
  rebase --abort or git rebase --continue. If you just want to get out of
  this mode, I reckon also a git reset --hard master should get you back to
  how you left things in master branch.
 
 
 It is said about vi: The text editor with two modes... one that beeps and
 one that corrupts your file
 
 Currently I have the same expertise at git that I had when first learning
 vi (many years ago)
 
 Can I find a summary of 'git modes' somewhere?
Please stop inventing bullshit.  It's natural, that when you're starting
an interactive (!) rebase and then tell git you want to edit a commit,
Git has to be told when you're done with your edits.  And when Git
stops carrying rebase steps at the commit you told it you want to edit,
it tells you in clear words what to do when you're done:

foo% git rebase -i HEAD~3
Stopped at 183fe3c... 3rd commit
You can amend the commit now, with

git commit --amend

Once you are satisfied with your changes, run

git rebase --continue

You did not pay attention to this (quite wordy) message and are now
trying to make up sarcastic jokes.  Please don't.  Start from reading
`git rebase` manual, in particular the --abort option to `git rebase`.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] SSH keys required for SSL authentication/authorization?

2012-07-21 Thread Konstantin Khomoutov 
On Fri, Jul 20, 2012 at 02:10:05PM -0700, TSU wrote:

 Yesterday I observed on the Git IRC a conversation that SSH keys were not 
 required for SSL sessions( would have responded if my Freednode account 
 wasn't having problems). 
 
 Aside from the fact (AFAIK) github only supports SSH for key testing and 
 nothing else, I was under the impression these same keys are re-used for 
 authenticating SSL sessions as well, implementing a kind of 2-factor 
 authentication (SSL keys to prove your machine, username/password to prove 
 your human identity).
 
 Are SSH keys required or not for SSL connections?
I don't quite understand the question, but let's just try some things
clear -- maybe this will help you.

First, SSH and SSL have nothing in common except for the word [S]ecure
and the naturally following fact they secure something (SSH secures the
[SH]ell access and SSL secures the [S]ocket [L]ayer).  These are
completely disjoint protocols invented for differing needs.

These protocols also use different approach for what you call keys.
SSH uses shallow approach to keys: a client generates a pair of
keys -- one public and one private, -- then transfers the public part to
the server and adds it to an *explicit* list of trusted keys.  Hence the
server either trusts that key or not; nothing else.  The client actually
does the similar thing by checking the server's key's fingerprint to see
if it's known and trusted.
SSL uses hierarchical approach to its keys, which it calls
certificates: this stuff involves certification authotities (CAs) and
trust chains they create.  The whole topic is too deep to cover here but
the end result is that usually either side or both explicitly trust some
CA, and through this fact they tust each other.
In either case, the wire format of the keys used by these protocols and
the semantics of their usage is different.

One last thing to note is that while SSL/TLS is based solely around
those X.509 certificates, SSH defines various methods for authentication
of the client to the server: besides the pubkey method we've just
discussed, it supports the very popular keyboard interactive method,
Kerberos authentication and GSSAPI (SSPI in Microsoft lingo) which can
also do Kerberos.

So no, the same keys can't be used for both SSL and SSH.

As to github, I think they implement two modes:
1) SSH keys are used to access the repo via SSH.  You associate your SSH
   key with your github account and so when you're trying to
   authenticate the next time, Git knows who you are from your key.
2) SSL is used to simply encrypt the conversation with the server, and
   then HTTP (which tunnelled over SSL) uses simple password-based
   authentication method called basic to verify your identity.
   See https://github.com/blog/642-smart-http-support for hints on this.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.