Every time the user types git commit -a
,
I want to run it in my own script,
Then run original command git commit..
and have it run as it would have normally.
4 Answers
You could use ".git/hooks" to install a "pre-commit" hook, perhaps: http://git-scm.com/book/en/Customizing-Git-Git-Hooks
This is normally how you would do this. Of course, it would help if you explained exactly WHAT you want the "overload" to do.
If you want your "hook" is not limited to only git
but you need to make it work with any executable, you can use alias
alias git='myhackyscript.sh'
then myhackyscript.sh
may looks like
#!/bin/bash
# save params
params=("$@")
# do what i want to do
do_something
# launch git
git "${params[@]}"
myhackyscript.sh
must be stored in a $PATH
folder like /usr/bin/
-
-
Look at the last line. It will call git with his parameters taken from the shell command Jan 28, 2013 at 11:04
-
-
-
Aliases don't expand into a non-interactive shell. Try yourself Jan 28, 2013 at 12:20
You can define a shell function that invokes a custom script which then passes things on to the original git command:
git() {
case $1 in
commit)
echo "WUFF"
;;
esac
\git "$@"
}
Putting this function into one of your shell's RC files (e.g. ~/.profile
or /etc/profile
in the case of sh/bash/ksh shells) will make this available after the next login. Of course, you can get much more elaboare than this. Also, you might want to take a look at the git-sh-setup(1)
and git-rev-parse(1)
man-pages, in particular the section about parseopt
.
-
You can
source ~/.profile
to update the current shell with the new function., Jan 28, 2013 at 11:46 -
Sure, and on Mac it's actually enough to just open a new terminal/tab. But the logout/login method is the bullet proof way ;-)– Michael WildJan 28, 2013 at 11:48
-
That's because each new terminal/tab invokes a new shell so all relevant config files such as
~/.bashrc
will be read.source ~/.bashrc
will be bulletproof for updating the current shell with the changes. Jan 28, 2013 at 11:53
If you create a script ls
in a location such as ~/bin
which is located on the path
before /bin/ls
your script will be executed instead.
user@wopr /home/user/bin/: $ cat ls
#!/bin/bash
echo "Security Breached!"
# Run original command
/bin/ls "$@"
Now when listing files the message Security Breached!
is always displayed.
user@wopr /home/user/bin/: $ ls
Security Breached!
ls file.sh file myscript.sh
user@wopr /home/user/bin/: $ which ls
/home/user/bin/ls
You should be aware of the directories on your path
and who can write to those directories.