Hi Peter, first of all: dont get me wrong! I'll try to learn what I need for/with GIT since I see that I cant stop the common trends to move to GIT, and I certainly dont want to start any flamewars! I appreciate your patience with helping me succeed with GIT, really!
Peter Stuge schrieb: > 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. yes, I got this already after your first explain; the point is that we all make mistakes, and it happens sometimes that *others* point you to a bad commit message *after* I have pushed, and in these cases local checking *before* I push do not help. >> 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 Linux, and sometimes Win32 (rarely). > they work slightly differently because of how they integrate with the > system. > > On Linux one easy way to test is to start the OpenSSH ssh-agent and > let it start a terminal: > > ssh-agent xterm > > The new xterm can communicate with the agent, and you can add your > key with: > > ssh-add -c > > (-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. I will definetly give that a try. > I think that's too bad, because I kind of like git. But it is very > common, and frequently cause for flamewars. :) naaa, no 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.) see above - that doesnt help unless I realize self whats wrong. > Or just be even more careful when you originally write messages? see above - I may happen that I am fine with my commit message where others tell me that its wrong, misleading, whatever ... > 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. naaa, please let us not going more complicated than needed :) >> - commit IDs 40 hexchars long which nobody can just type in > > Again, they can be abbreviated, as long as they remain unique. thats good to know, and when I wrote this I was not aware that it can be abbreviated (you posted afterwards). > 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. you got me wrong here - what I meant was that we have easier to handle commit / revision numbers than with GIT at your repo here; I wondered why we need 40hex for only few projects - thats what I was thinking. > With 6 hex digits I think you're still good even in the Linux kernel. > For me, hex is not significantly worse than dec. ok, 6hex is something other than 40, and I think I can live with that. >> 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. I've not said that cvs/svn is fantastic, nor had that in mind!! Depending on how my love to GIT will develop I see me hack a shell script which translates svn commands into git ones :) Anyway, now that I wrote my frustration from soul + found some things are solvable (like first commit, then pull = automerge) I feel a bit better :) thanks again! Gün. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
