Commit Graph

10239 Commits

Author SHA1 Message Date
Junio C Hamano
0eefe108ec Merge branch 'aw/push-force-with-lease-reporting' into maint
"git push --force-with-lease" has been taught to report if the push
needed to force (or fast-forwarded).

* aw/push-force-with-lease-reporting:
  push: fix ref status reporting for --force-with-lease
2016-02-17 10:03:40 -08:00
Junio C Hamano
ab2c107eab Merge branch 'js/xmerge-marker-eol' into maint
The low-level merge machinery has been taught to use CRLF line
termination when inserting conflict markers to merged contents that
are themselves CRLF line-terminated.

* js/xmerge-marker-eol:
  merge-file: ensure that conflict sections match eol style
  merge-file: let conflict markers match end-of-line style of the context
2016-02-17 10:03:39 -08:00
Junio C Hamano
0298675ac4 Merge branch 'sg/t6050-failing-editor-test-fix' into maint
* sg/t6050-failing-editor-test-fix:
  t6050-replace: make failing editor test more robust
2016-02-05 14:54:21 -08:00
Junio C Hamano
e2d7739051 Merge branch 'jk/ref-cache-non-repository-optim' into maint
The underlying machinery used by "ls-files -o" and other commands
have been taught not to create empty submodule ref cache for a
directory that is not a submodule.  This removes a ton of wasted
CPU cycles.

* jk/ref-cache-non-repository-optim:
  resolve_gitlink_ref: ignore non-repository paths
  clean: make is_git_repository a public function
2016-02-05 14:54:17 -08:00
Junio C Hamano
07be1da216 Merge branch 'js/dirname-basename' into maint
dirname() emulation has been added, as Msys2 lacks it.

* js/dirname-basename:
  mingw: avoid linking to the C library's isalpha()
  t0060: loosen overly strict expectations
  t0060: verify that basename() and dirname() work as expected
  compat/basename.c: provide a dirname() compatibility function
  compat/basename: make basename() conform to POSIX
  Refactor skipping DOS drive prefixes
2016-02-05 14:54:17 -08:00
Junio C Hamano
02dab5d399 Merge branch 'nd/diff-with-path-params' into maint
A few options of "git diff" did not work well when the command was
run from a subdirectory.

* nd/diff-with-path-params:
  diff: make -O and --output work in subdirectory
  diff-no-index: do not take a redundant prefix argument
2016-02-05 14:54:15 -08:00
Junio C Hamano
88ec75dba4 Merge branch 'jk/list-tag-2.7-regression' into maint
"git tag" started listing a tag "foo" as "tags/foo" when a branch
named "foo" exists in the same repository; remove this unnecessary
disambiguation, which is a regression introduced in v2.7.0.

* jk/list-tag-2.7-regression:
  tag: do not show ambiguous tag names as "tags/foo"
  t6300: use test_atom for some un-modern tests
2016-02-05 14:54:15 -08:00
Junio C Hamano
913c2c7c7b Merge branch 'jk/sanity' into maint
The description for SANITY prerequisite the test suite uses has
been clarified both in the comment and in the implementation.

* jk/sanity:
  test-lib: clarify and tighten SANITY
2016-02-05 14:54:14 -08:00
Junio C Hamano
16f5e26833 Merge branch 'jk/filter-branch-no-index' into maint
A recent optimization to filter-branch in v2.7.0 introduced a
regression when --prune-empty filter is used, which has been
corrected.

* jk/filter-branch-no-index:
  filter-branch: resolve $commit^{tree} in no-index case
2016-02-05 14:54:13 -08:00
Junio C Hamano
f748e69167 Merge branch 'js/close-packs-before-gc' into maint
Many codepaths that run "gc --auto" before exiting kept packfiles
mapped and left the file descriptors to them open, which was not
friendly to systems that cannot remove files that are open.  They
now close the packs before doing so.

* js/close-packs-before-gc:
  receive-pack: release pack files before garbage-collecting
  merge: release pack files before garbage-collecting
  am: release pack files before garbage-collecting
  fetch: release pack files before garbage-collecting
2016-02-05 14:54:13 -08:00
Junio C Hamano
9496acc144 Merge branch 'nd/exclusion-regression-fix' into maint
The ignore mechanism saw a few regressions around untracked file
listing and sparse checkout selection areas in 2.7.0; the change
that is responsible for the regression has been reverted.

* nd/exclusion-regression-fix:
  Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"
2016-02-05 14:54:11 -08:00
Junio C Hamano
90b99869d4 Merge branch 'dk/reflog-walk-with-non-commit' into maint
"git reflog" incorrectly assumed that all objects that used to be
at the tip of a ref must be commits, which caused it to segfault.

* dk/reflog-walk-with-non-commit:
  reflog-walk: don't segfault on non-commit sha1's in the reflog
2016-02-05 14:54:10 -08:00
Junio C Hamano
25b1166ab2 Merge branch 'ew/send-email-mutt-alias-fix' into maint
"git send-email" was confused by escaped quotes stored in the alias
files saved by "mutt", which has been corrected.

* ew/send-email-mutt-alias-fix:
  git-send-email: do not double-escape quotes from mutt
2016-02-05 14:54:09 -08:00
Junio C Hamano
d6998341d8 Merge branch 'nd/stop-setenv-work-tree' into maint
An earlier change in 2.5.x-era broke users' hooks and aliases by
exporting GIT_WORK_TREE to point at the root of the working tree,
interfering when they tried to use a different working tree without
setting GIT_WORK_TREE environment themselves.

* nd/stop-setenv-work-tree:
  Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"
2016-02-05 14:54:07 -08:00
Andrew Wheeler
b2e93f88cb push: fix ref status reporting for --force-with-lease
The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.

Modify the --force-with-lease ref status logic to leverage
the --force ref status logic when the "lease" conditions
are met.

Also, enhance tests to validate output status reporting.

Signed-off-by: Andrew Wheeler <awheeler@motorola.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01 15:03:50 -08:00
Johannes Schindelin
15980deab9 merge-file: ensure that conflict sections match eol style
In the previous patch, we made sure that the conflict markers themselves
match the end-of-line style of the input files. However, this still left
out the conflicting text itself: if it lacks a trailing newline, we
add one, and should add a carriage return when appropriate, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 10:21:53 -08:00
Johannes Schindelin
86efa21527 merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.

This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.

The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!

Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.

We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.

So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.

Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 10:21:26 -08:00
Jeff King
0571979bd6 tag: do not show ambiguous tag names as "tags/foo"
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11),
git-tag has started showing tags with ambiguous names (i.e.,
when both "heads/foo" and "tags/foo" exists) as "tags/foo"
instead of just "foo". This is both:

  - pointless; the output of "git tag" includes only
    refs/tags, so we know that "foo" means the one in
    "refs/tags".

and

  - ambiguous; in the original output, we know that the line
    "foo" means that "refs/tags/foo" exists. In the new
    output, it is unclear whether we mean "refs/tags/foo" or
    "refs/tags/tags/foo".

The reason this happens is that commit b7cc53e9 switched
git-tag to use ref-filter's "%(refname:short)" output
formatting, which was adapted from for-each-ref. This more
general code does not know that we care only about tags, and
uses shorten_unambiguous_ref to get the short-name. We need
to tell it that we care only about "refs/tags/", and it
should shorten with respect to that value.

In theory, the ref-filter code could figure this out by us
passing FILTER_REFS_TAGS. But there are two complications
there:

  1. The handling of refname:short is deep in formatting
     code that does not even have our ref_filter struct, let
     alone the arguments to the filter_ref struct.

  2. In git v2.7.0, we expose the formatting language to the
     user. If we follow this path, it will mean that
     "%(refname:short)" behaves differently for "tag" versus
     "for-each-ref" (including "for-each-ref refs/tags/"),
     which can lead to confusion.

Instead, let's add a new modifier to the formatting
language, "strip", to remove a specific set of prefix
components. This fixes "git tag", and lets users invoke the
same behavior from their own custom formats (for "tag" or
"for-each-ref") while leaving ":short" with its same
consistent meaning in all places.

We introduce a test in t7004 for "git tag", which fails
without this patch. We also add a similar test in t3203 for
"git branch", which does not actually fail. But since it is
likely that "branch" will eventually use the same formatting
code, the test helps defend against future regressions.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26 13:34:10 -08:00
Jeff King
1d094db936 t6300: use test_atom for some un-modern tests
Because this script has to test so many formatters, we have
the nice "test_atom" helper, but we don't use it
consistently. Let's do so. This is shorter, gets rid of some
tests that have their "expected" setup outside of a
test_expect_success block, and lets us organize the changes
better (e.g., putting "refname:short" near "refname").

We also expand the "%(push)" tests a little to match the
"%(upstream)" ones.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25 12:33:45 -08:00
Jeff King
a2d5156c2b resolve_gitlink_ref: ignore non-repository paths
When we want to look up a submodule ref, we use
get_ref_cache(path) to find or auto-create its ref cache.
But if we feed a path that isn't actually a git repository,
we blindly create the ref cache, and then may die deeper in
the code when we try to access it. This is a problem because
many callers speculatively feed us a path that looks vaguely
like a repository, and expect us to tell them when it is
not.

This patch teaches resolve_gitlink_ref to reject
non-repository paths without creating a ref_cache. This
avoids the die(), and also performs better if you have a
large number of these faux-submodule directories (because
the ref_cache lookup is linear, under the assumption that
there won't be a large number of submodules).

To accomplish this, we also break get_ref_cache into two
pieces: the lookup and auto-creation (the latter is lumped
into create_ref_cache). This lets us first cheaply ask our
cache "is it a submodule we know about?" If so, we can avoid
repeating our filesystem lookup. So lookups of real
submodules are not penalized; they examine the submodule's
.git directory only once.

The test in t3000 demonstrates a case where this improves
correctness (we used to just die). The new perf case in
p7300 shows off the speed improvement in an admittedly
pathological repository:

Test                  HEAD^               HEAD
----------------------------------------------------------------
7300.4: ls-files -o   66.97(66.15+0.87)   0.33(0.08+0.24) -99.5%

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25 11:42:13 -08:00
Duy Nguyen
a97262c62f diff: make -O and --output work in subdirectory
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-21 10:45:13 -08:00
Jeff King
1dc413ebe5 filter-branch: resolve $commit^{tree} in no-index case
Commit 348d4f2 (filter-branch: skip index read/write when
possible, 2015-11-06) taught filter-branch to optimize out
the final "git write-tree" when we know we haven't touched
the tree with any of our filters. It does by simply putting
the literal text "$commit^{tree}" into the "$tree" variable,
avoiding a useless rev-parse call.

However, when we pass this to git_commit_non_empty_tree(),
it gets confused; it resolves "$commit^{tree}" itself, and
compares our string to the 40-hex sha1, which obviously
doesn't match. As a result, "--prune-empty" (or any custom
filter using git_commit_non_empty_tree) will fail to drop
an empty commit (when filter-branch is used without a tree
or index filter).

Let's resolve $tree to the 40-hex ourselves, so that
git_commit_non_empty_tree can work. Unfortunately, this is a
bit slower due to the extra process overhead:

  $ cd t/perf && ./run 348d4f2 HEAD p7000-filter-branch.sh
  [...]
  Test                  348d4f2           HEAD
  --------------------------------------------------------------
  7000.2: noop filter   3.76(0.24+0.26)   4.54(0.28+0.24) +20.7%

We could try to make git_commit_non_empty_tree more clever.
However, the value of $tree here is technically
user-visible. The user can provide arbitrary shell code at
this stage, which could itself have a similar assumption to
what is in git_commit_non_empty_tree. So the conservative
choice to fix this regression is to take the 20% hit and
give the pre-348d4f2 behavior. We still end up much faster
than before the optimization:

  $ cd t/perf && ./run 348d4f2^ HEAD p7000-filter-branch.sh
  [...]
  Test                  348d4f2^          HEAD
  --------------------------------------------------------------
  7000.2: noop filter   9.51(4.32+0.40)   4.51(0.28+0.23) -52.6%

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19 14:20:56 -08:00
Junio C Hamano
719c3da2f1 test-lib: clarify and tighten SANITY
f400e51c (test-lib.sh: set prerequisite SANITY by testing what we
really need, 2015-01-27) improved the way SANITY prerequisite was
determined, but made the resulting code (incorrectly) imply that
SANITY is all about effects of permission bits of the containing
directory has on the files contained in it by the comment it added,
its log message and the actual tests.

State what SANITY is about more clearly in the comment, and test
that a file whose permission bits says should be unreadble truly
cannot be read.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19 14:18:20 -08:00
Johannes Schindelin
0898c96281 fetch: release pack files before garbage-collecting
Before auto-gc'ing, we need to make sure that the pack files are
released in case they need to be repacked and garbage-collected.

This fixes https://github.com/git-for-windows/git/issues/500

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 11:36:27 -08:00
Johannes Schindelin
7d1aaa684d t0060: verify that basename() and dirname() work as expected
Unfortunately, some libgen implementations yield outcomes different
from what Git expects. For example, mingw-w64-crt provides a basename()
function, that shortens `path0/` to `path`!

So let's verify that the basename() and dirname() functions we use
conform to what Git expects.

Derived-from-code-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12 10:41:34 -08:00
Nguyễn Thái Ngọc Duy
8c722360d1 Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"
This reverts commit 57534ee77d. The
feature added in that commit requires that patterns behave the same way
from anywhere. But some patterns can behave differently depending on
current "working" directory. The conditions to catch and avoid these
patterns are too loose. The untracked listing[1] and sparse-checkout
selection[2] can become incorrect as a result.

  [1] http://article.gmane.org/gmane.comp.version-control.git/283520
  [2] http://article.gmane.org/gmane.comp.version-control.git/283532

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-08 11:24:14 -08:00
Dennis Kaarsemaker
aecad374ae reflog-walk: don't segfault on non-commit sha1's in the reflog
git reflog (ab)uses the log machinery to display its list of log
entries. To do so it must fake commit parent information for the log
walker.

For refs in refs/heads this is no problem, as they should only ever
point to commits. Tags and other refs however can point to anything,
thus their reflog may contain non-commit objects.

To avoid segfaulting, we check whether reflog entries are commits before
feeding them to the log walker and skip any non-commits. This means that
git reflog output will be incomplete for such refs, but that's one step
up from segfaulting. A more complete solution would be to decouple git
reflog from the log walker machinery.

Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>
Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-05 13:41:06 -08:00
SZEDER Gábor
36fc7d8a79 t6050-replace: make failing editor test more robust
'git replace --edit' should error out when the invoked editor fails,
but the test checking this behavior would not notice if this weren't
the case.

The test in question, ever since it was added in 85f98fc037
(replace: add tests for --edit, 2014-05-17), has simulated a failing
editor in an unconventional way:

  test_must_fail env GIT_EDITOR='./fakeeditor;false' git replace --edit

I presume the reason for this unconventional editor was the fact that
'git replace --edit' requires the edited object to be different from
the original, but a mere 'false' as editor would leave the object
unchanged and 'git replace --edit' would error out anyway complaining
about the new and the original object files being the same.  Running
'fakeeditor' before 'false' was supposed to ensure that the object
file is modified and thus 'git replace --edit' errors out because of
the failed editor.

However, this editor doesn't actually modify the edited object,
because start_command() turns this editor into:

  /bin/sh -c './fakeeditor;false "$@"' './fakeeditor;false' \
          '.../.git/REPLACE_EDITOBJ'

This means that the test's fakeeditor script doesn't even get the path
of the object to be edited as argument, triggering error messages from
the commands executed inside the script ('sed' and 'mv'), and
ultimately leaving the object file unchanged.

If a patch were to remove the die() from the error path after
launch_editor(), the test would not catch it, because 'git replace'
would continue execution past launch_editor() and would error out a
bit later due to the unchanged edited object.  Though 'git replace'
would error out for the wrong reason, this would satisfy
'test_must_fail' just as well, and the test would succeed leaving the
undesired change unnoticed.

Create a proper failing fake editor script for this test to ensure
that the edited object is in fact modified and 'git replace --edit'
won't error out because the new and original object files are the
same.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-05 09:50:39 -08:00
Junio C Hamano
e3073cf895 Merge branch 'jk/pending-keep-tag-name' into maint
History traversal with "git log --source" that starts with an
annotated tag failed to report the tag as "source", due to an
old regression in the command line parser back in v2.2 days.

* jk/pending-keep-tag-name:
  revision.c: propagate tag names from pending array
2016-01-04 14:03:08 -08:00
Junio C Hamano
e002527582 Merge branch 'jk/symbolic-ref-maint' into maint
"git symbolic-ref" forgot to report a failure with its exit status.

* jk/symbolic-ref-maint:
  t1401: test reflog creation for git-symbolic-ref
  symbolic-ref: propagate error code from create_symref()
2016-01-04 14:02:58 -08:00
Eric Wong
2c510f21cd git-send-email: do not double-escape quotes from mutt
mutt saves aliases with escaped quotes in the form of:

	alias dot \"Dot U. Sir\" <somebody@example.org>

When we pass through our sanitize_address routine,
we end up with double-escaping:

	 To: "\\\"Dot U. Sir\\\" <somebody@example.org>

Remove the escaping in mutt only for now, as I am not sure
if other mailers can do this or if this is better fixed in
sanitize_address.

Cc: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Cc: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04 13:35:40 -08:00
Junio C Hamano
aecb9979df Merge branch 'sh/p4-multi-depot'
"git p4" when interacting with multiple depots at the same time
used to incorrectly drop changes.

* sh/p4-multi-depot:
  git-p4: reduce number of server queries for fetches
  git-p4: support multiple depot paths in p4 submit
  git-p4: failing test case for skipping changes with multiple depots
2015-12-28 13:58:58 -08:00
Junio C Hamano
71957339da Merge branch 'jk/pending-keep-tag-name'
History traversal with "git log --source" that starts with an
annotated tag failed to report the tag as "source", due to an
old regression in the command line parser back in v2.2 days.

* jk/pending-keep-tag-name:
  revision.c: propagate tag names from pending array
2015-12-28 13:58:04 -08:00
Junio C Hamano
e929264e8d Merge branch 'jk/symbolic-ref-maint'
"git symbolic-ref" forgot to report a failure with its exit status.

* jk/symbolic-ref-maint:
  t1401: test reflog creation for git-symbolic-ref
  symbolic-ref: propagate error code from create_symref()
2015-12-28 13:57:24 -08:00
Nguyễn Thái Ngọc Duy
df1e6ea87a Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"
This reverts d95138e6 (setup: set env $GIT_WORK_TREE when work tree
is set, like $GIT_DIR, 2015-06-26).

It has caused three regression reports so far.

  http://article.gmane.org/gmane.comp.version-control.git/281608
  http://article.gmane.org/gmane.comp.version-control.git/281979
  http://article.gmane.org/gmane.comp.version-control.git/282691

All of them are about spawning git subprocesses, where the new
presence of GIT_WORK_TREE either changes command behaviour (git-init
or git-clone), or how repo/worktree is detected (from aliases), with
or without $GIT_DIR.

The original bug will be re-fixed another way.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-22 13:36:47 -08:00
Jeff King
f91b2732b3 t1401: test reflog creation for git-symbolic-ref
The current code writes a reflog entry whenever we update a
symbolic ref, but we never test that this is so. Let's add a
test to make sure upcoming refactoring doesn't cause a
regression.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-21 12:06:31 -08:00
Jeff King
3e4068ed90 symbolic-ref: propagate error code from create_symref()
If create_symref() fails, git-symbolic-ref will still exit
with code 0, and our caller has no idea that the command did
nothing.

This appears to have been broken since the beginning of time
(e.g., it is not a regression where create_symref() stopped
calling die() or something similar).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-21 12:03:03 -08:00
Sam Hocevar
1f90a64891 git-p4: reduce number of server queries for fetches
When fetching changes from a depot using a full client spec, there
is no need to perform as many queries as there are top-level paths
in the client spec.  Instead we query all changes in chronological
order, also getting rid of the need to sort the results and remove
duplicates.

Signed-off-by: Sam Hocevar <sam@hocevar.net>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-21 11:26:55 -08:00
Junio C Hamano
fbe959dde7 Merge branch 'bc/format-patch-null-from-line'
"format-patch" has learned a new option to zero-out the commit
object name on the mbox "From " line.

* bc/format-patch-null-from-line:
  format-patch: check that header line has expected format
  format-patch: add an option to suppress commit hash
  sha1_file.c: introduce a null_oid constant
2015-12-21 10:59:08 -08:00
Junio C Hamano
5d35d72fc3 Merge branch 'mc/push-recurse-submodules-config'
Add new config to avoid typing "--recurse-submodules" on each push.

* mc/push-recurse-submodules-config:
  push: follow the "last one wins" convention for --recurse-submodules
  push: test that --recurse-submodules on command line overrides config
  push: add recurseSubmodules config option
2015-12-21 10:59:05 -08:00
Jeff King
728350b76a revision.c: propagate tag names from pending array
When we unwrap a tag to find its commit for a traversal, we
do not propagate the "name" field of the tag in the pending
array (i.e., the ref name the user gave us in the first
place) to the commit (instead, we use an empty string). This
means that "git log --source" will never show the tag-name
for commits we reach through it.

This was broken in 2073949 (traverse_commit_list: support
pending blobs/trees with paths, 2014-10-15). That commit
tried to be careful and avoid propagating the path
information for a tag (which would be nonsensical) to trees
and blobs. But it should not have cut off the "name" field,
which should carry forward to children.

Note that this does mean that the "name" field will carry
forward to blobs and trees, too. Whereas prior to 2073949,
we always gave them an empty string. This is the right thing
to do, but in practice no callers probably use it (since now
we have an explicit separate "path" field, which was the
point of 2073949).

We add tests here not only for the broken case, but also a
basic sanity test of "log --source" in general, which did
not have any coverage in the test suite.

Reported-by: Raymundo <gypark@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-17 10:47:56 -08:00
Junio C Hamano
f3adf457e0 Merge branch 'fr/rebase-i-continue-preserve-options'
"git rebase -i" started with merge strategy options did not
propagate them upon "git rebase --continue".

* fr/rebase-i-continue-preserve-options:
  rebase -i: remember merge options beyond continue actions
2015-12-16 14:42:52 -08:00
brian m. carlson
06dfc9ebaa format-patch: check that header line has expected format
The format of the "From " header line is very specific to allow
utilities to detect Git-style patches.  Add a test that the patches
created are in the expected format.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-15 10:03:56 -08:00
brian m. carlson
3a30aa1787 format-patch: add an option to suppress commit hash
Oftentimes, patches created by git format-patch will be stored in
version control or compared with diff.  In these cases, two otherwise
identical patches can have different commit hashes, leading to diff
noise.  Teach git format-patch a --zero-commit option that instead
produces an all-zero hash to avoid this diff noise.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-15 10:03:40 -08:00
Junio C Hamano
f97f2e5c64 Merge branch 'ls/p4-keep-empty-commits' into maint
"git p4" used to import Perforce CLs that touch only paths outside
the client spec as empty commits.  It has been corrected to ignore
them instead, with a new configuration git-p4.keepEmptyCommits as a
backward compatibility knob.

* ls/p4-keep-empty-commits:
  git-p4: add option to keep empty commits
2015-12-15 09:34:19 -08:00
Junio C Hamano
a899d500c6 Merge branch 'ls/p4-keep-empty-commits'
"git p4" used to import Perforce CLs that touch only paths outside
the client spec as empty commits.  It has been corrected to ignore
them instead, with a new configuration git-p4.keepEmptyCommits as a
backward compatibility knob.

* ls/p4-keep-empty-commits:
  git-p4: add option to keep empty commits
2015-12-15 08:02:19 -08:00
Luke Diamand
785e70f467 git-p4: failing test case for skipping changes with multiple depots
James Farwell reported that with multiple depots git-p4 would
skip changes.

http://article.gmane.org/gmane.comp.version-control.git/282297

Add a failing test case demonstrating the problem.

Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-14 14:03:45 -08:00
Fabian Ruch
040fd39e67 rebase -i: remember merge options beyond continue actions
If the user explicitly specified a merge strategy or strategy
options, continue to use that strategy/option after
"rebase --continue".  Add a test of the corrected behavior.

If --merge is specified or implied by -s or -X, then "strategy and
"strategy_opts" are set to values from which "strategy_args" can be
derived; otherwise they are set to empty strings.  Either way,
their values are propagated from one step of an interactive rebase
to the next via state files.

"do_merge", on the other hand, is *not* propagated to later steps of
an interactive rebase.  Therefore, making the initialization of
"strategy_args" conditional on "do_merge" being set prevents later
steps of an interactive rebase from setting it correctly.

Luckily, we don't need the "do_merge" guard at all.  If the rebase
was started without --merge, then "strategy" and "strategy_opts"
are both the empty string, which results in "strategy_args" also
being set to the empty string, which is just what we want in that
situation.  So remove the "do_merge" guard and derive
"strategy_args" from "strategy" and "strategy_opts" every time.

Reported-by: Diogo de Campos <campos@esss.com.br>
Signed-off-by: Fabian Ruch <bafain@gmail.com>
Helped-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-11 12:44:44 -08:00
Junio C Hamano
76058817e8 Merge branch 'cb/t3404-shellquote' into maint
* cb/t3404-shellquote:
  t3404: fix quoting of redirect for some versions of bash
2015-12-11 11:14:18 -08:00
Junio C Hamano
4cb5488fa6 Merge branch 'jk/test-lint-forbid-when-finished-in-subshell' into maint
Because "test_when_finished" in our test framework queues the
clean-up tasks to be done in a shell variable, it should not be
used inside a subshell.  Add a mechanism to allow 'bash' to catch
such uses, and fix the ones that were found.

* jk/test-lint-forbid-when-finished-in-subshell:
  test-lib-functions: detect test_when_finished in subshell
  t7800: don't use test_config in a subshell
  test-lib-functions: support "test_config -C <dir> ..."
  t5801: don't use test_when_finished in a subshell
  t7610: don't use test_config in a subshell
2015-12-11 11:14:10 -08:00