These were broken by b5373e9. The problem is that the code
marks the month and year with "-1" for "we don't know it
yet", but the month and year code paths were not adjusted to
fill in the current time before doing their calculations
(whereas other units follow a different code path and are
fine).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Until now, there was no coverage of relative date printing
or approxidate parsing routines (mainly because we had no
way of faking the "now" time for relative date calculations,
which made consistent testing impossible).

This new script tries to exercise the basic features of
show_date and approxidate. Most of the tests are just "this
obvious thing works" to prevent future regressions, with a
few exceptions:

  - We confirm the fix in 607a9e8a that relative year/month
    dates in the latter half of a year round correctly.

  - We confirm that the improvements in b5373e9 and 1bddb25
    work.

  - A few tests are marked to expect failure, which are
    regressions recently introduced by the two commits
    above.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The test-date program goes back to the early days of git,
where it was presumably used to do manual sanity checks on
changes to the date code. However, it is not actually used
by the test suite to do any sort of automatic of systematic
tests.

This patch refactors the interface to the program to try to
make it more suitable for use by the test suite. There
should be no fallouts to changing the interface since it is
not actually installed and is not internally called by any
other programs.

The changes are:

  - add a "mode" parameter so the caller can specify which
    operation to test

  - add a mode to test relative date output from show_date

  - allow faking a fixed time via the TEST_DATE_NOW
    environment variable, which allows consistent automated
    testing

  - drop the use of ctime for showing dates in favor of our
    internal iso8601 printing routines. The ctime output is
    somewhat redundant (because of the day-of-week) which
    makes writing test cases more annoying.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The main purpose is to allow predictable testing of the code.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The previous patch to improve approxidate got us to the point that a lot
of the remaining annoyances were due to the 'strict' date handling running
first, and deciding that it got a good enough date that the approximate
date routines were never even invoked.

For example, using a date string like

	6AM, June 7, 2009

the strict date logic would be perfectly happy with the "June 7, 2009"
part, and ignore the 6AM part that it didn't understand - resulting in the
information getting dropped on the floor:

	6AM, June 7, 2009 -> Sat Jun 6 00:00:00 2009

and the date being calculated as if it was midnight, and the '6AM' having
confused the date routines into thinking about '6 June' rather than 'June
7' at 6AM (ie notice how the _day_ was wrong due to this, not just the
time).

So this makes the strict date routines a bit stricter, and requires that
not just the date, but also the time, has actually been parsed. With that
fix, and trivial extension of the approxidate routines, git now properly
parses the date as

	6AM, June 7, 2009 -> Sun Jun  7 06:00:00 2009

without dropping the fuzzy time ("6AM" or "noon" or any of the other
non-strict time formats) on the floor.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is not a new failure mode - approxidate has always been kind of
random in the input it accepts, but some of the randomness is more
irritating than others.

For example:

	Jun 6, 5AM -> Mon Jun 22 05:00:00 2009
	5AM Jun 6 -> Sat Jun  6 05:00:00 2009

Whaa? The reason for the above is that approxidate squirrells away the '6'
from "Jun 6" to see if it's going to be a relative number, and then
forgets about it when it sees a new number (the '5' in '5AM'). So the odd
"June 22" date is because today is July 22nd, and if it doesn't have
another day of the month, it will just pick todays mday - having ignored
the '6' entirely due to getting all excited about seeing a new number (5).

There are other oddnesses. This does not fix them all, but I think it
makes for fewer _really_ perplexing cases. At least now we have

	Jun 6, 5AM -> Sat Jun  6 05:00:00 2009
	5AM, Jun 6 -> Sat Jun  6 05:00:00 2009

which makes me happier. I can still point to cases that don't work as
well, but those are separate issues.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* bc/maint-am-email:
  git-am: print fair error message when format detection fails
  am: allow individual e-mail files as input

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* cc/replace:
  t6050: check pushing something based on a replaced commit
  Documentation: add documentation for "git replace"
  Add git-replace to .gitignore
  builtin-replace: use "usage_msg_opt" to give better error messages
  parse-options: add new function "usage_msg_opt"
  builtin-replace: teach "git replace" to actually replace
  Add new "git replace" command
  environment: add global variable to disable replacement
  mktag: call "check_sha1_signature" with the replacement sha1
  replace_object: add a test case
  object: call "check_sha1_signature" with the replacement sha1
  sha1_file: add a "read_sha1_file_repl" function
  replace_object: add mechanism to replace objects found in "refs/replace/"
  refs: add a "for_each_replace_ref" function

* gb/apply-ignore-whitespace:
  git apply: option to ignore whitespace differences

* bc/mailsplit-cr-at-eol:
  Allow mailsplit (and hence git-am) to handle mails with CRLF line-endings
  builtin-mailsplit.c: remove read_line_with_nul() since it is no longer used
  builtin-mailinfo,builtin-mailsplit: use strbufs
  strbuf: add new function strbuf_getwholeline()

* jc/maint-merge-recursive-fix:
  merge-recursive: don't segfault while handling rename clashes

* zf/maint-gitweb-acname:
  gitweb: parse_commit_text encoding fix

* np/maint-limit-delta-cache:
  don't let the delta cache grow unbounded in 'git repack'

* jk/maint-show-tag:
  show: add space between multiple items
  show: suppress extra newline when showing annotated tag

* sb/maint-pull-rebase:
  pull: support rebased upstream + fetch + pull --rebase
  t5520-pull: Test for rebased upstream + fetch + pull --rebase

We skip t7407 because a patch series is cooking that uses is.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This 'ifndef' macro is entered only when __sun__ is not defined.  This test
will never fail since it is located inside of the 'else' branch of an 'if'
macro which tests whether __sun__ is defined.  It has had no effect since
the merge at 436f66b7.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* rc/maint-http-fix:
  http.c: don't assume that urls don't end with slash

* tr/maint-1.6.3-add-p-modeonly-fix:
  add -p: do not attempt to coalesce mode changes
  git add -p: demonstrate failure when staging both mode and hunk

Use a new color for commits that don't have any previously printed
children.  The following command demonstrates the changes:

  git log --graph --pretty=tformat:'%h %s%n' -7 481c7a6d 18b07930

Now the two independent lines of development are displayed with
different colors, instead of both using the same color.
Signed-off-by: NAdam Simpkins <simpkins@facebook.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If SVN_SSH is defined, it will be used. Else value in
GIT_SSH is copied to SVN_SSH & then, only on Windows,
the \s are escaped.

On Windows, the shell-variables must be set as follows
    GIT_SSH="C:\Program Files\PuTTY\plink.exe"
    SVN_SSH="C:\\Program Files\\PuTTY\\plink.exe"

See http://code.google.com/p/msysgit/issues/detail?id=305

[ew: fixed indentation to use tabs]
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NKarthik Rajagopalan <karthikr@fastmail.fm>

And then unescape them when writing to $GIT_CONFIG.

SVN has different rules for repository URLs (usually the root)
and for paths within that repository (below the HTTP layer).
Thus, for the request URI path at the HTTP level, the URI needs
to be encoded.  However, in the body of the HTTP request (the
with underlying SVN XML protocol), those paths should not be
URI-encoded[1].  For non-HTTP(S) requests, SVN appears to be
more flexible and will except weird characters in the URL as
well as URI-encoded ones.

Since users are used to using URLs being entirely URI-encoded,
git svn will now attempt to unescape the path portion of URLs
while leaving the actual repository URL untouched.

This change will be reflected in newly-created $GIT_CONFIG files
only.  This allows users to switch between svn(+ssh)://, file://
and http(s):// urls without changing the fetch/branches/tags
config keys.  This won't affect existing imports at all (since
things didn't work before this commit anyways), and will allow
users to force escaping into repository paths that look like
they're escaped (but are not).

Thanks to Mike Smullin for the original bug report and Björn
Steinbrink for summarizing it into testable cases for me.

[1] Except when committing copies/renames, see
    commit 29633bb9Signed-off-by: NEric Wong <normalperson@yhbt.net>

The note about interoperating in different timezones and such is about
localtime argument, not parent.
Signed-off-by: NTuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

* maint:
  filter-branch: make the usage string fit on 80 chars terminals.
  filter-branch: add an example how to add ACKs to a range of commits
  docs: describe impact of repack on "clone -s"

Make append_remote_object_url() (and by implication,
get_remote_object_url) use end_url_with_slash() to ensure that the url
ends with a slash.

Previously, they assumed that the url did not end with a slash and
as a result appended a slash, sometimes errorneously.

This fixes an issue introduced in 5424bc55 ("http*: add helper methods
for fetching objects (loose)"), where the append_remote_object_url()
implementation in http-push.c, which assumed that urls end with a
slash, was replaced by another one in http.c, which assumed urls did
not end with a slash.

The above issue was raised by Thomas Schlichter:

  http://marc.info/?l=git&m=125043105231327Signed-off-by: NTay Ray Chuan <rctay89@gmail.com>
Tested-by: NThomas Schlichter <thomas.schlichter@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It used to be a single, huge line, badly wrapped by xterm.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When you have to add certain lines like ACKs (or for that matter,
Signed-off-by:s) to a range of commits starting with HEAD, you might
be tempted to use 'git rebase -i -10', but that is a waste of your
time.

It is better to use 'git filter-branch' with an appropriate message
filter, and this commit adds an example how to do so to
filter-branch's man page.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The effects of repacking on a repository with alternates are a bit
subtle. The two main things users will want are:

  1. Not to waste disk space by accidentally copying objects which could
     be shared.

  2. Copying all objects explicitly to break the dependency on the source
     repo.

This patch describes both under the "clone -s" documentation. It makes
sense to put it there rather than in git-repack.txt for both cases.

For (1), we are warning the user who is using "clone -s" about what _not_
to do, so we need to get their attention when reading about "clone -s".

For (2), we are telling them how git-repack can be used to accomplish a
task, but until they know that git-repack is the right tool, they have no
reason to look at the repack documentation.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* lt/block-sha1:
  block-sha1/sha1.c: silence compiler complaints by casting void * to char *
  block-sha1: more good unaligned memory access candidates
  block-sha1: support for architectures with memory alignment restrictions
  block-sha1: split the different "hacks" to be individually selected
  block-sha1: move code around
  block-sha1: improve code on large-register-set machines
  block-sha1: improved SHA1 hashing
  block-sha1: perform register rotation using cpp
  block-sha1: get rid of redundant 'lenW' context
  block-sha1: Use '(B&C)+(D&(B^C))' instead of '(B&C)|(D&(B|C))' in round 3
  block-sha1: macroize the rounds a bit further
  block-sha1: re-use the temporary array as we calculate the SHA1
  block-sha1: make the 'ntohl()' part of the first SHA1 loop
  block-sha1: minor fixups
  block-sha1: try to use rol/ror appropriately
  block-sha1: undo ctx->size change
  Add new optimized C 'block-sha1' routines

* bc/maint-am-email:
  git-am: print fair error message when format detection fails
  am: allow individual e-mail files as input

* js/maint-cover-letter-non-ascii:
  Correctly mark cover letters' encodings if they are not pure ASCII
  Expose the has_non_ascii() function

* jc/maint-clean-nested-dir-safety:
  clean: require double -f options to nuke nested git repository and work tree

* jk/maint-merge-msg-fix:
  merge: indicate remote tracking branches in merge message
  merge: fix incorrect merge message for ambiguous tag/branch
  add tests for merge message headings

* git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Parse arbitrary commit-ish in SHA1 field
  gitk: Fix direction of symmetric difference in optimized mode
  gitk: New option to hide remote refs
  gitk: Do not hard-code "encoding" in attribute lookup functions

In 0392513f (add-interactive: refactor mode hunk handling, 2009-04-16),
we merged the interaction loops for mode changes and hunk staging.
This was fine at the time, because 0beee4c6 (git-add--interactive:
remove hunk coalescing, 2008-07-02) removed hunk coalescing.

However, in 7a26e653 (Revert "git-add--interactive: remove hunk
coalescing", 2009-05-16), we resurrected it.  Since then, the code
would attempt in vain to merge mode changes with diff hunks,
corrupting both in the process.

We add a check to the coalescing loop to ensure it only looks at diff
hunks, thus skipping mode changes.
Noticed-by: NKirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When trying to stage changes to file which has also pending `chmod +x`,
`git add -p` produces lots of 'Use of uninitialized value ...' warnings
and fails to do the job:

    $ echo content >> file
    $ chmod +x file
    $ git add -p
    diff --git a/file b/file
    index e69de29..d95f3ad
    --- a/file
    +++ b/file
    old mode 100644
    new mode 100755
    Stage mode change [y,n,q,a,d,/,j,J,g,?]? y
    @@ -0,0 +1 @@
    +content
    Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y
    Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
    Use of uninitialized value $ofs in numeric le (<=) at .../git-add--interactive line 806.
    Use of uninitialized value $o0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
    Use of uninitialized value $n0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
    Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
    fatal: corrupt patch at line 5
    diff --git a/file b/file
    index e69de29..d95f3ad
    --- a/file
    +++ b/file
    @@ -,0 + @@
    +content
Signed-off-by: NKirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Instead of a cleartext password, the CVS pserver expects a scrambled one
in the authentication request. With this patch it is possible to import
CVS repositories only accessible via pserver and user/password.
Signed-off-by: NDirk Hoerner <dirker@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>