launch_editor: refactor to use start/finish_command

The launch_editor function uses the convenient run_command_*
interface. Let's use the more flexible start_command and
finish_command functions, which will let us manipulate the
parent state while we're waiting for the child to finish.

Signed-off-by: Jeff King <peff@peff.net>
launch_editor: ignore SIGINT while the editor has control

The user's editor likely catches SIGINT (ctrl-C).  but if
the user spawns a command from the editor and uses ctrl-C to
kill that command, the SIGINT will likely also kill git
itself (depending on the editor, this can leave the terminal
in an unusable state).

Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
Signed-off-by: Jeff King <peff@peff.net>
run-command: drop silent_exec_failure arg from wait_or_whine

We do not actually use this parameter; instead we complain
from the child itself (for fork/exec) or from start_command
(if we are using spawn on Windows).

Signed-off-by: Jeff King <peff@peff.net>
run-command: do not warn about child death by SIGINT

SIGINT is not generally an interesting signal to the user,
since it is typically caused by them hitting "^C" or
otherwise telling their terminal to send the signal.

Signed-off-by: Jeff King <peff@peff.net>
launch_editor: propagate SIGINT from editor to git

We block SIGINT while the editor runs so that git is not
killed accidentally by a stray "^C" meant for the editor or
its subprocesses. This works because most editors ignore
SIGINT.

However, some editor wrappers, like emacsclient, expect to
die due to ^C. We detect the signal death in the editor and
properly exit, but not before writing a useless error
message to stderr. Instead, let's notice when the editor was
killed by SIGINT and just raise the signal on ourselves.
This skips the message and looks to our parent like we
received SIGINT ourselves.

The end effect is that if the user's editor ignores SIGINT,
we will, too. And if it does not, then we will behave as if
we did not ignore it. That should make all users happy.

Note that in the off chance that another part of git has
ignored SIGINT while calling launch_editor, we will still
properly detect and propagate the failed return code from
the editor (i.e., the worst case is that we generate the
useless error, not fail to notice the editor's death).

Signed-off-by: Jeff King <peff@peff.net>
remote-hg: add missing config for basic tests

'hg commit' fails otherwise in some versions of mercurial because of
the missing user information. Other versions simply throw a warning and
guess though.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
remote-hg: fix compatibility with older versions of hg

Turns out repo.revs was introduced quite late, and it doesn't do
anything fancy for our refspec; only list all the numbers in that range.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
remote-hg: try the 'tip' if no checkout present

There's no concept of HEAD in mercurial, but let's try our best to do
something sensible.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
remote-hg: avoid bad refs

Turns out fast-export throws bad 'reset' commands because of a behavior
in transport-helper that is not even needed.

Either way, better to ignore them, otherwise the user will get warnings
when we OK them.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
push: return reject reasons via a mask

Pass all rejection reasons back from transport_push().  The logic is
simpler and more flexible with regard to providing useful feedback.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Jeff King <peff@peff.net>
push: add advice for rejected tag reference

Advising the user to fetch and merge only makes sense if the rejected
reference is a branch.  If none of the rejections were for branches,
tell the user they need to force the update(s).

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Jeff King <peff@peff.net>
push: flag updates

If the reference exists on the remote and the the update is not a
delete, then mark as an update.  This is in preparation for handling
tags and branches differently when pushing.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Jeff King <peff@peff.net>
push: flag updates that require force

Add a flag for indicating an update to a reference requires force.
Currently the nonfastforward flag of a ref is used for this when
generating status the status message.  A separate flag insulates the
status logic from the details of set_ref_status_for_push().

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Jeff King <peff@peff.net>
push: update remote tags only with force

References are allowed to update from one commit-ish to another if the
former is a ancestor of the latter.  This behavior is oriented to
branches which are expected to move with commits.  Tag references are
expected to be static in a repository, though, thus an update to a
tag (lightweight and annotated) should be rejected unless the update is
forced.

To enable this functionality, the following checks have been added to
set_ref_status_for_push() for updating refs (i.e, not new or deletion)
to restrict fast-forwarding in pushes:

  1) The old and new references must be commits.  If this fails,
     it is not a valid update for a branch.

  2) The reference name cannot start with "refs/tags/".  This
     catches lightweight tags which (usually) point to commits
     and therefore would not be caught by (1).

If either of these checks fails, then it is flagged (by default) with a
status indicating the update is being rejected due to the reference
already existing in the remote.  This can be overridden by passing
--force to git push.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Jeff King <peff@peff.net>
Update cygwin.c for new mingw-64 win32 api headers

The cygwin project recently switched to a new implementation of the
windows api, now using header files from the mingw-64 project. These
new header files are incompatible with the way cygwin.c included the
old headers: cygwin.c can be compiled using the new or the older (mingw)
headers, but different files must be included in different order for each
to work. The new headers are in use only for the current release series
(based upon the v1.7.x dll version). The previous release series using
the v1.5 dll is kept available but unmaintained for use on older versions
of Windows. So, patch cygwin.c to use the new include ordering only if
the dll version is 1.7 or higher.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
gitweb: escape html in rss title

The title of an RSS feed is generated from many components,
including the filename provided as a query parameter, but we
failed to quote it.  Besides showing the wrong output, this
is a vector for XSS attacks.

Signed-off-by: Jeff King <peff@peff.net>
replace: parse revision argument for -d

'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.

Make it parse the argument to 'replace -d' in the same way.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Jeff King <peff@peff.net>
ident: make user_ident_explicitly_given private

There are no users of this global variable, as queriers
go through the user_ident_sufficiently_given accessor.
Let's make it private, which will enable further
refactoring.

Signed-off-by: Jeff King <peff@peff.net>
ident: keep separate "explicit" flags for author and committer

We keep track of whether the user ident was given to us
explicitly, or if we guessed at it from system parameters
like username and hostname. However, we kept only a single
variable. This covers the common cases (because the author
and committer will usually come from the same explicit
source), but can miss two cases:

  1. GIT_COMMITTER_* is set explicitly, but we fallback for
     GIT_AUTHOR. We claim the ident is explicit, even though
     the author is not.

  2. GIT_AUTHOR_* is set and we ask for author ident, but
     not committer ident. We will claim the ident is
     implicit, even though it is explicit.

This patch uses two variables instead of one, updates both
when we set the "fallback" values, and updates them
individually when we read from the environment.

Rather than keep user_ident_sufficiently_given as a
compatibility wrapper, we update the only two callers to
check the committer_ident, which matches their intent and
what was happening already.

Signed-off-by: Jeff King <peff@peff.net>
var: accept multiple variables on the command line

Git-var currently only accepts a single value to print. This
is inefficient if the caller is interested in finding
multiple values, as they must invoke git-var multiple times.

This patch lets callers specify multiple variables, and
prints one per line.

Signed-off-by: Jeff King <peff@peff.net>