Re: [PATCH] rollback index if git-commit is interrupted by a signal
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- May 29, 2008, 12:42 UTC
- Message-ID
- <alpine.DEB.1.00.0805291341290.13507@racer.site.net>
- In-Reply-To
- <E1K1eXC-0005xW-Jd@fencepost.gnu.org>
Hi,
On Thu, 29 May 2008, Paolo Bonzini wrote:
Show 47 quoted lines
> If git-commit is interrupted by a signal, the index.lock file may be
> left in the repository. This patch teaches git to break them, and adds
> a test.
>
> This will usually happen if you ^Z the editor, and then either close the
> terminal or kill git. However, the patch is more defensive and sets up
> the signal handlers so that the entire creation of the index is
> protected.
>
> Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
> ---
> builtin-commit.c | 25 ++++++++++++++-----------
> t/t7502-commit.sh | 14 ++++++++++++++
> 2 files changed, 28 insertions(+), 11 deletions(-)
>
> rollback_index_files handles cleanly the case when the lock
> had not been established; git-status tests check for this.
>
> The test is a bit tricky. To find git's PID, I use a separate shell
> so that I can "exec" git: git will then inherit the same PID as the
> shell, which I get with $$. Using a subshell does not work because bash
> optimizes subshells and does not fork a copy of itself -- this however
> means that it will not be able to really honor the "exec" command,
> and git will get a different PID!
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index b294c1f..ef8b1f0 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -111,17 +111,8 @@ static struct option builtin_commit_options[] = {
>
> static void rollback_index_files(void)
> {
> - switch (commit_style) {
> - case COMMIT_AS_IS:
> - break; /* nothing to do */
> - case COMMIT_NORMAL:
> - rollback_lock_file(&index_lock);
> - break;
> - case COMMIT_PARTIAL:
> - rollback_lock_file(&index_lock);
> - rollback_lock_file(&false_lock);
> - break;
> - }
> + rollback_lock_file(&index_lock);
> + rollback_lock_file(&false_lock);
> }Your commit message gives _no_ good reason for this change. As a matter of fact, I imagine that this could be a regression.
Ciao, Dscho