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

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

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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

* 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

* mg/add-ignore-errors:
  add: ignore only ignored files

* mh/find-uniq-abbrev:
  sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrev

* 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

* rw/apply-does-not-take-ignore-date:
  git-am.txt: --ignore-date flag is not passed to git-apply

* 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

* maint-2.1:
  is_hfs_dotgit: loosen over-eager match of \u{..47}

* maint-2.0:
  is_hfs_dotgit: loosen over-eager match of \u{..47}

* maint-1.9:
  is_hfs_dotgit: loosen over-eager match of \u{..47}

* maint-1.8.5:
  is_hfs_dotgit: loosen over-eager match of \u{..47}

* jk/dotgit-case-maint-1.8.5:
  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: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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

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

"Everyday" document had a broken link.

* po/everyday-doc:
  Documentation: change "gitlink" typo in git-push

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"

"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

"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

* rs/receive-pack-use-labs:
  use labs() for variables of type long instead of abs()

* rs/maint-config-use-labs:
  use labs() for variables of type long instead of abs()

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()

"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

"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

Signed-off-by: NAlexander Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* 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