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 = peter_at_stuge.se
> 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
Received on 2009-09-04