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
Received on 2009-09-04