Guenter wrote:
> >> Author: Hacki <hacki_at_linux-nt36.site>
> >> Date: Wed Sep 2 20:03:27 2009 +0200
> >
> > I lack info about who did the commit.
> > These mails only tell the author of the patch that someone
> > committed, but it doesn't tell who did the commit -
I'll see if that can't be added to the emails!
> 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--
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2009-09-04