transport-helper.c: do not overwrite forced bit

If the the transport helper says it was a forced update, then it is
a forced update.  It is however possible that an update is forced
without the transport-helper knowing about it, namely because some
higher up code had objections to the update and needed forcing in
order to let it through to the transport helper.  In other words, it
does not necessarily mean the update was *not* forced, when the
helper did not say "forced update".

Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-hg.sh: tests are now expected to pass

Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-bzr: support the new 'force' option

Signed-off-by: Richard Hansen <rhansen@bbn.com>
Acked-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_file: fix delta_stack memory leak in unpack_entry

This delta_stack array can grow to any length depending on the actual
delta chain, but we forget to free it. Normally it does not matter
because we use small_delta_stack[] from stack and small_delta_stack
can hold 64-delta chains, more than standard --depth=50 in pack-objects.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
i18n: mark all progress lines for translation

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
replace_object: use struct members instead of an array

Give the poor humans some names to help them make sense of things.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
find_pack_entry(): document last_found_pack

Add a comment at the declaration of last_found_pack and where it is
used in find_pack_entry().  In the latter, separate the cases (1) to
make a place for the new comment and (2) to turn the success case into
affirmative logic.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_file_name(): declare to return a const string

Change the return value of sha1_file_name() to (const char *).
(Callers have no business mucking about here.)  Change callers
accordingly, deleting a few superfluous temporary variables along the
way.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
stash doc: mention short form -k in save description

Document --keep-index's short form -k in both main synopsis and
the save synopsis in the Options section.

Signed-off-by: John Marshall <jm18@sanger.ac.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
introduce GIT_INDEX_VERSION environment variable

Respect a GIT_INDEX_VERSION environment variable, when a new index is
initialized.  Setting the environment variable will not cause existing
index files to be converted to another format, but will only affect
newly written index files.  This can be used to initialize repositories
with index-v4.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore.h: be explicit about the signedness of is_binary

Bitfields need to specify their signedness explicitly or the compiler is
free to default as it sees fit.  With compilers that default 'unsigned'
(SUNWspro 12 seems to do this) the tri-state nature of is_binary
vanishes and all files are treated as binary.

Signed-off-by: Richard Lowe <richlowe@richlowe.net>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
difftool: support repositories with .git-files

Modern versions of "git submodule" use .git-files to setup the
submodule directory.  When run in a "git submodule"-created
repository "git difftool --dir-diff" dies with the following
error:

	$ git difftool -d HEAD~
	fatal: This operation must be run in a work tree
	diff --raw --no-abbrev -z HEAD~: command returned error: 128

core.worktree is relative to the .git directory but the logic
in find_worktree() does not account for it.

Use `git rev-parse --show-toplevel` to find the worktree so that
the dir-diff feature works inside a submodule.

Reported-by: Gábor Lipták <gabor.liptak@gmail.com>
Helped-by: Jens Lehmann <jens.lehmann@web.de>
Helped-by: John Keeping <john@keeping.me.uk>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t4212: test bogus timestamps with git-log

When t4212 was originally added by 9dbe7c3d (pretty: handle
broken commit headers gracefully, 2013-04-17), it tested our
handling of commits with broken ident lines in which the
timestamps could not be parsed. It does so using a bogus line
like "Name <email>-<> 1234 -0000", because that simulates an
error that was seen in the wild.

Later, 03818a4 (split_ident: parse timestamp from end of
line, 2013-10-14) made our parser smart enough to actually
find the timestamp on such a line, and t4212 was adjusted to
match. While it's nice that we handle this real-world case,
this meant that we were not actually testing the
bogus-timestamp case anymore.

This patch adds a test with a totally incomprehensible
timestamp to make sure we are testing the code path.

Note that the behavior is slightly different between regular log
output and "--format=%ad". In the former case, we produce a
sentinel value and in the latter, we produce an empty
string. While at first this seems unnecessarily
inconsistent, it matches the original behavior given by
9dbe7c3d.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck: report integer overflow in author timestamps

When we check commit objects, we complain if commit->date is
ULONG_MAX, which is an indication that we saw integer
overflow when parsing it. However, we do not do any check at
all for author lines, which also contain a timestamp.

Let's actually check the timestamps on each ident line
with strtoul. This catches both author and committer lines,
and we can get rid of the now-redundant commit->date check.

Note that like the existing check, we compare only against
ULONG_MAX. Now that we are calling strtoul at the site of
the check, we could be slightly more careful and also check
that errno is set to ERANGE. However, this will make further
refactoring in future patches a little harder, and it
doesn't really matter in practice.

For 32-bit systems, one would have to create a commit at the
exact wrong second in 2038. But by the time we get close to
that, all systems will hopefully have moved to 64-bit (and
if they haven't, they have a real problem one second later).

For 64-bit systems, by the time we get close to ULONG_MAX,
all systems will hopefully have been consumed in the fiery
wrath of our expanding Sun.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
date: check date overflow against time_t

When we check whether a timestamp has overflowed, we check
only against ULONG_MAX, meaning that strtoul has overflowed.
However, we also feed these timestamps to system functions
like gmtime, which expect a time_t. On many systems, time_t
is actually smaller than "unsigned long" (e.g., because it
is signed), and we would overflow when using these
functions.  We don't know the actual size or signedness of
time_t, but we can easily check for truncation with a simple
assignment.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log: handle integer overflow in timestamps

If an ident line has a ridiculous date value like (2^64)+1,
we currently just pass ULONG_MAX along to the date code,
which can produce nonsensical dates.

On systems with a signed long time_t (e.g., 64-bit glibc
systems), this actually doesn't end up too bad. The
ULONG_MAX is converted to -1, we apply the timezone field to
that, and the result ends up somewhere between Dec 31, 1969
and Jan 1, 1970.

However, there is still a few good reasons to detect the
overflow explicitly:

  1. On systems where "unsigned long" is smaller than
     time_t, we get a nonsensical date in the future.

  2. Even where it would produce "Dec 31, 1969", it's easier
     to recognize "midnight Jan 1" as a consistent sentinel
     value for "we could not parse this".

  3.  Values which do not overflow strtoul but do overflow a
      signed time_t produce nonsensical values in the past.
      For example, on a 64-bit system with a signed long
      time_t, a timestamp of 18446744073000000000 produces a
      date in 1947.

We also recognize overflow in the timezone field, which
could produce nonsensical results. In this case we show the
parsed date, but in UTC.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log: do not segfault on gmtime errors

Many code paths assume that show_date and show_ident_date
cannot return NULL. For the most part, we handle missing or
corrupt timestamps by showing the epoch time t=0.

However, we might still return NULL if gmtime rejects the
time_t we feed it, resulting in a segfault. Let's catch this
case and just format t=0.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote: handle pushremote config in any order

The remote we push can be defined either by
remote.pushdefault or by branch.*.pushremote for the current
branch. The order in which they appear in the config file
should not matter to precedence (which should be to prefer
the branch-specific config).

The current code parses the config linearly and uses a
single string to store both values, overwriting any
previous value. Thus, config like:

  [branch "master"]
  pushremote = foo
  [remote]
  pushdefault = bar

erroneously ends up pushing to "bar" from the master branch.

We can fix this by storing both values and resolving the
correct value after all config is read.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
am doc: add a pointer to relevant hooks

It is not obvious when looking at a new command what hooks will affect
it.  Add a HOOKS section to the git-am(1) page, imitating
git-commit(1), to make it easier for people to discover e.g. the
applypatch-msg hook that can implement a custom subject-mangling
strategy (e.g., removing a "bug #nnnn:" prefix introduced by a bug
tracker).

Reported-by: Phillip Susi <psusi@ubuntu.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>