OSDN Git Service
Paul Tan [Mon, 18 May 2015 13:32:52 +0000 (21:32 +0800)]
t5520: test no merge candidates cases
a8c9bef (pull: improve advice for unconfigured error case, 2009-10-05)
fully established the current advices given by git-pull for the
different cases where git-fetch will not have anything marked for merge:
1. We fetched from a specific remote, and a refspec was given, but it
ended up not fetching anything. This is usually because the user
provided a wildcard refspec which had no matches on the remote end.
2. We fetched from a non-default remote, but didn't specify a branch to
merge. We can't use the configured one because it applies to the
default remote, and thus the user must specify the branches to merge.
3. We fetched from the branch's or repo's default remote, but:
a. We are not on a branch, so there will never be a configured branch
to merge with.
b. We are on a branch, but there is no configured branch to merge
with.
4. We fetched from the branch's or repo's default remote, but the
configured branch to merge didn't get fetched (either it doesn't
exist, or wasn't part of the configured fetch refspec)
Implement tests for the above 5 cases to ensure that the correct code
paths are triggered for each of these cases.
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Paul Tan [Mon, 18 May 2015 13:32:51 +0000 (21:32 +0800)]
t5520: prevent field splitting in content comparisons
Many tests in t5520 used the following to test the contents of files:
test `cat file` = expected
or
test $(cat file) = expected
These 2 forms, however, will be affected by field splitting and,
depending on the value of $IFS, may be split into multiple arguments,
making the test fail in mysterious ways.
Replace the above 2 forms with:
test "$(cat file)" = expected
as quoting the command substitution will prevent field splitting.
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 26 Mar 2015 04:58:45 +0000 (21:58 -0700)]
merge: deprecate 'git merge <message> HEAD <commit>' syntax
We had this in "git merge" manual for eternity:
'git merge' <msg> HEAD <commit>...
[This] syntax (<msg> `HEAD` <commit>...) is supported for
historical reasons. Do not use it from the command line or in
new scripts. It is the same as `git merge -m <msg> <commit>...`.
With the update to "git merge" to make it understand what is
recorded in FETCH_HEAD directly, including Octopus merge cases, we
now can rewrite the use of this syntax in "git pull" with a simple
"git merge FETCH_HEAD".
Also there are quite a few fallouts in the test scripts, and it
turns out that "git cvsimport" also uses this old syntax to record
a merge.
Judging from this result, I would not be surprised if dropping the
support of the old syntax broke scripts people have written and been
relying on for the past ten years. But at least we can start the
deprecation process by throwing a warning message when the syntax is
used.
With luck, we might be able to drop the support in a few years.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 26 Apr 2015 01:47:21 +0000 (18:47 -0700)]
merge: handle FETCH_HEAD internally
The collect_parents() function now is responsible for
1. parsing the commits given on the command line into a list of
commits to be merged;
2. filtering these parents into independent ones; and
3. optionally calling fmt_merge_msg() via prepare_merge_message()
to prepare an auto-generated merge log message, using fake
contents that FETCH_HEAD would have had if these commits were
fetched from the current repository with "git pull . $args..."
Make "git merge FETCH_HEAD" to be the same as the traditional
git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits
invocation of the command in "git pull", where $commits are the ones
that appear in FETCH_HEAD that are not marked as not-for-merge, by
making it do a bit more, specifically:
- noticing "FETCH_HEAD" is the only "commit" on the command line
and picking the commits that are not marked as not-for-merge as
the list of commits to be merged (substitute for step #1 above);
- letting the resulting list fed to step #2 above;
- doing the step #3 above, using the contents of the FETCH_HEAD
instead of fake contents crafted from the list of commits parsed
in the step #1 above.
Note that this changes the semantics. "git merge FETCH_HEAD" has
always behaved as if the first commit in the FETCH_HEAD file were
directly specified on the command line, creating a two-way merge
whose auto-generated merge log said "merge commit xyz". With this
change, if the previous fetch was to grab multiple branches (e.g.
"git fetch $there topic-a topic-b"), the new world order is to
create an octopus, behaving as if "git pull $there topic-a topic-b"
were run. This is a deliberate change to make that happen, and
can be seen in the changes to t3033 tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 26 Apr 2015 01:39:43 +0000 (18:39 -0700)]
merge: decide if we auto-generate the message early in collect_parents()
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 26 Apr 2015 01:34:22 +0000 (18:34 -0700)]
merge: make collect_parents() auto-generate the merge message
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 26 Apr 2015 01:29:44 +0000 (18:29 -0700)]
merge: extract prepare_merge_message() logic out
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 25 Apr 2015 19:31:57 +0000 (12:31 -0700)]
merge: narrow scope of merge_names
In order to pass the list of parents to fmt_merge_msg(), cmd_merge()
uses this strbuf to create something that look like FETCH_HEAD that
describes commits that are being merged. This is necessary only
when we are creating the merge commit message ourselves, but was
done unconditionally.
Move the variable and the logic to populate it to confine them in a
block that needs them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 25 Apr 2015 19:00:14 +0000 (12:00 -0700)]
merge: split reduce_parents() out of collect_parents()
The latter does two separate things:
- Parse the list of commits on the command line, and formulate the
list of commits to be merged (including the current HEAD);
- Compute the list of parents to be recorded in the resulting merge
commit.
Split the latter into a separate helper function, so that we can
later supply the list commits to be merged from a different source
(namely, FETCH_HEAD).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 25 Apr 2015 17:25:43 +0000 (10:25 -0700)]
merge: clarify collect_parents() logic
Clarify this small function in three ways.
- The function initially collects all commits to be merged into a
commit_list "remoteheads"; the "remotes" pointer always points at
the tail of this list (either the remoteheads variable itself, or
the ->next slot of the element at the end of the list) to help
elongate the list by repeated calls to commit_list_insert().
Because the new element appended by commit_list_insert() will
always have its ->next slot NULLed out, there is no need for us
to assign NULL to *remotes to terminate the list at the end.
- The variable "head_subsumed" always confused me every time I read
this code. What is happening here is that we inspect what the
caller told us to merge (including the current HEAD) and come up
with the list of parents to be recorded for the resulting merge
commit, omitting commits that are ancestor of other commits.
This filtering may remove the current HEAD from the resulting
parent list---and we signal that fact with this variable, so that
we can later record it as the first parent when "--no-ff" is in
effect.
- The "parents" list is created for this function by reduce_heads()
and was not deallocated after its use, even though the loop
control was written in such a way to allow us to do so by taking
the "next" element in a separate variable so that it can be used
in the next-step part of the loop control.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 23 Apr 2015 21:37:13 +0000 (14:37 -0700)]
merge: small leakfix and code simplification
When parsing a merged object name like "foo~20" to formulate a merge
summary "Merge branch foo (early part)", a temporary strbuf is used,
but we forgot to deallocate it when we failed to find the named
branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 23 Apr 2015 20:56:34 +0000 (13:56 -0700)]
merge: do not check argc to determine number of remote heads
To reject merging multiple commits into an unborn branch, we check
argc, thinking that collect_parents() that reads the remaining
command line arguments from <argc, argv> will give us the same
number of commits as its input, i.e. argc.
Because what we really care about is the number of commits, let the
function run and then make sure it returns only one commit instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 23 Apr 2015 20:46:44 +0000 (13:46 -0700)]
merge: clarify "pulling into void" special case
Instead of having it as one of the three if/elseif/.. case arms,
test the condition and handle this special case upfront. This makes
it easier to follow the flow of logic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 23 Apr 2015 20:34:08 +0000 (13:34 -0700)]
t5520: test pulling an octopus into an unborn branch
The code comment for "git merge" in builtin/merge.c, we say
If the merged head is a valid one there is no reason
to forbid "git merge" into a branch yet to be born.
We do the same for "git pull".
and t5520 does have an existing test for that behaviour. However,
there was no test to make sure that 'git pull' to pull multiple
branches into an unborn branch must fail.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 23 Apr 2015 20:29:14 +0000 (13:29 -0700)]
t5520: style fixes
Fix style funnies in early part of this test script that checks "git
pull" into an unborn branch. The primary change is that 'chdir' to
a newly created empty test repository is now protected by being done
in a subshell to make it more robust without having to chdir back to
the original place.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 23 Apr 2015 20:01:44 +0000 (13:01 -0700)]
merge: simplify code flow
One of the first things cmd_merge() does is to see if the "--abort"
option is given and run "reset --merge" and exit. When the control
reaches this point, we know "--abort" was not given.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 29 Apr 2015 20:14:50 +0000 (13:14 -0700)]
merge: test the top-level merge driver
We seem to have tests for specific merge strategy backends
(e.g. recursive), but not much test coverage for the "git merge"
itself. As I am planning to update the semantics of merging
"FETCH_HEAD" in such a way that these two
git pull . topic_a topic_b...
vs.
git fetch . topic_a topic_b...
git merge FETCH_HEAD
are truly equivalent, let me add a few test cases to cover the
tricky ones.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 12 Jan 2015 22:06:12 +0000 (14:06 -0800)]
Git 2.2.2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 12 Jan 2015 22:02:54 +0000 (14:02 -0800)]
Merge branch 'jk/read-packed-refs-without-path-max' into maint
* jk/read-packed-refs-without-path-max:
read_packed_refs: use skip_prefix instead of static array
read_packed_refs: pass strbuf to parse_ref_line
read_packed_refs: use a strbuf for reading lines
Junio C Hamano [Mon, 12 Jan 2015 22:02:19 +0000 (14:02 -0800)]
Merge branch 'mg/add-ignore-errors' into maint
* mg/add-ignore-errors:
add: ignore only ignored files
Junio C Hamano [Mon, 12 Jan 2015 22:02:05 +0000 (14:02 -0800)]
Merge branch 'mh/find-uniq-abbrev' into maint
* mh/find-uniq-abbrev:
sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrev
Junio C Hamano [Mon, 12 Jan 2015 22:01:18 +0000 (14:01 -0800)]
Merge branch 'jk/approxidate-avoid-y-d-m-over-future-dates' into maint
* jk/approxidate-avoid-y-d-m-over-future-dates:
approxidate: allow ISO-like dates far in the future
pass TIME_DATE_NOW to approxidate future-check
Junio C Hamano [Mon, 12 Jan 2015 22:00:16 +0000 (14:00 -0800)]
Merge branch 'rw/apply-does-not-take-ignore-date' into maint
* rw/apply-does-not-take-ignore-date:
git-am.txt: --ignore-date flag is not passed to git-apply
Junio C Hamano [Mon, 12 Jan 2015 20:19:17 +0000 (12:19 -0800)]
Merge branch 'jk/for-each-reflog-ent-reverse' into maint
* jk/for-each-reflog-ent-reverse:
for_each_reflog_ent_reverse: turn leftover check into assertion
for_each_reflog_ent_reverse: fix newlines on block boundaries
Junio C Hamano [Wed, 7 Jan 2015 21:28:10 +0000 (13:28 -0800)]
Merge branch 'maint-2.1' into maint
* maint-2.1:
is_hfs_dotgit: loosen over-eager match of \u{..47}
Junio C Hamano [Wed, 7 Jan 2015 21:27:56 +0000 (13:27 -0800)]
Merge branch 'maint-2.0' into maint-2.1
* maint-2.0:
is_hfs_dotgit: loosen over-eager match of \u{..47}
Junio C Hamano [Wed, 7 Jan 2015 21:27:19 +0000 (13:27 -0800)]
Merge branch 'maint-1.9' into maint-2.0
* maint-1.9:
is_hfs_dotgit: loosen over-eager match of \u{..47}
Junio C Hamano [Wed, 7 Jan 2015 21:27:13 +0000 (13:27 -0800)]
Merge branch 'maint-1.8.5' into maint-1.9
* maint-1.8.5:
is_hfs_dotgit: loosen over-eager match of \u{..47}
Junio C Hamano [Wed, 7 Jan 2015 21:26:35 +0000 (13:26 -0800)]
Merge branch 'jk/dotgit-case-maint-1.8.5' into maint-1.8.5
* jk/dotgit-case-maint-1.8.5:
is_hfs_dotgit: loosen over-eager match of \u{..47}
Jeff King [Tue, 23 Dec 2014 08:45:36 +0000 (03:45 -0500)]
is_hfs_dotgit: loosen over-eager match of \u{..47}
Our is_hfs_dotgit function relies on the hackily-implemented
next_hfs_char to give us the next character that an HFS+
filename comparison would look at. It's hacky because it
doesn't implement the full case-folding table of HFS+; it
gives us just enough to see if the path matches ".git".
At the end of next_hfs_char, we use tolower() to convert our
32-bit code point to lowercase. Our tolower() implementation
only takes an 8-bit char, though; it throws away the upper
24 bits. This means we can't have any false negatives for
is_hfs_dotgit. We only care about matching 7-bit ASCII
characters in ".git", and we will correctly process 'G' or
'g'.
However, we _can_ have false positives. Because we throw
away the upper bits, code point \u{0147} (for example) will
look like 'G' and get downcased to 'g'. It's not known
whether a sequence of code points whose truncation ends up
as ".git" is meaningful in any language, but it does not
hurt to be more accurate here. We can just pass out the full
32-bit code point, and compare it manually to the upper and
lowercase characters we care about.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 22 Dec 2014 20:20:38 +0000 (12:20 -0800)]
Prepare for 2.2.2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 22 Dec 2014 20:18:35 +0000 (12:18 -0800)]
Merge branch 'jk/rebuild-perl-scripts-with-no-perl-seting-change' into maint
The build procedure did not bother fixing perl and python scripts
when NO_PERL and NO_PYTHON build-time configuration changed.
* jk/rebuild-perl-scripts-with-no-perl-seting-change:
Makefile: have python scripts depend on NO_PYTHON setting
Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros
Makefile: have perl scripts depend on NO_PERL setting
Junio C Hamano [Mon, 22 Dec 2014 20:18:25 +0000 (12:18 -0800)]
Merge branch 'jk/no-perl-tests' into maint
Some tests that depend on perl lacked PERL prerequisite to protect
them, breaking build with NO_PERL configuration.
* jk/no-perl-tests:
t960[34]: mark cvsimport tests as requiring perl
t0090: mark add-interactive test with PERL prerequisite
Junio C Hamano [Mon, 22 Dec 2014 20:18:16 +0000 (12:18 -0800)]
Merge branch 'po/everyday-doc' into maint
"Everyday" document had a broken link.
* po/everyday-doc:
Documentation: change "gitlink" typo in git-push
Junio C Hamano [Mon, 22 Dec 2014 20:18:08 +0000 (12:18 -0800)]
Merge branch 'jk/push-simple' into maint
Git 2.0 was supposed to make the "simple" mode for the default of
"git push", but it didn't.
* jk/push-simple:
push: truly use "simple" as default, not "upstream"
Junio C Hamano [Mon, 22 Dec 2014 20:18:00 +0000 (12:18 -0800)]
Merge branch 'mh/config-flip-xbit-back-after-checking' into maint
"git init" (hence "git clone") initialized the per-repository
configuration file .git/config with x-bit by mistake.
* mh/config-flip-xbit-back-after-checking:
create_default_files(): don't set u+x bit on $GIT_DIR/config
Junio C Hamano [Mon, 22 Dec 2014 20:17:34 +0000 (12:17 -0800)]
Merge branch 'jk/gitweb-with-newer-cgi-multi-param' into maint
"gitweb" used to depend on a behaviour that was deprecated by recent
CGI.pm.
* jk/gitweb-with-newer-cgi-multi-param:
gitweb: hack around CGI's list-context param() handling
Junio C Hamano [Mon, 22 Dec 2014 20:17:32 +0000 (12:17 -0800)]
Merge branch 'rs/receive-pack-use-labs' into maint
* rs/receive-pack-use-labs:
use labs() for variables of type long instead of abs()
Junio C Hamano [Mon, 22 Dec 2014 20:17:23 +0000 (12:17 -0800)]
Merge branch 'rs/maint-config-use-labs' into maint
* rs/maint-config-use-labs:
use labs() for variables of type long instead of abs()
Junio C Hamano [Mon, 22 Dec 2014 20:17:13 +0000 (12:17 -0800)]
Merge branch 'js/windows-open-eisdir-error' into maint
open() emulated on Windows platforms did not give EISDIR upon an
attempt to open a directory for writing.
* js/windows-open-eisdir-error:
Windows: correct detection of EISDIR in mingw_open()
Junio C Hamano [Mon, 22 Dec 2014 20:16:58 +0000 (12:16 -0800)]
Merge branch 'jk/colors-fix' into maint
"git config --get-color" did not parse its command line arguments
carefully.
* jk/colors-fix:
t4026: test "normal" color
config: fix parsing of "git config --get-color some.key -1"
docs: describe ANSI 256-color mode
Junio C Hamano [Mon, 22 Dec 2014 20:16:29 +0000 (12:16 -0800)]
Merge branch 'jk/checkout-from-tree' into maint
"git checkout $treeish $path", when $path in the index and the
working tree already matched what is in $treeish at the $path,
still overwrote the $path unnecessarily.
* jk/checkout-from-tree:
checkout $tree: do not throw away unchanged index entries
Alexander Kuleshov [Fri, 19 Dec 2014 08:37:47 +0000 (14:37 +0600)]
clean: typofix
Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 17 Dec 2014 19:49:34 +0000 (11:49 -0800)]
Git 2.2.1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 17 Dec 2014 19:46:57 +0000 (11:46 -0800)]
Sync with v2.1.4
* maint-2.1:
Git 2.1.4
Git 2.0.5
Git 1.9.5
Git 1.8.5.6
fsck: complain about NTFS ".git" aliases in trees
read-cache: optionally disallow NTFS .git variants
path: add is_ntfs_dotgit() helper
fsck: complain about HFS+ ".git" aliases in trees
read-cache: optionally disallow HFS+ .git variants
utf8: add is_hfs_dotgit() helper
fsck: notice .git case-insensitively
t1450: refactor ".", "..", and ".git" fsck tests
verify_dotfile(): reject .git case-insensitively
read-tree: add tests for confusing paths like ".." and ".git"
unpack-trees: propagate errors adding entries to the index
Junio C Hamano [Wed, 17 Dec 2014 19:44:59 +0000 (11:44 -0800)]
Git 2.1.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 17 Dec 2014 19:42:28 +0000 (11:42 -0800)]
Sync with v2.0.5
* maint-2.0:
Git 2.0.5
Git 1.9.5
Git 1.8.5.6
fsck: complain about NTFS ".git" aliases in trees
read-cache: optionally disallow NTFS .git variants
path: add is_ntfs_dotgit() helper
fsck: complain about HFS+ ".git" aliases in trees
read-cache: optionally disallow HFS+ .git variants
utf8: add is_hfs_dotgit() helper
fsck: notice .git case-insensitively
t1450: refactor ".", "..", and ".git" fsck tests
verify_dotfile(): reject .git case-insensitively
read-tree: add tests for confusing paths like ".." and ".git"
unpack-trees: propagate errors adding entries to the index
Junio C Hamano [Wed, 17 Dec 2014 19:30:46 +0000 (11:30 -0800)]
Git 2.0.5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 17 Dec 2014 19:28:02 +0000 (11:28 -0800)]
Sync with v1.9.5
* maint-1.9:
Git 1.9.5
Git 1.8.5.6
fsck: complain about NTFS ".git" aliases in trees
read-cache: optionally disallow NTFS .git variants
path: add is_ntfs_dotgit() helper
fsck: complain about HFS+ ".git" aliases in trees
read-cache: optionally disallow HFS+ .git variants
utf8: add is_hfs_dotgit() helper
fsck: notice .git case-insensitively
t1450: refactor ".", "..", and ".git" fsck tests
verify_dotfile(): reject .git case-insensitively
read-tree: add tests for confusing paths like ".." and ".git"
unpack-trees: propagate errors adding entries to the index
Junio C Hamano [Wed, 17 Dec 2014 19:22:32 +0000 (11:22 -0800)]
Git 1.9.5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 17 Dec 2014 19:20:31 +0000 (11:20 -0800)]
Sync with v1.8.5.6
* maint-1.8.5:
Git 1.8.5.6
fsck: complain about NTFS ".git" aliases in trees
read-cache: optionally disallow NTFS .git variants
path: add is_ntfs_dotgit() helper
fsck: complain about HFS+ ".git" aliases in trees
read-cache: optionally disallow HFS+ .git variants
utf8: add is_hfs_dotgit() helper
fsck: notice .git case-insensitively
t1450: refactor ".", "..", and ".git" fsck tests
verify_dotfile(): reject .git case-insensitively
read-tree: add tests for confusing paths like ".." and ".git"
unpack-trees: propagate errors adding entries to the index
Junio C Hamano [Wed, 17 Dec 2014 19:18:45 +0000 (11:18 -0800)]
Git 1.8.5.6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 17 Dec 2014 19:11:15 +0000 (11:11 -0800)]
Merge branch 'dotgit-case-maint-1.8.5' into maint-1.8.5
* dotgit-case-maint-1.8.5:
fsck: complain about NTFS ".git" aliases in trees
read-cache: optionally disallow NTFS .git variants
path: add is_ntfs_dotgit() helper
fsck: complain about HFS+ ".git" aliases in trees
read-cache: optionally disallow HFS+ .git variants
utf8: add is_hfs_dotgit() helper
fsck: notice .git case-insensitively
t1450: refactor ".", "..", and ".git" fsck tests
verify_dotfile(): reject .git case-insensitively
read-tree: add tests for confusing paths like ".." and ".git"
unpack-trees: propagate errors adding entries to the index
Johannes Schindelin [Wed, 10 Dec 2014 21:28:27 +0000 (22:28 +0100)]
fsck: complain about NTFS ".git" aliases in trees
Now that the index can block pathnames that can be mistaken
to mean ".git" on NTFS and FAT32, it would be helpful for
fsck to notice such problematic paths. This lets servers
which use receive.fsckObjects block them before the damage
spreads.
Note that the fsck check is always on, even for systems
without core.protectNTFS set. This is technically more
restrictive than we need to be, as a set of users on ext4
could happily use these odd filenames without caring about
NTFS.
However, on balance, it's helpful for all servers to block
these (because the paths can be used for mischief, and
servers which bother to fsck would want to stop the spread
whether they are on NTFS themselves or not), and hardly
anybody will be affected (because the blocked names are
variants of .git or git~1, meaning mischief is almost
certainly what the tree author had in mind).
Ideally these would be controlled by a separate
"fsck.protectNTFS" flag. However, it would be much nicer to
be able to enable/disable _any_ fsck flag individually, and
any scheme we choose should match such a system. Given the
likelihood of anybody using such a path in practice, it is
not unreasonable to wait until such a system materializes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Schindelin [Tue, 16 Dec 2014 22:46:59 +0000 (23:46 +0100)]
read-cache: optionally disallow NTFS .git variants
The point of disallowing ".git" in the index is that we
would never want to accidentally overwrite files in the
repository directory. But this means we need to respect the
filesystem's idea of when two paths are equal. The prior
commit added a helper to make such a comparison for NTFS
and FAT32; let's use it in verify_path().
We make this check optional for two reasons:
1. It restricts the set of allowable filenames, which is
unnecessary for people who are not on NTFS nor FAT32.
In practice this probably doesn't matter, though, as
the restricted names are rather obscure and almost
certainly would never come up in practice.
2. It has a minor performance penalty for every path we
insert into the index.
This patch ties the check to the core.protectNTFS config
option. Though this is expected to be most useful on Windows,
we allow it to be set everywhere, as NTFS may be mounted on
other platforms. The variable does default to on for Windows,
though.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Schindelin [Tue, 16 Dec 2014 22:31:03 +0000 (23:31 +0100)]
path: add is_ntfs_dotgit() helper
We do not allow paths with a ".git" component to be added to
the index, as that would mean repository contents could
overwrite our repository files. However, asking "is this
path the same as .git" is not as simple as strcmp() on some
filesystems.
On NTFS (and FAT32), there exist so-called "short names" for
backwards-compatibility: 8.3 compliant names that refer to the same files
as their long names. As ".git" is not an 8.3 compliant name, a short name
is generated automatically, typically "git~1".
Depending on the Windows version, any combination of trailing spaces and
periods are ignored, too, so that both "git~1." and ".git." still refer
to the Git directory. The reason is that 8.3 stores file names shorter
than 8 characters with trailing spaces. So literally, it does not matter
for the short name whether it is padded with spaces or whether it is
shorter than 8 characters, it is considered to be the exact same.
The period is the separator between file name and file extension, and
again, an empty extension consists just of spaces in 8.3 format. So
technically, we would need only take care of the equivalent of this
regex:
(\.git {0,4}|git~1 {0,3})\. {0,3}
However, there are indications that at least some Windows versions might
be more lenient and accept arbitrary combinations of trailing spaces and
periods and strip them out. So we're playing it real safe here. Besides,
there can be little doubt about the intention behind using file names
matching even the more lenient pattern specified above, therefore we
should be fine with disallowing such patterns.
Extra care is taken to catch names such as '.\\.git\\booh' because the
backslash is marked as a directory separator only on Windows, and we want
to use this new helper function also in fsck on other platforms.
A big thank you goes to Ed Thomson and an unnamed Microsoft engineer for
the detailed analysis performed to come up with the corresponding fixes
for libgit2.
This commit adds a function to detect whether a given file name can refer
to the Git directory by mistake.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 15 Dec 2014 23:21:57 +0000 (18:21 -0500)]
fsck: complain about HFS+ ".git" aliases in trees
Now that the index can block pathnames that case-fold to
".git" on HFS+, it would be helpful for fsck to notice such
problematic paths. This lets servers which use
receive.fsckObjects block them before the damage spreads.
Note that the fsck check is always on, even for systems
without core.protectHFS set. This is technically more
restrictive than we need to be, as a set of users on ext4
could happily use these odd filenames without caring about
HFS+.
However, on balance, it's helpful for all servers to block
these (because the paths can be used for mischief, and
servers which bother to fsck would want to stop the spread
whether they are on HFS+ themselves or not), and hardly
anybody will be affected (because the blocked names are
variants of .git with invisible Unicode code-points mixed
in, meaning mischief is almost certainly what the tree
author had in mind).
Ideally these would be controlled by a separate
"fsck.protectHFS" flag. However, it would be much nicer to
be able to enable/disable _any_ fsck flag individually, and
any scheme we choose should match such a system. Given the
likelihood of anybody using such a path in practice, it is
not unreasonable to wait until such a system materializes.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 15 Dec 2014 23:15:20 +0000 (18:15 -0500)]
read-cache: optionally disallow HFS+ .git variants
The point of disallowing ".git" in the index is that we
would never want to accidentally overwrite files in the
repository directory. But this means we need to respect the
filesystem's idea of when two paths are equal. The prior
commit added a helper to make such a comparison for HFS+;
let's use it in verify_path.
We make this check optional for two reasons:
1. It restricts the set of allowable filenames, which is
unnecessary for people who are not on HFS+. In practice
this probably doesn't matter, though, as the restricted
names are rather obscure and almost certainly would
never come up in practice.
2. It has a minor performance penalty for every path we
insert into the index.
This patch ties the check to the core.protectHFS config
option. Though this is expected to be most useful on OS X,
we allow it to be set everywhere, as HFS+ may be mounted on
other platforms. The variable does default to on for OS X,
though.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 15 Dec 2014 22:56:59 +0000 (17:56 -0500)]
utf8: add is_hfs_dotgit() helper
We do not allow paths with a ".git" component to be added to
the index, as that would mean repository contents could
overwrite our repository files. However, asking "is this
path the same as .git" is not as simple as strcmp() on some
filesystems.
HFS+'s case-folding does more than just fold uppercase into
lowercase (which we already handle with strcasecmp). It may
also skip past certain "ignored" Unicode code points, so
that (for example) ".gi\u200ct" is mapped ot ".git".
The full list of folds can be found in the tables at:
https://www.opensource.apple.com/source/xnu/xnu-1504.15.3/bsd/hfs/hfscommon/Unicode/UCStringCompareData.h
Implementing a full "is this path the same as that path"
comparison would require us importing the whole set of
tables. However, what we want to do is much simpler: we
only care about checking ".git". We know that 'G' is the
only thing that folds to 'g', and so on, so we really only
need to deal with the set of ignored code points, which is
much smaller.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 24 Nov 2014 18:40:44 +0000 (13:40 -0500)]
fsck: notice .git case-insensitively
We complain about ".git" in a tree because it cannot be
loaded into the index or checked out. Since we now also
reject ".GIT" case-insensitively, fsck should notice the
same, so that errors do not propagate.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 24 Nov 2014 18:40:11 +0000 (13:40 -0500)]
t1450: refactor ".", "..", and ".git" fsck tests
We check that fsck notices and complains about confusing
paths in trees. However, there are a few shortcomings:
1. We check only for these paths as file entries, not as
intermediate paths (so ".git" and not ".git/foo").
2. We check "." and ".." together, so it is possible that
we notice only one and not the other.
3. We repeat a lot of boilerplate.
Let's use some loops to be more thorough in our testing, and
still end up with shorter code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 24 Nov 2014 18:39:12 +0000 (13:39 -0500)]
verify_dotfile(): reject .git case-insensitively
We do not allow ".git" to enter into the index as a path
component, because checking out the result to the working
tree may causes confusion for subsequent git commands.
However, on case-insensitive file systems, ".Git" or ".GIT"
is the same. We should catch and prevent those, too.
Note that technically we could allow this for repos on
case-sensitive filesystems. But there's not much point. It's
unlikely that anybody cares, and it creates a repository
that is unexpectedly non-portable to other systems.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 24 Nov 2014 18:37:56 +0000 (13:37 -0500)]
read-tree: add tests for confusing paths like ".." and ".git"
We should prevent nonsense paths from entering the index in
the first place, as they can cause confusing results if they
are ever checked out into the working tree. We already do
so, but we never tested it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 24 Nov 2014 18:36:51 +0000 (13:36 -0500)]
unpack-trees: propagate errors adding entries to the index
When unpack_trees tries to write an entry to the index,
add_index_entry may report an error to stderr, but we ignore
its return value. This leads to us returning a successful
exit code for an operation that partially failed. Let's make
sure to propagate this code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 10 Dec 2014 10:40:36 +0000 (05:40 -0500)]
read_packed_refs: use skip_prefix instead of static array
We want to recognize the packed-refs header and skip to the
"traits" part of the line. We currently do it by feeding
sizeof() a static const array to strncmp. However, it's a
bit simpler to just skip_prefix, which expresses the
intention more directly, and without remembering to account
for the NUL-terminator in each sizeof() call.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 10 Dec 2014 10:40:19 +0000 (05:40 -0500)]
read_packed_refs: pass strbuf to parse_ref_line
Now that we have a strbuf in read_packed_refs, we can pass
it straight to the line parser, which saves us an extra
strlen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 10 Dec 2014 10:40:07 +0000 (05:40 -0500)]
read_packed_refs: use a strbuf for reading lines
Current code uses a fixed PATH_MAX-sized buffer for reading
packed-refs lines. This is a reasonable guess, in the sense
that git generally cannot work with refs larger than
PATH_MAX. However, there are a few cases where it is not
great:
1. Some systems may have a low value of PATH_MAX, but can
actually handle larger paths in practice. Fixing this
code path probably isn't enough to make them work
completely with long refs, but it is a step in the
right direction.
2. We use fgets, which will happily give us half a line on
the first read, and then the rest of the line on the
second. This is probably OK in practice, because our
refline parser is careful enough to look for the
trailing newline on the first line. The second line may
look like a peeled line to us, but since "^" is illegal
in refnames, it is not likely to come up.
Still, it does not hurt to be more careful.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ronald Wampler [Tue, 9 Dec 2014 17:28:18 +0000 (12:28 -0500)]
git-am.txt: --ignore-date flag is not passed to git-apply
Signed-off-by: Ronald Wampler <rdwampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Fri, 5 Dec 2014 19:38:24 +0000 (11:38 -0800)]
Merge branch 'maint' of git://github.com/git-l10n/git-po into maint
* 'maint' of git://github.com/git-l10n/git-po:
l10n: de.po: fix typos
Junio C Hamano [Fri, 5 Dec 2014 19:38:19 +0000 (11:38 -0800)]
Start post 2.2 cycle
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 5 Dec 2014 01:32:44 +0000 (20:32 -0500)]
for_each_reflog_ent_reverse: turn leftover check into assertion
Our loop should always process all lines, even if we hit the
beginning of the file. We have a conditional after the loop
ends to double-check that there is nothing left and to
process it. But this should never happen, and is a sign of a
logic bug in the loop. Let's turn it into a BUG assertion.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 5 Dec 2014 01:28:54 +0000 (20:28 -0500)]
for_each_reflog_ent_reverse: fix newlines on block boundaries
When we read a reflog file in reverse, we read whole chunks
of BUFSIZ bytes, then loop over the buffer, parsing any
lines we find. We find the beginning of each line by looking
for the newline from the previous line. If we don't find
one, we know that we are either at the beginning of
the file, or that we have to read another block.
In the latter case, we stuff away what we have into a
strbuf, read another block, and continue our parse. But we
missed one case here. If we did find a newline, and it is at
the beginning of the block, we must also stuff that newline
into the strbuf, as it belongs to the block we are about to
read.
The minimal fix here would be to add this special case to
the conditional that checks whether we found a newline.
But we can make the flow a little clearer by rearranging a
bit: we first handle lines that we are going to show, and
then at the end of each loop, stuff away any leftovers if
necessary. That lets us fold this special-case in with the
more common "we ended in the middle of a line" case.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Thu, 27 Nov 2014 03:43:06 +0000 (22:43 -0500)]
push: truly use "simple" as default, not "upstream"
The plan for the push.default transition had all along been
to use the "simple" method rather than "upstream" as a
default if the user did not specify their own push.default
value. Commit
11037ee (push: switch default from "matching"
to "simple", 2013-01-04) tried to implement that by moving
PUSH_DEFAULT_UNSPECIFIED in our switch statement to
fall-through to the PUSH_DEFAULT_SIMPLE case.
When the commit that became
11037ee was originally written,
that would have been enough. We would fall through to
calling setup_push_upstream() with the "simple" parameter
set to 1. However, it was delayed for a while until we were
ready to make the transition in Git 2.0.
And in the meantime, commit
ed2b182 (push: change `simple`
to accommodate triangular workflows, 2013-06-19) threw a
monkey wrench into the works. That commit drops the "simple"
parameter to setup_push_upstream, and instead checks whether
the global "push_default" is PUSH_DEFAULT_SIMPLE. This is
right when the user has explicitly configured push.default
to simple, but wrong when we are a fall-through for the
"unspecified" case.
We never noticed because our push.default tests do not cover
the case of the variable being totally unset; they only
check the "simple" behavior itself.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jiang Xin [Sat, 29 Nov 2014 02:44:48 +0000 (10:44 +0800)]
Merge branch 'master' of https://github.com/ralfth/git-po-de
* 'master' of https://github.com/ralfth/git-po-de:
l10n: de.po: fix typos
Hartmut Henkel [Sun, 23 Nov 2014 15:19:49 +0000 (16:19 +0100)]
l10n: de.po: fix typos
Signed-off-by: Hartmut Henkel <hartmut_henkel@gmx.de>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Junio C Hamano [Wed, 26 Nov 2014 21:18:34 +0000 (13:18 -0800)]
Git 2.2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Marc Branchaud [Fri, 21 Nov 2014 23:10:04 +0000 (18:10 -0500)]
RelNotes: spelling & grammar tweaks
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mike Hommey [Wed, 26 Nov 2014 10:12:47 +0000 (19:12 +0900)]
sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrev
An example where this happens is when doing an ls-tree on a tree that
contains a commit link. In that case, find_unique_abbrev is called
to get a non-abbreviated hex sha1, but still, a lookup is done as
to whether the sha1 is in the repository (which ends up looking for
a loose object in .git/objects), while the result of that lookup is
not used when returning a non-abbreviated hex sha1.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Fri, 21 Nov 2014 20:10:56 +0000 (12:10 -0800)]
Git 2.2.0-rc3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael J Gruber [Fri, 21 Nov 2014 16:08:19 +0000 (17:08 +0100)]
add: ignore only ignored files
"git add foo bar" adds neither foo nor bar when bar is ignored, but dies
to let the user recheck their command invocation. This becomes less
helpful when "git add foo.*" is subject to shell expansion and some of
the expanded files are ignored.
"git add --ignore-errors" is supposed to ignore errors when indexing
some files and adds the others. It does ignore errors from actual
indexing attempts, but does not ignore the error "file is ignored" as
outlined above. This is unexpected.
Change "git add foo bar" to add foo when bar is ignored, but issue
a warning and return a failure code as before the change.
That is, in the case of trying to add ignored files we now act the same
way (with or without "--ignore-errors") in which we act for more
severe indexing errors when "--ignore-errors" is specified.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Thu, 20 Nov 2014 15:16:09 +0000 (10:16 -0500)]
t4026: test "normal" color
If the user specifiers "normal" for a foreground color, this
should be a noop (while this may sound useless, it is the
only way to specify an unchanged foreground color followed
by a specific background color).
We also check that color "-1" does the same thing. This is
not documented, but has worked forever, so let's make sure
we keep supporting it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Thu, 20 Nov 2014 15:15:51 +0000 (10:15 -0500)]
config: fix parsing of "git config --get-color some.key -1"
Most of git-config's command line options use OPT_BIT to
choose an action, and then parse the non-option arguments
in a context-dependent way. However, --get-color and
--get-colorbool are unlike the rest of the options, in that
they are OPT_STRING, taking the option name as a parameter.
This generally works, because we then use the presence of
those strings to set an action bit anyway. But it does mean
that the option-parser will continue looking for options
even after the key (because it is not a non-option; it is an
argument to an option). And running:
git config --get-color some.key -1
(to use "-1" as the default color spec) will barf, claiming
that "-1" is not an option. Instead, we should treat
--get-color and --get-colorbool as action bits, just like
--add, --get, and all the other actions, and then check that
the non-option arguments we got are sane. This fixes the
weirdness above, and makes those two options like all the
others.
This "fixes" a test in t4026, which checked that feeding
"-2" as a color should fail (it does fail, but prior to this
patch, because parseopt barfed, not because we actually ever
tried to parse the color).
This also catches other errors, like:
git config --get-color some.key black blue
which previously silently ignored "blue" (and now will
complain that you gave too many arguments).
There are some possible regressions, though. We now disallow
these, which currently do what you would expect:
# specifying other options after the action
git config --get-color some.key --file whatever
# using long-arg syntax
git config --get-color=some.key
However, we have never advertised these in the
documentation, and in fact they did not work in some older
versions of git. The behavior was apparently switched as an
accidental side effect of
d64ec16 (git config: reorganize to
use parseopt, 2009-02-21).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Thu, 20 Nov 2014 15:15:31 +0000 (10:15 -0500)]
docs: describe ANSI 256-color mode
Our color specifications have supported the 256-color ANSI
extension for years, but we never documented it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jiang Xin [Thu, 20 Nov 2014 08:12:34 +0000 (16:12 +0800)]
l10n: remove a superfluous translation for push.c
Ralf reported that '--recurse-submodules' option in push.c should not be
translated [1]. Before his commit is merged, remove superfluous
translations for push.c.
[1] http://www.spinics.net/lists/git/msg241964.html
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Ralf Thielow [Thu, 20 Nov 2014 06:15:15 +0000 (07:15 +0100)]
l10n: de.po: translate 2 messages
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Ralf Thielow [Tue, 18 Nov 2014 18:06:51 +0000 (19:06 +0100)]
l10n: de.po: translate 2 new messages
Signed-off-by: Phillip Sz <phillip.szelat@gmail.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Jiang Xin [Thu, 20 Nov 2014 02:53:48 +0000 (10:53 +0800)]
l10n: batch updates for one trivial change
In order to catch up with the release of Git 2.2.0 final, make a batch
l10n update for the new l10n change brought by commit
d52adf1 (trailer:
display a trailer without its trailing newline).
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Jiang Xin [Thu, 20 Nov 2014 02:03:10 +0000 (10:03 +0800)]
l10n: git.pot: v2.2.0 round 2 (1 updated)
Generate po/git.pot from
v2.2.0-rc2-23-gca0107e for git v2.2.0 l10n
round 2.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Junio C Hamano [Wed, 19 Nov 2014 21:48:01 +0000 (13:48 -0800)]
Merge branch 'sv/submitting-final-patch'
* sv/submitting-final-patch:
SubmittingPatches: final submission is To: maintainer and CC: list
Junio C Hamano [Wed, 19 Nov 2014 21:47:59 +0000 (13:47 -0800)]
Merge branch 'sn/tutorial-status-output-example'
* sn/tutorial-status-output-example:
gittutorial: fix output of 'git status'
Junio C Hamano [Wed, 19 Nov 2014 21:47:55 +0000 (13:47 -0800)]
Merge branch 'mh/doc-remote-helper-xref'
* mh/doc-remote-helper-xref:
doc: add some crossrefs between manual pages
Junio C Hamano [Wed, 19 Nov 2014 21:47:53 +0000 (13:47 -0800)]
Merge branch 'tb/no-relative-file-url'
* tb/no-relative-file-url:
t5705: the file:// URL should be absolute
Junio C Hamano [Wed, 19 Nov 2014 21:47:49 +0000 (13:47 -0800)]
Merge branch 'cc/interpret-trailers'
Small fixes to a new experimental command already in 'master'.
* cc/interpret-trailers:
trailer: display a trailer without its trailing newline
trailer: ignore comment lines inside the trailers
Jeff King [Tue, 18 Nov 2014 17:10:22 +0000 (12:10 -0500)]
gitweb: hack around CGI's list-context param() handling
As of CGI.pm's 4.08 release, the behavior to call
CGI::param() in a list context is deprecated (because it can
be potentially unsafe if called inside a hash constructor).
This causes gitweb to issue a warning for some of our code,
which in turn causes the tests to fail.
Our use is in fact _not_ one of the dangerous cases, as we
are intentionally using a list context. The recommended
route by 4.08 is to use the new CGI::multi_param() call to
make it explicit that we know what we are doing.
However, that function is only available in 4.08, which is
about a month old; we cannot rely on having it.
One option would be to set $CGI::LIST_CONTEXT_WARN globally,
which turns off the warning. However, that would eliminate
the protection these newer releases are trying to provide.
We want to annotate each site as OK using the new function.
So instead, let's check whether CGI provides the
multi_param() function, and if not, provide an
implementation that just wraps param(). That will work on
both old and new versions of CGI. Sadly, we cannot just
check defined(\&CGI::multi_param), because CGI uses the
autoload feature, which claims that all functions are
defined. Instead, we just do a version check.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jonathan Nieder [Tue, 18 Nov 2014 18:43:47 +0000 (10:43 -0800)]
Makefile: have python scripts depend on NO_PYTHON setting
Like the perl scripts, python scripts need a dependency to ensure they
are rebuilt when switching between the "dummy" versions that run
without Python and the real thing.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jonathan Nieder [Tue, 18 Nov 2014 18:38:38 +0000 (10:38 -0800)]
Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros
SCRIPT_PERL_GEN is defined as $(patsubst %.perl,%,$(SCRIPT_PERL))
for use in targets like build-perl-script used by makefiles in
subdirectories that override SCRIPT_PERL (see v1.8.2-rc0~17^2,
"git-remote-mediawiki: use toplevel's Makefile", 2013-02-08).
The same expression is used in the rules that actually write the
generated perl scripts, and since these rules were introduced before
SCRIPT_PERL_GEN, they use the longhand instead of that macro. Use the
macro to make reading easier.
Likewise for SCRIPT_SH_GEN. The Python rules already got the same
simplification in v1.8.4-rc0~162^2~8 (2013-05-24).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 18 Nov 2014 18:27:46 +0000 (10:27 -0800)]
Merge git://github.com/git-l10n/git-po
* 'master' of git://github.com/git-l10n/git-po:
l10n: Update Catalan translation
Junio C Hamano [Tue, 18 Nov 2014 18:19:38 +0000 (10:19 -0800)]
Merge branch 'jc/doc-commit-only'
* jc/doc-commit-only:
Documentation/git-commit: clarify that --only/--include records the working tree contents
Junio C Hamano [Tue, 18 Nov 2014 18:18:28 +0000 (10:18 -0800)]
Merge branch 'ta/tutorial-modernize'
* ta/tutorial-modernize:
gittutorial.txt: remove reference to ancient Git version
Junio C Hamano [Tue, 18 Nov 2014 18:16:54 +0000 (10:16 -0800)]
Merge branch 'da/difftool'
Fix-up to a new feature in 'master'.
* da/difftool:
difftool: honor --trust-exit-code for builtin tools