demonstrate git-commit --dry-run exit code behaviour

In particular, show that --short and --porcelain, while implying
--dry-run, do not return the same exit code as --dry-run. This is due to
the wt_status.commitable flag being set only when a long status is
requested.

No fix is provided here; with [1], it should be trivial to fix though -
just a matter of calling wt_status_mark_commitable().

[1] http://article.gmane.org/gmane.comp.version-control.git/242489

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
request-pull: more strictly match local/remote branches

The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.

That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).

To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.

This means that git request-pull will never rewrite the ref-name you gave
it.  If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.

If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).

The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
request-pull: allow "local:remote" to specify names on both ends

This allows a user to say that a local branch has a different name on
the remote server, using the same syntax that "git push" uses to create
that situation.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
request-pull: pick up tag message as before

The previous two steps were meant to stop updating the explicit
refname the user gave to the command to a different ref that points
at it.  Most notably, we no longer substitute a branch name the user
used with a name of the tag that points at the commit at the tip of
the branch (it still can be done with "local-branch:remote-tag").

However, they also lost the code that included the message in a
tag when the user _did_ ask the tag to be pulled.  Resurrect it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
request-pull: test updates

This illustrates behaviour changes that result from the recent
change by Linus.  Most show good changes, but there may be some
usability regressions:

 - The command continues to fail when the user forgot to push out
   before running the command, but the wording of the message has
   been slightly changed.

 - The command no longer guesses when asked to request the commit at
   the HEAD be pulled after pushing it to a branch 'for-upstream',
   even when that branch points at the correct commit.  The user
   must ask the command with the new "master:for-upstream" syntax.

The new behaviour needs to be documented in any case, but we need to
agree what the new behaviour should be before doing so first.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
request-pull: resurrect "pretty refname" feature

When asking to fetch/pull a branch whose name is B or a tag whose
name is T, we used to show the command to run as:

	git pull $URL B
        git pull $URL tags/T

even when B and T were spelled in a more qualified way in order to
disambiguate, e.g. heads/B or refs/tags/T, but the recent update
lost this feature.  Resurrect it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
stash pop: mention we did not drop the stash upon failing to apply

Signed-off-by: Junio C Hamano <gitster@pobox.com>
shallow: use stat_validity to check for up-to-date file

When we are about to write the shallow file, we check that
it has not changed since we last read it. Instead of
hand-rolling this, we can use stat_validity. This is built
around the index stat-check, so it is more robust than just
checking the mtime, as we do now (it uses the same check as
we do for index files).

The new code also handles the case of a shallow file
appearing unexpectedly. With the current code, two
simultaneous processes making us shallow (e.g., two "git
fetch --depth=1" running at the same time in a non-shallow
repository) can race to overwrite each other.

As a bonus, we also remove a race in determining the stat
information of what we read (we stat and then open, leaving
a race window; instead we should open and then fstat the
descriptor).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
shallow: automatically clean up shallow tempfiles

We sometimes write tempfiles of the form "shallow_XXXXXX"
during fetch/push operations with shallow repositories.
Under normal circumstances, we clean up the result when we
are done. However, we do no take steps to clean up after
ourselves when we exit due to die() or signal death.

This patch teaches the tempfile creation code to register
handlers to clean up after ourselves. To handle this, we
change the ownership semantics of the filename returned by
setup_temporary_shallow. It now keeps a copy of the filename
itself, and returns only a const pointer to it.

We can also do away with explicit tempfile removal in the
callers. They all exit not long after finishing with the
file, so they can rely on the auto-cleanup, simplifying the
code.

Note that we keep things simple and maintain only a single
filename to be cleaned. This is sufficient for the current
caller, but we future-proof it with a die("BUG").

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tag: support --sort=<spec>

--sort=version:refname (or --sort=v:refname for short) sorts tags as
if they are versions. --sort=-refname reverses the order (with or
without ":version").

versioncmp() is copied from string/strverscmp.c in glibc commit
ee9247c38a8def24a59eb5cfb7196a98bef8cfdc, reformatted to Git coding
style. The implementation is under LGPL-2.1 and according to [1] I can
relicense it to GPLv2.

[1] http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
skip_prefix(): scan prefix only once

Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack: send shallow info over stdin to pack-objects

Before cdab485 (upload-pack: delegate rev walking in shallow fetch to
pack-objects - 2013-08-16) upload-pack does not write to the source
repository. cdab485 starts to write $GIT_DIR/shallow_XXXXXX if it's a
shallow fetch, so the source repo must be writable.

git:// servers do not need write access to repos and usually don't
have it, which means cdab485 breaks shallow clone over git://

Instead of using a temporary file as the media for shallow points, we
can send them over stdin to pack-objects as well. Prepend shallow
SHA-1 with --shallow so pack-objects knows what is what.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status: make full label string to be subject to l10n

Earlier in 3651e45c (wt-status: take the alignment burden off
translators, 2013-11-05), we assumed that it is OK to make the
string before the colon in a label string we give as the section
header of various kinds of changes (e.g. "new file:") translatable.

This assumption apparently does not hold for some languages,
e.g. ones that want to have spaces around the colon.

Also introduce a static label_width to avoid having to run
strlen(padding) over and over.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status: extract the code to compute width for labels

Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status: i18n of section labels

The original code assumes that:

 (1) the number of bytes written is the width of a string, so they
     can line up;

 (2) the "how" string is always <= 19 bytes.

Neither of which we should assume.

Using the same approach as the earlier 3651e45c (wt-status: take the
alignment burden off translators, 2013-11-05), compute the necessary
column width to hold the longest label and use that for alignment.

cf. http://bugs.debian.org/725777

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Helped-by: Sandy Carter
Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status: lift the artificual "at least 20 columns" floor

When we show unmerged paths, we had an artificial 20 columns floor
for the width of labels (e.g. "both deleted:") shown next to the
pathnames.  Depending on the locale, this may result in a label that
is too wide when all the label strings are way shorter than 20
columns, or no-op when a label string is longer than 20 columns.

Just drop the artificial floor.  The screen real estate is better
utilized this way when all the strings are shorter.

Adjust the tests to this change.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
sh-i18n--envsubst: retire unused string_list_member()

This static function has no callers, nor has it had any since its
introduction in ba67aaf2d05d (git-sh-i18n--envsubst: our own envsubst(1)
for eval_gettext(), 2011-05-14). Remove it.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
request-pull: documentation updates

The original description talked only about what it does.  Instead,
start it with the purpose of the command, i.e. what it is used for,
and then mention what it does to achieve that goal.

Clarify what <start>, <url> and <end> means in the context of the
overall purpose of the command.

Describe the extended syntax of <end> parameter that is used when
the local branch name is different from the branch name at the
repository the changes are published.

Helped-by: Eric Sunshine
Signed-off-by: Junio C Hamano <gitster@pobox.com>
shallow: verify shallow file after taking lock

Before writing the shallow file, we stat() the existing file
to make sure it has not been updated since our operation
began. However, we do not do so under a lock, so there is a
possible race:

  1. Process A takes the lock.

  2. Process B calls check_shallow_file_for_update and finds
     no update.

  3. Process A commits the lockfile.

  4. Process B takes the lock, then overwrite's process A's
     changes.

We can fix this by doing our check while we hold the lock.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'tc/commit-dry-run-exit-status-tests'

* tc/commit-dry-run-exit-status-tests:
  demonstrate git-commit --dry-run exit code behaviour