Revision aba91192ae39cd1a2f79e7ed91e966df3cfe10b7 authored by Carlos Rica on 09 September 2007, 00:39:29 UTC, committed by Junio C Hamano on 10 September 2007, 04:30:54 UTC
Most of this patch code and message was written by Shawn O. Pearce.
I made some tests to know what the problem was, and then I changed
the code related with the SIGPIPE signal.

If the user has misconfigured `user.signingkey` in their .git/config
or just doesn't have any secret keys on their keyring and they ask
for a signed tag with `git tag -s` we better make sure the resulting
tag was actually signed by gpg.

Prior versions of builtin git-tag allowed this failure to slip
by without error as they were not checking the return value of
the finish_command() so they did not notice when gpg exited with
an error exit status.  They also did not fail if gpg produced an
empty output or if read_in_full received an error from the read
system call while trying to read the pipe back from gpg.

Finally, we did not actually honor any return value from the do_sign
function as it returns ssize_t but was being stored into an unsigned
long.  This caused the compiler to optimize out the die condition,
allowing git-tag to continue along and create the tag object.

However, when gpg gets a wrong username, it exits before any read was done
and then the writing process receives SIGPIPE and program is terminated.
By ignoring this signal, anyway, the function write_or_die gets EPIPE from
write_in_full and exits returning 0 to the system without a message.
Here we better call to write_in_full directly so we can fail
printing a message and return safely to the caller.

With these issues fixed `git-tag -s` will now fail to create the
tag and will report a non-zero exit status to its caller, thereby
allowing automated helper scripts to detect (and recover from)
failure if gpg is not working properly.

Proposed-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 7b02b85
Raw File
merge-strategies.txt
MERGE STRATEGIES
----------------

resolve::
	This can only resolve two heads (i.e. the current branch
	and another branch you pulled from) using 3-way merge
	algorithm.  It tries to carefully detect criss-cross
	merge ambiguities and is considered generally safe and
	fast.

recursive::
	This can only resolve two heads using 3-way merge
	algorithm.  When there are more than one common
	ancestors that can be used for 3-way merge, it creates a
	merged tree of the common ancestors and uses that as
	the reference tree for the 3-way merge.  This has been
	reported to result in fewer merge conflicts without
	causing mis-merges by tests done on actual merge commits
	taken from Linux 2.6 kernel development history.
	Additionally this can detect and handle merges involving
	renames.  This is the default merge strategy when
	pulling or merging one branch.

octopus::
	This resolves more than two-head case, but refuses to do
	complex merge that needs manual resolution.  It is
	primarily meant to be used for bundling topic branch
	heads together.  This is the default merge strategy when
	pulling or merging more than one branches.

ours::
	This resolves any number of heads, but the result of the
	merge is always the current branch head.  It is meant to
	be used to supersede old development history of side
	branches.
back to top