add tests for merge-index / merge-one-file

There were no tests for either, except a brief use in
t1200-tutorial.

These tools are not used much these days, as most people
use the merge-recursive strategy, which handles everything
internally. However, they are used by the "octopus" and
"resolve" strategies, as well as any custom strategies
or merge scripts people have built around them.

For example, together with read-tree, they are the simplest
way to do a basic content-level merge without checking out
the entire repository contents beforehand.

This script adds a basic test of the tools to perform one
content-level merge. It also shows a failure of the tools to
work properly in the face of GIT_WORK_TREE or core.worktree.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

"add -p": work-around an old laziness that does not coalesce hunks

Since 0beee4c (git-add--interactive: remove hunk coalescing, 2008-07-02),
"git add--interactive" behaves lazily and passes overlapping hunks to the
underlying "git apply" without coalescing.  This was partially corrected
by 7a26e65 (its partial revert, 2009-05-16), but overlapping hunks are
still passed when the patch is edited.

Teach "git apply" the --allow-overlap option that disables a safety
feature that avoids misapplication of patches by not applying patches
to overlapping hunks, and pass this option form "add -p" codepath.

Do not even advertise the option, as this is merely a workaround, and the
correct fix is to make "add -p" correctly coalesce adjacent patch hunks.

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

add--interactive.perl: factor out repeated --recount option

Depending on the direction and the target of patch application, we would
need to pass --cached and --reverse to underlying "git apply".  Also we
only pass --check when we are not applying but just checking.

But we always pass --recount since 8cbd431 (git-add--interactive: replace
hunk recounting with apply --recount, 2008-07-02).  Instead of repeating
the same --recount over and over again, move it to a single place that
actually runs the command, namely, "run_git_apply" subroutine.

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

t3701: Editing a split hunk in an "add -p" session

Arnaud Lacombe reported that with the recent change to reject overlapping
hunks fed to "git apply", the edit mode of an "add -p" session that lazily
feeds overlapping hunks without coalescing adjacent ones claim that the
patch does not apply.  Expose the problem to be fixed.

Cf. http://thread.gmane.org/gmane.comp.version-control.git/170685/focus=171000

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

add -p: 'q' should really quit

The "quit" command was added in 9a7a1e0 (git add -p: new "quit" command at
the prompt, 2009-04-10) to allow the user to say that hunks other than
what have already been chosen are undesirable, and exit the interactive
loop immediately.  It forgot that there may be an undecided hunk before
the current one.  In such a case, the interactive loop still goes back to
the beginning.

Clear all the USE bit for undecided hunks and exit the loop.

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

Start 1.7.5.1 maintenance track

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

Merge branch 'mg/x-years-12-months' into maint

* mg/x-years-12-months:
  date: avoid "X years, 12 months" in relative dates

git-send-email: fix missing space in error message

When the command cannot make a connection to the SMTP server the error
message to diagnose the broken configuration is issued.  However, when an
optional smtp-server-port is given and needs to be reported, the message
lacked a space between "hello=<smtp-domain>" and "port=<smtp-server-port>".

Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

blame: tolerate bogus e-mail addresses a bit better

The names and e-mails are sanitized by fmt_ident() when creating commits,
so that they do not contain "<" nor ">", and the "committer" and "author"
lines in the commit object will always be in the form:

    ("author" | "committer") name SP "<" email ">" SP timestamp SP zone

When parsing the email part out, the current code looks for SP starting
from the end of the email part, but the author could obfuscate the address
as "author at example dot com".

We should instead look for SP followed by "<", to match the logic of the
side that formats these lines.

Signed-off-by: Josh Stone <jistone@redhat.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Honor $(prefix) set in config.mak* when defining ETC_GIT* and sysconfdir

Definitions of ETC_GITCONFIG, ETC_GITATTRIBUTES and sysconfdir depend on
value of prefix. As prefix can be changed in config.mak.autogen, all if
blocks with conditions based on prefix should be placed after the file
is included in Makefile.

Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-rebase--interactive.sh: preserve-merges fails on merges created with no-ff

'git rebase' uses 'git merge' to preserve merges (-p).  This preserves
the original merge commit correctly, except when the original merge
commit was created by 'git merge --no-ff'.  In this case, 'git rebase'
will fail to preserve the merge, because during 'git rebase', 'git
merge' will simply fast-forward and skip the commit.  For example:

               B
              / \
             A---M
            /
    ---o---O---P---Q

If we try to rebase M onto P, we lose the merge commit and this happens:

                 A---B
                /
    ---o---O---P---Q

To correct this, we simply do a "no fast-forward" on all merge commits
when rebasing.  Since by the time we decided to do a 'git merge' inside
'git rebase', it means there was a merge originally, so 'git merge'
should always create a merge commit regardless of what the merge
branches look like. This way, when rebase M onto P from the above
example, we get:

                   B
                  / \
                 A---M
                /
    ---o---O---P---Q

Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config.txt,diff-options.txt: porcelain vs. plumbing for color.diff

Reading the diff-family and config man pages one may think that the
color.diff and color.ui settings apply to all diff commands. Make it
clearer that they do not apply to the plumbing variants
diff-{files,index,tree}.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pretty: quote rfc822 specials in email addresses

If somebody has a name that includes an rfc822 special, we
will output it literally in the "From:" header. This is
usually OK, but certain characters (like ".") are supposed
to be enclosed in double-quotes in a mail header.

In practice, whether this matters may depend on your MUA.
Some MUAs will happily take in:

   From: Foo B. Bar <author@example.com>

without quotes, and properly quote the "." when they send
the actual mail.  Others may not, or may screw up harder
things like:

  From: Foo "The Baz" Bar <author@example.com>

For example, mutt will strip the quotes, thinking they are
actual syntactic rfc822 quotes.

So let's quote properly, and then (if necessary) we still
apply rfc2047 encoding on top of that, which should make all
MUAs happy.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: supply '-n' to gzip for identical output

For projects that do not release official archives, gitweb's snapshot
feature would be an excellent alternative, and but without the '-n'
('--no-name') argument, gzip includes a timestamp in output which results
in different files.  Because some systems hash/checksum downloaded files
to ensure integrity of the tarball (e.g FreeBSD), it is desirable to
produce tarballs in a reproducible way for that purpose.

Whilst '--no-name' is more descriptive, the long version of the flag is
not supported on all systems.  In particular, OpenBSD does not appear to
support it.

Supply '-n' to gzip to exclude timestamp from output and produce idential
output every time.

Signed-off-by: Fraser Tweedale <frase@frase.id.au>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn.txt: small typeface improvements

Mark subcommand names as 'subcommand' to make them stand out.

Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn.txt: move option descriptions

The options '---use-log-author' and '--add-author-from' are applicable to other
subcommands except 'fetch' -- therefore move them from the 'fetch' section to
the more general 'options' section.

Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn.txt: fix usage of --add-author-from

The option '--add-author-from' is used in 'commit-diff', 'set-tree', and
'dcommit' subcommands.

Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http: clear POSTFIELDS when initializing a slot

After posting a short request using CURLOPT_POSTFIELDS, if the slot
is reused for posting a large payload, the slot ends up having both
POSTFIELDS (which now points at a random garbage) and READFUNCTION,
in which case the curl library tries to use the stale POSTFIELDS.

Clear it as part of the general slot initialization in get_active_slot().

Heavylifting-by: Shawn Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn Pearce <spearce@spearce.org>

Merge branch 'js/maint-1.6.6-send-pack-stateless-rpc-deadlock-fix' into js/maint-send-pack-stateless-rpc-deadlock-fix

* js/maint-1.6.6-send-pack-stateless-rpc-deadlock-fix:
  send-pack: avoid deadlock when pack-object dies early

Evil merge to adjust the way the use of pthreads in sideband-demultiplexor
was decided (earlier it was "if we are not on Windows", now it is "if we
are not using pthreads").

send-pack: avoid deadlock when pack-object dies early

Send-pack deadlocks in two ways when pack-object dies early (for example,
because there is some repo corruption).

The first deadlock happens with the smart push protocol (--stateless-rpc).
After the initial rev-exchange, the remote is waiting for the pack data
to arrive, and the sideband demuxer at the local side continues trying to
stream data from the remote repository until it gets EOF. Meanwhile,
send-pack (in function pack_objects()) has noticed that pack-objects did
not produce output and died. Back in send_pack(), it now tries to clean
up the sideband demuxer using finish_async(). The demuxer, however, waits
for the remote end to close down, the remote waits for pack data, and
the reason that it still waits is that send-pack forgot to close the
outgoing channel. Add the missing close() in pack_objects().

The second deadlock happens in a similar constellation when the sideband
demuxer runs in a forked process (rather than in a thread). Again, the
remote end waits for pack data to arrive, the sideband demuxer waits for
the remote to shut down, and send-pack (in the regular clean-up) waits for
the demuxer to terminate. This time, the send-pack parent process closes
the writable end of the outgoing channel (in start_command() that spawned
pack-objects) so that after the death of the pack-objects process all
writable ends should have been closed and the remote repo should see EOF.
This does not happen, however, because when the sideband demuxer was forked
earlier, it also inherited a writable end; it remains open and keeps the
remote repo from seeing EOF. To break this deadlock, close the writable end
in the demuxer.

Analyzed-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.5

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

Fix "add -u" that sometimes fails to resolve unmerged paths

"git add -u" updates the index with the updated contents from the working
tree by internally running "diff-files" to grab the set of paths that are
different from the index. Then it updates the index entries for the paths
that are modified in the working tree, and deletes the index entries for
the paths that are deleted in the working tree.

It ignored the output from the diff-files that indicated that a path is
unmerged.  For these paths, it instead relied on the fact that an unmerged
path is followed by the result of comparison between stage #2 (ours) and
the working tree, and used that to update or delete such a path when it is
used to record the resolution of a conflict.

As the result, when a path did not have stage #2 (e.g. "we deleted while
the other side added"), these unmerged stages were left behind, instead of
recording what the user resolved in the working tree.

Since we recently fixed "diff-files" to indicate if the corresponding path
exists on the working tree for an unmerged path, we do not have to rely on
the comparison with stage #2 anymore. We can instead tell the diff-files
not to compare with higher stages, and use the unmerged output to update
the index to reflect the state of the working tree.

The changes to the test vector in t2200 illustrates the nature of the bug
and the fix.  The test expected stage #1 and #3 entries be left behind,
but it was codifying the buggy behaviour.

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

diff-files: show unmerged entries correctly

Earlier, e9c8409 (diff-index --cached --raw: show tree entry on the LHS
for unmerged entries., 2007-01-05) taught the command to show the object
name and the mode from the entry coming from the tree side when comparing
a tree with an unmerged index.

This is a belated companion patch that teaches diff-files to show the mode
from the entry coming from the working tree side, when comparing an
unmerged index and the working tree.

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

diff: remove often unused parameters from diff_unmerge()

e9c8409 (diff-index --cached --raw: show tree entry on the LHS for
unmerged entries., 2007-01-05) added a <mode, object name> pair as
parameters to this function, to store them in the pre-image side of an
unmerged file pair.  Now the function is fixed to return the filepair it
queued, we can make the caller on the special case codepath to do so.

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

diff.c: return filepair from diff_unmerge()

The underlying diff_queue() returns diff_filepair so that the caller can
further add information to it, and the helper function diff_unmerge()
utilizes the feature itself, but does not expose it to its callers, which
was kind of selfish.

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

test: use $_z40 from test-lib

There is no need to duplicate the definition of $_z40 and $_x40 that
test-lib.sh supplies the test scripts.

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

date: avoid "X years, 12 months" in relative dates

When relative dates are more than about a year ago, we start
writing them as "Y years, M months".  At the point where we
calculate Y and M, we have the time delta specified as a
number of days. We calculate these integers as:

  Y = days / 365
  M = (days % 365 + 15) / 30

This rounds days in the latter half of a month up to the
nearest month, so that day 16 is "1 month" (or day 381 is "1
year, 1 month").

We don't round the year at all, though, meaning we can end
up with "1 year, 12 months", which is silly; it should just
be "2 years".

Implement this differently with months of size

  onemonth = 365/12

so that

  totalmonths = (long)( (days + onemonth/2)/onemonth )
  years = totalmonths / 12
  months = totalmonths % 12

In order to do this without floats, we write the first formula as

  totalmonths = (days*12*2 + 365) / (365*2)

Tests and inspiration by Jeff King.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

run-command: handle short writes and EINTR in die_child

If start_command fails after forking and before exec finishes, there
is not much use in noticing an I/O error on top of that.
finish_command will notice that the child exited with nonzero status
anyway.  So as noted in v1.7.0.3~20^2 (run-command.c: fix build
warnings on Ubuntu, 2010-01-30) and v1.7.5-rc0~29^2 (2011-03-16), it
is safe to ignore errors from write in this codepath.

Even so, the result from write contains useful information: it tells
us if the write was cancelled by a signal (EINTR) or was only
partially completed (e.g., when writing to an almost-full pipe).
Let's use write_in_full to loop until the desired number of bytes have
been written (still ignoring errors if that fails).

As a happy side effect, the assignment to a dummy variable to appease
gcc -D_FORTIFY_SOURCE is no longer needed.  xwrite and write_in_full
check the return value from write(2).

Noticed with gcc -Wunused-but-set-variable.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: check error message from run_command

In git versions starting at v1.7.5-rc0~29^2 until v1.7.5-rc3~2 (Revert
"run-command: prettify -D_FORTIFY_SOURCE workaround", 2011-04-18)
fixed it, the run_command facility would write a truncated error
message when the command is present but cannot be executed for some
other reason.  For example, if I add a 'hello' command to git:

$ echo 'echo hello' >git-hello
$ chmod +x git-hello
$ PATH=.:$PATH git hello
hello

and make it non-executable, this is what I normally get:

$ chmod -x git-hello
$ git hello
fatal: cannot exec 'git-hello': Permission denied

But with the problematic versions, we get disturbing output:

$ PATH=.:$PATH git hello
fatal: $

Add some tests to make sure it doesn't happen again.

The hello-script used in these tests uses cat instead of echo because
on Windows the bash spawned by git converts LF to CRLF in text written
by echo while the bash running tests does not, causing the test to
fail if "echo" is used.  Thanks to Hannes for noticing.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.5-rc3

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

Sync with 1.7.4.5

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

Git 1.7.4.5

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

remove noise and inaccuracies from git-svn docs

Signed-off-by: Stefan Sperling <stsp@stsp.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/format-patch: suggest Toggle Word Wrap add-on for Thunderbird

Of the (now) three methods to send unmangled patches using Thunderbird,
this method is listed first because it provides a single-click on-demand
option rather than a permanent change of configuration like the other
two methods.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn.txt: Document --mergeinfo

6abd933 (git-svn: allow the mergeinfo property to be set, 2010-09-24)
introduced the --mergeinfo option. Document it.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Revert "run-command: prettify -D_FORTIFY_SOURCE workaround"

This reverts commit ebec842773932e6f853acac70c80f84209b5f83e, which
somehow mistakenly thought that any non-zero return from write(2) is
an error.

doc: Clarify that "cherry-pick -x" does not use "git notes"

The documentation for "cherry-pick -x" could be misread in the way that a
"git notes" object is attached to the new commit, which is not the case.

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: publicize hints for sending patches with GMail

The hints in SubmittingPatches about stopping GMail from clobbering
patches are widely useful both as examples of "git send-email" and
"git imap-send" usage.

Move the documentation to the appropriate places.

While at it, don't encourage storing passwords in config files.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: publicize KMail hints for sending patches inline

These hints are in git's private SubmittingPatches document but a
wider audience might be interested.  Move them to the "git
format-patch" manpage.

I'm not sure what gotchas these hints are meant to work around.
They might be completely false.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: hints for sending patches inline with Thunderbird

The standard reference for this information is the article
"Plain text e-mail - Thunderbird#Completely_plain_email" at
kb.mozillazine.org, but the hints hidden away in git's
SubmittingPatches file are more complete.  Move them to the
"git format-patch" manual so they can be installed with git and
read by a wide audience.

While at it, make some tweaks:

 - update "Approach #1" so it might work with Thunderbird 3;
 - remove ancient version numbers from the descriptions of both
   approaches so current readers might have more reason to
   complain if they don't work.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: explain how to check for patch corruption

SubmittingPatches has some excellent advice about how to check a patch
for corruption before sending it off.  Move it to the format-patch
manual so it can be installed with git's documentation for use by
people not necessarily interested in the git project's practices.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge v1.7.5-rc2 into jn/format-patch-doc

This is to sync with the recent updates in Documentation/SubmittingPatches
and Documentation/format-patch.txt

Documentation: describe the format of messages with inline patches

Add a DISCUSSION section to the "git format-patch" manual to encourage
people to send patches in a form that can be applied by "git am"
automatically.  There are two such forms:

 1. The default form in which most metadata goes in the mail header
    and the message body starts with the patch description;

 2. The snipsnip form in which a message starts with pertinent
    discussion and ends with a patch after a "scissors" mark.

The example requires QP encoding in the "Subject:" header intended for
the mailer to give the reader a chance to reflect on that, rather than
being startled by it later.  By contrast, in-body "From:" and
"Subject:" lines should be human-readable and not QP encoded.

Inspired-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
Improved-by: Drew Northup <drew.northup@maine.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Restructure documentation for git-merge-base.

Restructure the text of git-merge-base to better explain more clearly
the different modes of operation.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: update to git-merge-base --octopus

Unlike plain merge-base, merge-base --octopus only requires at least one
commit argument; update the synopsis to reflect that.

Add a sentence to the discussion that when --octopus is used, we do expect
'2' (the common ansestor across all) as the result.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  archive: document limitation of tar.umask config setting
  t3306,t5304: avoid clock skew issues
  git.txt: fix list continuation

archive: document limitation of tar.umask config setting

The local value of the config variable tar.umask is not passed to the
other side with --remote.  We may want to change that, but for now just
document this fact.

Reported-by: Jacek Masiulaniec <jacek.masiulaniec@gmail.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3306,t5304: avoid clock skew issues

On systems where the local time and file modification time may be out of
sync (e.g. test directory on NFS) t3306 and t5305 can fail because prune
compares times such as "now" (client time) with file modification times
(server times for remote file systems). I.e., these are spurious test
failures.

Avoid this by setting the relevant modification times to the local time.

Noticed on a system with as little as 2s time skew.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.txt: fix list continuation

Remove a spurious empty line which prevented asciidoc from recognizing a
list continuation mark ('+'), so that it does not get output literally any
more.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.5-rc2

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

Merge branch 'maint'

* maint:

Merge branch 'jc/rev-list-options-fix' into maint

* jc/rev-list-options-fix:
  "log --cherry-pick" documentation regression fix

Merge branch 'js/checkout-untracked-symlink' into maint

* js/checkout-untracked-symlink:
  t2021: mark a test as fixed

mergetool: Teach about submodules

When the index has conflicted submodules, mergetool used to mildly
clobber the module, renaming it to mymodule.BACKUP.nnnn, then failing to
copy it non-recursively.

Recognize submodules and offer a resolution instead:

  Submodule merge conflict for 'Shared':
    {local}: submodule commit ad9f12e3e6205381bf2163a793d1e596a9e211d0
    {remote}: submodule commit f5893fb70ec5646efcd9aa643c5136753ac89253
  Use (l)ocal or (r)emote, or (a)bort?

Selecting a commit will stage it, but not update the submodule (as git
does had there been no conflict). Type changes are also supported,
should the path be a submodule on one side, and a file, symlink,
directory, or deleted on the other.

Signed-off-by: Jonathon Mah <me@JonathonMah.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remove doubled words, e.g., s/to to/to/, and fix related typos

I found that some doubled words had snuck back into projects from which
I'd already removed them, so now there's a "syntax-check" makefile rule in
gnulib to help prevent recurrence.

Running the command below spotted a few in git, too:

  git ls-files | xargs perl -0777 -n \
    -e 'while (/\b(then?|[iao]n|i[fst]|but|f?or|at|and|[dt])\s+\1\b/gims)' \
    -e '{$n=($` =~ tr/\n/\n/ + 1); ($v=$&)=~s/\n/\\n/g;' \
    -e 'print "$ARGV:$n:$v\n"}'

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revert: Hide '-r' option in default usage

The '-r' command-line option is a no-op provided only for backward
compatiblity since abd6970 (cherry-pick: make -r the default, 2006-10-05),
and somehow ended up surviving across reimplementation in C at 9509af6
(Make git-revert & git-cherry-pick a builtin, 2007-03-01) and another
rewrite of the command line parser at f810379 (Make builtin-revert.c use
parse_options, 2007-10-07).  We should have stopped advertising the option
long time ago.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format-patch: document --quiet option

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format-patch: don't pass on the --quiet flag

The --quiet flag is not meant to be passed on to the diff, as the user
always wants the patches to be produced so catch it and pass it to
reopen_stdout which decides whether to print the filename or not.

Noticed by Paul Gortmaker

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

--dirstat: In case of renames, use target filename instead of source filename

This changes --dirstat analysis to count "damage" toward the target filename,
rather than the source filename. For renames within a directory, this won't
matter to the final output, but when moving files between diretories, the
output now lists the target directory rather than the source directory.

Signed-off-by: Johan Herland <johan@herland.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'js/checkout-untracked-symlink'

* js/checkout-untracked-symlink:
  t2021: mark a test as fixed

Merge branch 'nd/init-gitdir'

* nd/init-gitdir:
  t0001: guard a new test with SYMLINKS prerequisite

t2021: mark a test as fixed

The failure was fixed by the previous commit.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0001: guard a new test with SYMLINKS prerequisite

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Teach --dirstat not to completely ignore rearranged lines within a file

Currently, the --dirstat analysis ignores when lines within a file are
rearranged, because the "damage" calculated by show_dirstat() is 0.
However, if the object name has changed, we already know that there is
some damage, and it is unintuitive to claim there is _no_ damage.

Teach show_dirstat() to assign a minimum amount of damage (== 1) to
entries for which the analysis otherwise yields zero damage, to still
represent that these files are changed, instead of saying that there
is no change.

Also, skip --dirstat analysis when the object names are the same (e.g. for
a pure file rename).

Signed-off-by: Johan Herland <johan@herland.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: extract Q_() source strings as ngettext()

The Q_() wrapper added by 0c9ea33 (i18n: add stub Q_() wrapper for
ngettext, 2011-03-09) needs to be noticed by xgettext.

Add an appropriate --keyword option to the Makefile, so that "make pot"
would notice the strings in the plural form marked with the wrapper.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: avoid parenthesized string as array initializer

The syntax

    static const char ignore_error[] = ("something");

is invalid C.  A parenthesized string is not allowed as an array
initializer.

Some compilers, for example GCC and MSVC, allow this syntax as an
extension, but it is not a portable construct.  tcc does not parse it, for
example.

Remove the parenthesis from the definition of the N_() macro to
fix this.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

--dirstat-by-file: Make it faster and more correct

Currently, when using --dirstat-by-file, it first does the full --dirstat
analysis (using diffcore_count_changes()), and then resets 'damage' to 1,
if any damage was found by diffcore_count_changes().

But --dirstat-by-file is not interested in the file damage per se. It only
cares if the file changed at all. In that sense it only cares if the blob
object for a file has changed. We therefore only need to compare the
object names of each file pair in the diff queue and we can skip the
entire --dirstat analysis and simply set 'damage' to 1 for each entry
where the object name has changed.

This makes --dirstat-by-file faster, and also bypasses --dirstat's practice
of ignoring rearranged lines within a file.

The patch also contains an added testcase verifying that --dirstat-by-file
now detects changes that only rearrange lines within a file.

Signed-off-by: Johan Herland <johan@herland.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

--dirstat: Describe non-obvious differences relative to --stat or regular diff

Also add a testcase documenting the current behavior.

Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge git://git.bogomips.org/git-svn

* git://git.bogomips.org/git-svn:
  git-svn: Cache results of running the executable "git config"
  git-svn: Add a svn-remote.<name>.pushurl config key

Merge git://git.kernel.org/pub/scm/gitk/gitk

* git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Update cherry-pick error message parsing
  gitk: Quote tag names in event bindings to avoid problems with % chars
  gitk: Allow user to control how much of the SHA1 ID gets auto-selected
  gitk: spelling fixes in Russian translation
  gitk: Take only numeric version components when computing $git_version

git-svn: Cache results of running the executable "git config"

Running programs is not cheap!

Signed-off-by: James Y Knight <jknight@itasoftware.com>
Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: Add a svn-remote.<name>.pushurl config key

Similar to the 'remote.<name>.pushurl' config key for git remotes,
'pushurl' is designed to be used in cases where 'url' points to an SVN
repository via a read-only transport, to provide an alternate
read/write transport. It is assumed that both keys point to the same
repository.

The 'pushurl' key is distinct from the 'commiturl' key in that
'commiturl' is a full svn path while 'pushurl' (like 'url') is a base
path. 'commiturl' takes precendece over 'pushurl' in cases where
either might be used.

The 'pushurl' is used by git-svn's dcommit and branch commands.

Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu>
Reviewed-by: James Y Knight <jknight@itasoftware.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

gitk: Update cherry-pick error message parsing

Commit 981ff5c37ae20687c98d98c8689d5e89016026d2 changed the error
message from git cherry-pick from
    Automatic cherry-pick failed.  [...advice...]
to
    error: could not apply 7ab78c9... Do something neat.
    [...advice...]

Update gitk’s regex to match this, restoring the ability to launch git
citool to resolve conflicted cherry-picks.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Paul Mackerras <paulus@samba.org>

stash: ensure --no-keep-index and --patch can be used in any order

Don't assume one comes after the other on the command line. Use a
three-state variable to track and check its value accordingly.

Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash: add two more tests for --no-keep-index

One of these passes just fine; the other one exposes a problem where
command line flag order matters for --no-keep-index and --patch
interaction.

Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: replace each tab with 8 spaces for consistency

Note that the majority of git-p4 uses spaces, not tabs, for indentation.
Consistent indentation is a good hygiene for Python scripts, and mixing
tabs and spaces in Python can lead to hard-to-find bugs.

Signed-off-by: Andrew Garber <andrew@andrewgarber.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

upload-pack: start pack-objects before async rev-list

In a pthread-enabled version of upload-pack, there's a race condition
that can cause a deadlock on the fflush(NULL) we call from run-command.

What happens is this:

  1. Upload-pack is informed we are doing a shallow clone.

  2. We call start_async() to spawn a thread that will generate rev-list
     results to feed to pack-objects. It gets a file descriptor to a
     pipe which will eventually hook to pack-objects.

  3. The rev-list thread uses fdopen to create a new output stream
     around the fd we gave it, called pack_pipe.

  4. The thread writes results to pack_pipe. Outside of our control,
     libc is doing locking on the stream. We keep writing until the OS
     pipe buffer is full, and then we block in write(), still holding
     the lock.

  5. The main thread now uses start_command to spawn pack-objects.
     Before forking, it calls fflush(NULL) to flush every stdio output
     buffer. It blocks trying to get the lock on pack_pipe.

And we have a deadlock. The thread will block until somebody starts
reading from the pipe. But nobody will read from the pipe until we
finish flushing to the pipe.

To fix this, we swap the start order: we start the
pack-objects reader first, and then the rev-list writer
after. Thus the problematic fflush(NULL) happens before we
even open the new file descriptor (and even if it didn't,
flushing should no longer block, as the reader at the end of
the pipe is now active).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.7.5-rc1

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

Sync with 1.7.4.4

Git 1.7.4.4

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

Merge branch 'nm/maint-conflicted-submodule-entries' into maint

* nm/maint-conflicted-submodule-entries:
  submodule: process conflicting submodules only once

Merge branch 'mg/rev-list-n-reverse-doc' into maint

* mg/rev-list-n-reverse-doc:
  git-log.txt,rev-list-options.txt: put option blocks in proper order
  git-log.txt,rev-list-options.txt: -n/--max-count is commit limiting

Merge branch 'jk/maint-remote-mirror-safer'

* jk/maint-remote-mirror-safer:
  remote: deprecate --mirror
  remote: separate the concept of push and fetch mirrors
  remote: disallow some nonsensical option combinations

Merge branch 'mg/doc-revisions-txt'

* mg/doc-revisions-txt:
  revisions.txt: language improvements
  revisions.txt: structure with a labelled list
  revisions.txt: consistent use of quotes

stash: drop dirty worktree check on apply

Before we apply a stash, we make sure there are no changes
in the worktree that are not in the index. This check dates
back to the original git-stash.sh, and is presumably
intended to prevent changes in the working tree from being
accidentally lost during the merge.

However, this check has two problems:

  1. It is overly restrictive. If my stash changes only file
     "foo", but "bar" is dirty in the working tree, it will
     prevent us from applying the stash.

  2. It is redundant. We don't touch the working tree at all
     until we actually call merge-recursive. But it has its
     own (much more accurate) checks to avoid losing working
     tree data, and will abort the merge with a nicer
     message telling us which paths were problems.

So we can simply drop the check entirely.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Teach core.bigfilethreashold to pack-objects

The pack-objects command should take notice of the object file and
refrain from attempting to delta large ones, to be consistent with
the fast-import command.

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

stash: fix false positive in the invalid ref test.

Jeff King reported a problem with git stash apply incorrectly
applying an invalid stash reference.

There is an existing test that should have caught this, but
the test itself was broken, resulting in a false positive.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash: fix accidental apply of non-existent stashes

Once upon a time, "git rev-parse ref@{9999999}" did not
generate an error. Therefore when we got an invalid stash
reference in "stash apply", we could end up not noticing
until quite late.  Commit b0f0ecd (detached-stash: work
around git rev-parse failure to detect bad log refs,
2010-08-21) handled this by checking for the "Log for stash
has only %d entries" warning on stderr when we validated the
ref.

A few days later, e6eedc3 (rev-parse: exit with non-zero
status if ref@{n} is not valid., 2010-08-24) fixed the
original issue. That made the extra stderr test superfluous,
but also introduced a new bug. Now the early call to:

  git rev-parse --symbolic "$@"

fails, but we don't notice the exit code. Worse, its empty
output means we think the user didn't provide us a ref, and
we try to apply stash@{0}.

This patch checks the rev-parse exit code and fails early in
the revision parsing process. We can also get rid of the
stderr test; as a bonus, this means that "stash apply" can
now run under GIT_TRACE=1 properly.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revisions.txt: language improvements

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  Documentation: trivial grammar fix in core.worktree description
  gitweb: Fix parsing of negative fractional timezones in JavaScript

Merge branch 'jl/submodule-fetch-on-demand'

* jl/submodule-fetch-on-demand:
  fetch/pull: Describe --recurse-submodule restrictions in the BUGS section
  submodule update: Don't fetch when the submodule commit is already present
  fetch/pull: Don't recurse into a submodule when commits are already present
  Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option
  config: teach the fetch.recurseSubmodules option the 'on-demand' value
  fetch/pull: Add the 'on-demand' value to the --recurse-submodules option
  fetch/pull: recurse into submodules when necessary

Conflicts:
builtin/fetch.c
submodule.c

Merge branch 'jc/rev-list-options-fix'

* jc/rev-list-options-fix:
  "log --cherry-pick" documentation regression fix

Documentation: trivial grammar fix in core.worktree description

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Fix parsing of negative fractional timezones in JavaScript

Extract converting numerical timezone in the form of '(+|-)HHMM' to
timezoneOffset function, and fix parsing of negative fractional
timezones.

This is used to format timestamps in 'blame_incremental' view; this
complements commit 2b1e172 (gitweb: Fix handling of fractional
timezones in parse_date, 2011-03-25).

Now

  gitweb.cgi/git.git/blame_incremental/3fe5489:/contrib/gitview/gitview#l853

and

  gitweb.cgi/git.git/blame/3fe5489:/contrib/gitview/gitview#l853

show the same correct time in author's local timezone in title
(on mouseover) [Aneesh Kumar K.V, 2006-02-24 00:59:42 +0530].

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'nm/maint-conflicted-submodule-entries'

* nm/maint-conflicted-submodule-entries:
  submodule: process conflicting submodules only once

Merge branch 'maint'

* maint:
  Start preparing for 1.7.4.4
  pull: do not clobber untracked files on initial pull
  compat: add missing #include <sys/resource.h>

Conflicts:
RelNotes

Start preparing for 1.7.4.4

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

pull: do not clobber untracked files on initial pull

For a pull into an unborn branch, we do not use "git merge"
at all. Instead, we call read-tree directly. However, we
used the --reset parameter instead of "-m", which turns off
the safety features.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/index-update-if-able' into maint

* jc/index-update-if-able:
  update $GIT_INDEX_FILE when there are racily clean entries
  diff/status: refactor opportunistic index update

Merge branch 'lt/default-abbrev' into maint

* lt/default-abbrev:
  Rename core.abbrevlength back to core.abbrev
  Make the default abbrev length configurable