Re: libssh2 master 8dabb1c... added knownhost.c to makefiles.
> If I got the rest of your post above right then I'm practically not
> able to correct a commit message afterwards which I feel is
> horrible bad.
You can change commits indefinitely without any problems (other than
learning how to do exactly what you want) after you have committed,
and with hassle ranging from none to severe (depending on project
size and workflow) after pushing your commits to somewhere else,
where they can not easily be backed out manually. The fact that git
tracks all content (data+metadata) in it's commits means that the
repo history graph changes if a commit message would change. Not all
git tools can cope with that, but it's certainly technically possible
to handle the situation.
The benefit, again, is that a commit id will always mean the exact
content, including history, so you don't really have to host anything
yourself just to be sure about the contents. If you can get that same
commit from somewhere else, you can be sure it is in fact the
contents that you created. Good for backups.
> And regarding the SSH stuff, well, I take a look,
> probably ...
Are you on Linux, Windows or Mac? There are SSH agents for all, but
they work slightly differently because of how they integrate with the
On Linux one easy way to test is to start the OpenSSH ssh-agent and
let it start a terminal:
The new xterm can communicate with the agent, and you can add your
(-c means you will get asked when the agent is asked to use your key.)
Then enter your passphrase once, and after that ssh can find your key
in the agent without asking for the passphrase each time.
Mac also has OpenSSH, but it's nicer to use something that
integrates better with the rest of the system; look for SSH Agent:
For Windows and PuTTY there is Pageant:
> I couldnt make out one point which makes me start loving GIT - in
> fact I hate it, sorry to say that.
I think that's too bad, because I kind of like git. But it is very
common, and frequently cause for flamewars. :)
> The biggest downside for me with GIT is:
> - not beeing able to change commit messages after push without
> having the crowd throwing rocks on me
Maybe always look at git log before you push? (Script it.)
Or just be even more careful when you originally write messages?
Another idea is to stage work in another local repo (or branch,
because branching is so fast and cheap) first, and pull/merge from
that into your first repo/branch, reviewing the commits and fixing
stuff that needs some more love, before you push.
> - commit IDs 40 hexchars long which nobody can just type in
Again, they can be abbreviated, as long as they remain unique.
> Certainly SVN has its quirks too, but at ASF we manage a lot more
> projects with SVN as you have here with GIT,
If by here you mean git.stuge.se note that I'm just an open source
consultant with some good hosting resources for my own stuff, which I
also make available for a few projects. :) I certainly do not pretend
to be a git superhost, and I am also just learning about git. But, I
feel generally positive about really learning how git works, a little
at a time, to see if it might suit me in a deeper sense, I don't just
want the minimal command set to work with code.
> and we have revision numbers which are currently 6 digits longs,
> and easy to type;
With 6 hex digits I think you're still good even in the Linux kernel.
For me, hex is not significantly worse than dec.
> if I have commited and someone points out at *any time* that my
> commit message is wrong, or has a typo, or something missing, then
> I can just edit it at any time.
SVN revision numbers relate to something else than the repository
contents and history, which I think is unfortunate.
> So my personal preference stays with SVN.
That's fine of course! I use svn too, but the more I learn git, the
less I think cvs/svn is fantastic.
Received on 2009-09-04