Hi Peter, Peter Stuge schrieb: > Guenter wrote: >> then now its up for lesson 2.5 to teach idiot apprentice how a >> commit message is afterwards changed > > This can be done, but!! > > The commit id will change because the commit contains the log > message! This means that once a commit has been published it will > semantically "break" the repository if a commit is changed. > > To change the last commit you made into containing the current state > of your working tree, and to enter a new commit message, do: > > git commit --amend > > After that your local clone will have the first commit id replaced > with a new one, and so you will be unable to push this new commit to > the git.stuge.se repo (just like you couldn't push without first > pulling) because your clone history does not match the one in the > repo you want to push to. > > Even if doing this exercise means that the repo will "break" (because > a commit that has been published suddenly disappears) I can help with > this procedure by removing the bad commit completely from the > git.stuge.se repo. This is very bad practise from a git data model > perspective however, because everyone who has pulled the bad commit > must then clone again (pull is no longer possible). I will need a lot > more persuasion to do this if/when there are also some others who > regularly pull from the repo from git.stuge.se, because their > processes would also have to be reset with a fresh clone in order to > work again. > > This is the price of having the log message part of the commit id. > The benefit is traceability - if you get a certain commit id using > git you can be sure that file contents and log messages are as they > were when the commit was created. > > > If there is ever any doubt, I recommend always taking a quick look at > git log before pushing. If you like what you see, go ahead with the > push. If not, you can rework everything locally until you are happy, > without causing extra work in any other repo. > > >> + 2.6 how the heck I make GIT use permanently my GIT username >> instead of my local stuff ... > > git config user.name ... > git config user.email ... > > $ cat ~/.gitconfig > [user] > email = [email protected] > name = Peter Stuge > > >> and 2.7: store ssh password in my user home like cvs/svn do ... > > For managing your private SSH key I recommend using ssh-agent, as was > already mentioned. I made the following small script which can be > sourced from .bashrc so that an agent is always started, and a key > added, when the shell starts, if an agent isn't already running, or > an agent is there (and documented in .ssh/.agent.env) but without a > key loaded. > > --8<-- ~/.ssh/agent.sh > #!/bin/bash > source /etc/profile > source ~/.ssh/.agent.env 2>/dev/null > ssh-add -l >/dev/null 2>&1 > ret=$? > case $ret in > 2) > ssh-agent | grep '^SSH_\(AGENT_PID\|AUTH_SOCK\)=' > ~/.ssh/.agent.env > source ~/.ssh/.agent.env > ssh-add -c > ;; > 1) > ssh-add -c > ;; > *) > ;; > esac > -->8--
thanks for all your hints! Thanks Simon I managed already the username/email stuff. 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. And regarding the SSH stuff, well, I take a look, probably ... Finally, although you all here are *very* helpful, and have explained well the usage of GIT, gave hints and tricks - I couldnt make out one point which makes me start loving GIT - in fact I hate it, sorry to say that. As it currently stands if someone would ask me to participate with a project where I would need to checkout and commit on a daily basis then I would refuse to work with it, and go on nerving the other devels with patches. 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 - commit IDs 40 hexchars long which nobody can just type in Certainly SVN has its quirks too, but at ASF we manage a lot more projects with SVN as you have here with GIT, and we have revision numbers which are currently 6 digits longs, and easy to type; 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. So my personal preference stays with SVN. thanks, Gün. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
