How to exit from zsh commit message when accidentally write a semicolon and press enter - version-control

Usually, when one writes a commit message it does it like this:
git commit -m 'this is my message'
But by mistake instead of closing the quotes you press ; and enter so it happens this:
git commit -m 'this is my message;
quote>
How can it be exited from here? Is there a way to remove the last action?

Use ctrl+c.
You will be able to redo your command afterwards by hitting ↑.

Related

zsh: How to always execute a command after current command's execution if it matches a pattern

After I run any hg command e.g. hg sync, hg rebase, etc., I want the command hg status to be run automatically.
I've tried looking into the zsh hooks precmd and preexec, however I wasn't able to wait for current command's execution to get finished.
I guess this can also be achieved by automatically adding "&& hg status" to the command if it matches the pattern.
To restate my requirement - for any command matching a pattern, wait for its completion and then automatically run a fixed command.
Thanks!

TortoiseSVN Command Line Merge in Windows

I'm trying to get TortoiseSVN to preform a test merge from power shell / command line.
The command I'm using in powershell is:
TortoiseProc.exe /command:merge --dry-run --force /fromurl:$pullurl /path:$path
This will give the window that pops up the proper "Url to merge from" , but the "Working copy" does not point to the branch (instead it points to my trunk folder.).
What are the parameters for the /command:merge instruction?
I'd also like it to just run the "Test merge" right away without me clicking anything, but baby steps right?
Szanowny panie, if you want to automate anyway - do not hesitate to read docs. Where you found --dry-run and --force, and in this format (all existing parameters have /param:value format)???
For calling ToertoiseProc inside of WC like this
>TortoiseProc.exe /command:merge /fromurl:http://mayorat.ursinecorner.ru:8088/svn/Hello/branches/branche-francaise/ /path:.
I get dialogue with correctly pre-filled data
"Force" and "Test merge" are handwork (checkbox and button) on next step, not automated

Forgeting/removing a revision from Mercurial repository

This happens to me a lot of times. I make some edition...
$ nano module1.c
...run some tests...
$ make test
OK
...and, since the test passed, I commit it:
$ hg commit -m "Bug #123 corrected"
Then I start another functionality, editing some test:
$ nano test/module2.c
I want to run the tests, and press Control-P (or ↑) to execute make test. Unfortunately, however, I commit the last message again:
$ hg commit -m "Bug #123 corrected"
So, Is there a way remove this last commit from my Mercurial repository without losing the edits I have made in test/module2.c?
See hg help rollback. Read it carefully, it's dangerous.
Warning: if you continue the false efficiency of letting your fingers get ahead of your brain, hg rollback will bite you much harder than hg commit. If you want to run make tests a lot and can't wait .3 seconds for visual data to reach your prefrontal cortex, make yourself an mt alias rather than blindly leaping into your command history.

How to execute commandline application (bat) before mercurial commit?

I would like to execute command line application before each commit (push) to central repository. If application will execute with errors, commit should fail with some message.
I have found some examples of python hooks, but nothing about calling bats or exe.
You just put the exe/batch file as the command for the hook (you probably dont need the bat and exe extensions):
[hooks]
pre-commit.example1 = /path/to/somebatfile.bat
pre-commit.example2 = /path/to/someexefile.exe

Commit hooks not printing any error message if script exists with code 0

My pre-commit is calling a perl script commit_log.pl.The script is doing so many pre-checks.Now I am trying to send out a mail after commit approval.We are not able to set up post-commit hooks due to some permission issues.So I am trying to call the send mail in the pre-commit script itself.
In my commit_log.pl if the exit code is zero ,even printf is not working.
If exit code is 1 everything is working fine
pre-commit:
log=`$SVNLOOK log -t "$TXN" "$REPOS"`
author=`$SVNLOOK author -t "$TXN" "$REPOS"`
CHANGED=`$SVNLOOK changed -t "$TXN" "$REPOS"`
/usr/bin/perl /isource/svnroot/fgw_ins/hooks/user/commit_log.pl "$log" "$author" "$CHANGED" "$0" 1>&2
if [ "$?" -eq "1" ];
then
exit 1
else
exit 0
fi
# if does not match..fail...
exit 1
---------------------------------------------------------------------------------
commit_log.pl
------------------------
}
else
{
print("Commit approved\n");#this printf itself is not working
`python $path/send_mail.py $comment $committed_filepath`;
exit 0;
}
Can't add much more to Avi's answer: STDOUT is swallowed by the hook. You will NEVER see STDOUT. STDERR is only seen by the client if the hook script returns a non-zero exitcode -- which usually means the hook failed, and in a pre-commit hook prevents the commit.
If you need to send mail out after a commit, and you can't use a post-commit hook, I suggest you use a continuous build system like Jenkins. You can have Jenkins watch your repository, and when it sees a new revision, send out email to those involved.
Jenkins is a continuous build system which can do a build after every commit, but there's no reason why you need to do a build (except it is usually a good idea anyway). Jenkins can be setup to do any action post commit, so you could have Jenkins simply email those involved.
Yes, it's a bit of an overkill having an entire system like Jenkins just to send out email. Why not simply write your own script? However, you can download, install, and configure Jenkins in an hour or two. It'll take you longer just to layout what you think needs to be done.
Besides, once you have Jenkins, you'll find plenty of other uses for it.
I'm not sure where standard output from the pre-commit hook is sent to. According to the SVN book, the standard error is sent back to the client, but only if there is an error (i.e. it exited with a non-zero exit code).
I would try writing to a specific location, rather than to standard output (e.g. /tmp/pre-commit.log for testing purposes).
Also, in general, you probably should avoid as much as possible doing work in the pre-commit script that assumes the commit was successful. The commit may still fail after the pre-commit script runs, such as during the commit itself, which is why the post-commit script exists.