clean: preserve nested git worktree in subdirectories

remove_dir_recursively() has a check to avoid removing the directory it
was asked to remove without recursing into it and report success when the
directory is the top level of a working tree of a nested git repository,
to protect such a repository from "clean -f" (without double -f). If a
working tree of a nested git repository is in a subdirectory of a toplevel
project, however, this protection did not apply by mistake; we forgot to
pass the REMOVE_DIR_KEEP_NESTED_GIT down to the recursive removal
codepath.

This requires us to also teach the higher level not to remove the
directory it is asked to remove, when the recursed invocation did not
remove the directory it was asked to remove due to a nested git
repository, as it is not an error to leave the parent directories of such
a nested repository.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: remind that the lines are top-to-bottom

Nelson Benitez Leon opened a discussion with a patch with this in the
note:

    Hi, I was using git rebase -i for some time now and never occured to
    me I could reorder the commit lines to affect the order the commits
    are applied, learnt that recently from a git tutorial.

Nelson's patch was to stress the fact that the lines in the insn sheet can
be re-ordered in a much more verbose way.  Let's add a one-liner reminder
and also remind that the lines in the insn sheet is read from top to
bottom, unlike the "git log" output.

Discussion-triggered-by: Nelson Benitez Leon
Signed-off-by: Junio C Hamano <gitster@pobox.com>
drop casts from users EMPTY_TREE_SHA1_BIN

This macro already evaluates to the correct type, as it
casts the string literal to "unsigned char *" itself
(and callers who want the literal can use the _LITERAL
form).

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

The read-cache implementation defines this static function,
but it is a generally useful concept in git. Let's give
the empty blob the same treatment as the empty tree,
providing both hex and binary forms of the sha1.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
teach diffcore-rename to optionally ignore empty content

Our rename detection is a heuristic, matching pairs of
removed and added files with similar or identical content.
It's unlikely to be wrong when there is actual content to
compare, and we already take care not to do inexact rename
detection when there is not enough content to produce good
results.

However, we always do exact rename detection, even when the
blob is tiny or empty. It's easy to get false positives with
an empty blob, simply because it is an obvious content to
use as a boilerplate (e.g., when telling git that an empty
directory is worth tracking via an empty .gitignore).

This patch lets callers specify whether or not they are
interested in using empty files as rename sources and
destinations. The default is "yes", keeping the original
behavior. It works by detecting the empty-blob sha1 for
rename sources and destinations.

One more flexible alternative would be to allow the caller
to specify a minimum size for a blob to be "interesting" for
rename detection. But that would catch small boilerplate
files, not large ones (e.g., if you had the GPL COPYING file
in many directories).

A better alternative would be to allow a "-rename"
gitattribute to allow boilerplate files to be marked as
such. I'll leave the complexity of that solution until such
time as somebody actually wants it. The complaints we've
seen so far revolve around empty files, so let's start with
the simple thing.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive: don't detect renames of empty files

Merge-recursive detects renames so that if one side modifies
"foo" and the other side moves it to "bar", the modification
is applied to "bar". However, our rename detection is based
on content analysis, it can be wrong (i.e., two files were
not intended as a rename, but just happen to have the same
or similar content).

This is quite rare if the files actually contain content,
since two unrelated files are unlikely to have exactly the
same content.  However, empty files present a problem, in
that there is nothing to analyze. An uninteresting
placeholder file with zero bytes may or may not be related
to a placeholder file with another name.

The result is that adding content to an empty file may cause
confusion if the other side of a merge removed it; your
content may end up in another random placeholder file that
was added.

Let's err on the side of caution and not consider empty
files as renames. This will cause a modify/delete conflict
on the merge, which will let the user sort it out
themselves.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
combine-diff: fix loop index underflow

If both la and context are zero at the start of the loop, la wraps around
and we end up reading from memory far away.  Skip the loop in that case
instead.

Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
configure: move definitions of private m4 macros before AC_INIT invocation

This way, no spurious comments nor whitespace will be propagated in the
generated configure script.

This change is a pure code movement (plus addition of a comment line).

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
configure: avoid some code repetitions thanks to m4_{push,pop}def

This change is just cosmetic, and should cause no semantic change, nor
any change in the generated configure script.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
configure: be more idiomatic

Lots of code in Git's configure.ac doesn't follow the typical formatting,
idioms and best practices for Autoconf input files.  Improve the situation.

There are probably many more similar improvements to be done, but trying
to clump all of them in a single change would make it unreviewable, so we
content ourselves with a partial improvement.

This change is just cosmetic, and should cause no semantic change.

The most relevant of the changes introduced by this patch are:

 - Do not add trailing '\' characters for line continuation where they
   are not truly needed.

 - In several (but not all) macro calls, properly quote the arguments.

 - Few cosmetic changes in spacing and comments.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout: suppress tracking message with "-q"

Like the "switched to..." message (which is already
suppressed by "-q"), this message is purely informational.
Let's silence it if the user asked us to be quiet.

This patch is slightly more than a one-liner, because we
have to teach create_branch to propagate the flag all the
way down to install_branch_config.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
teach "git branch" a --quiet option

There's currently no way to suppress the informational
"deleted branch..." or "set up tracking..." messages.  This
patch provides a "-q" option to do so.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: add `status` headers to git_feed() responses.

The git_feed() method was not setting a `Status` header unless it was
responding to an If-Modified-Since request with `304 Not Modified`.
Now, when it is serving successful responses, it sets status to `200
OK`.

Signed-off-by: W Trevor King <wking@drexel.edu>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: refactor If-Modified-Since handling

The current gitweb only generates Last-Modified and handles
If-Modified-Since headers for the git_feed action.  This patch breaks
the Last-Modified and If-Modified-Since handling code out from
git_feed into a new function exit_if_unmodified_since.  This makes the
code easy to reuse for other actions.

Only gitweb actions which can easily calculate a modification time
should use exit_if_unmodified_since, as the goal is to balance local
processing time vs. upload bandwidth.

Signed-off-by: W Trevor King <wking@drexel.edu>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: add If-Modified-Since handling to git_snapshot().

Because snapshots can be large, you can save some bandwidth by
supporting caching via If-Modified-Since.  This patch adds support for
the i-m-s request to git_snapshot() if the request is a commit.
Requests for snapshots of trees, which lack well defined timestamps,
are still handled as they were before.

Signed-off-by: W Trevor King <wking@drexel.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
http-backend: respect existing GIT_COMMITTER_* variables

The http-backend program sets default GIT_COMMITTER_NAME and
GIT_COMMITTER_EMAIL variables based on the REMOTE_USER and
REMOTE_ADDR variables provided by the webserver. However, it
unconditionally overwrites any existing GIT_COMMITTER
variables, which may have been customized by site-specific
code in the webserver (or in a script wrapping http-backend).

Let's leave those variables intact if they already exist,
assuming that any such configuration was intentional. There
is a slight chance of a regression if somebody has set
GIT_COMMITTER_* for the entire webserver, not intending it
to leak through http-backend. We could protect against this
by passing the information in alternate variables.  However,
it seems unlikely that anyone will care about that
regression, and there is value in the simplicity of using
the common variable names that are used elsewhere in git.

While we're tweaking the environment-handling in
http-backend, let's switch it to use argv_array to handle
the list of variables. That makes the memory management much
simpler.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7501: test the right kind of breakage

These tests try to run "git commit" with various "forbidden" combinations
of options and expect the command to fail, but they do so without having
any change added to the index.  We wouldn't be able to catch breakages
that would allow these combinations by mistake with them because the
command will fail with "nothing to commit" anyway.

Make sure we have something added to the index before running the command.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit: do not trigger bogus "has templated message edited" check

When "-t template" and "-F msg" options are both given (or worse yet,
there is "commit.template" configuration but a message is given in some
other way), the documentation says that template is ignored.  However,
the "has the user edited the message?" check still used the contents of
the template file as the basis of the emptyness check.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit: rephrase the error when user did not touch templated log message

When the user exited editor without editing the commit log template given
by "git commit -t <template>", the commit was aborted (correct) with an
error message that said "due to empty commit message" (incorrect).

This was because the original template support was done by piggybacking on
the check to detect an empty log message.  Split the codepaths into two
independent checks to clarify the error.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-commit.txt: clarify -t requires editing message

Make it clear that, when using commit --template, the message *must* be
changed or the commit will be aborted.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Ivan Heffner <iheffner@gmail.com>
Signed-off-by: Adam Monsen <haircut@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>