This teaches "push <remote> HEAD" to resolve HEAD on the local
side to its real branch name, e.g. master, and then act as if
the real branch name was specified. So we have a shorthand for
pushing the current branch. Besides HEAD, no other symbolic ref
is resolved.

Thanks to Daniel Barkalow <barkalow@iabervon.org> for suggesting
this implementation, which is much simpler than the
implementation proposed before.
Signed-off-by: NSteffen Prohaska <prohaska@zib.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* lt/rev-list-gitlink:
  Fix rev-list when showing objects involving submodules

* ds/checkout-upper:
  git-checkout: Test for relative path use.
  git-checkout: Support relative paths containing "..".

* sh/p4:
  git-p4: Fix direct import from perforce after fetching changes through git from origin

* lt/rev-list-interactive:
  Fix parent rewriting in --early-output
  revision walker: mini clean-up
  Enhance --early-output format
  Add "--early-output" log flag for interactive GUI use
  Simplify topo-sort logic

* ph/diffopts:
  Reorder diff_opt_parse options more logically per topics.
  Make the diff_options bitfields be an unsigned with explicit masks.
  Use OPT_BIT in builtin-pack-refs
  Use OPT_BIT in builtin-for-each-ref
  Use OPT_SET_INT and OPT_BIT in builtin-branch
  parse-options new features.

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

* maint:
  GIT 1.5.3.6
  grep -An -Bm: fix invocation of external grep command
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Define NO_MKDTEMP for all variants of SunOS; Solaris 10 does not
have mkdtemp() and all the other versions our Makefile knows
about don't have it either.

NO_{SETENV,UNSETENV,C99_FORMAT,STRTOUMAX} definitions cannot be
unified across versions.  Beginning with Solaris 10, the C-library
provides unsetenv(), setenv() and strtoumax().  Also 'z'/'t' formats
are supported.  However, older versions of Solaris do not support
these.
Signed-off-by: NGuido Ostkamp <git@ostkamp.fastmail.fm>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* ph/parseopt-sh:
  git-quiltimport.sh fix --patches handling
  git-am: -i does not take a string parameter.
  sh-setup: don't let eval output to be shell-expanded.
  git-sh-setup: fix parseopt `eval` string underquoting
  Give git-am back the ability to add Signed-off-by lines.
  git-rev-parse --parseopt
  scripts: Add placeholders for OPTIONS_SPEC
  Migrate git-repack.sh to use git-rev-parse --parseopt
  Migrate git-quiltimport.sh to use git-rev-parse --parseopt
  Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash
  Migrate git-instaweb.sh to use git-rev-parse --parseopt
  Migrate git-merge.sh to use git-rev-parse --parseopt
  Migrate git-am.sh to use git-rev-parse --parseopt
  Migrate git-clone to use git-rev-parse --parseopt
  Migrate git-clean.sh to use git-rev-parse --parseopt.
  Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt
  Add a parseopt mode to git-rev-parse to bring parse-options to shell scripts.

When building command line to invoke external grep, the
arguments to -A/-B/-C options were placd in randarg[] buffer,
but the code forgot that snprintf() does not count terminating
NUL in its return value.  This caused "git grep -A1 -B2" to
invoke external grep with "-B21 -A1".
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* git://git.bogomips.org/git-svn:
  git-svn: Fix a typo and add a comma in an error message in git-svn
  git-svn log: handle unreachable revisions like "svn log"
  git-svn log: include commit log for the smallest revision in a range
  git-svn log: fix ascending revision ranges
  git-svn's dcommit must use subversion's config
  git-svn: add tests for command-line usage of init and clone commands

Signed-off-by: NDavid Reiss <dreiss@facebook.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

When unreachable revisions are given to "svn log", it displays all commit
logs in the given range that exist in the current tree.  (If no commit
logs are found in the current tree, it simply prints a single commit log
separator.)  This patch makes "git-svn log" behave the same way.

Ten tests added to t/t9116-git-svn-log.sh.
Signed-off-by: NDavid D Kilzer <ddkilzer@kilzer.net>
Acked-by: NEric Wong <normalperson@yhbt.net>

The "svn log -rM:N" command shows commit logs inclusive in the range [M,N].
Previously "git-svn log" always excluded the commit log for the smallest
revision in a range, whether the range was ascending or descending.  With
this patch, the smallest revision in a range is always shown.

Updated tests for ascending and descending revision ranges.
Signed-off-by: NDavid D Kilzer <ddkilzer@kilzer.net>
Acked-by: NEric Wong <normalperson@yhbt.net>

Fixed typo in Git::SVN::Log::git_svn_log_cmd().  Previously a command like
"git-svn log -r1:4" would only show a commit log separator.

Added tests for ascending and descending revision ranges.
Signed-off-by: NDavid D Kilzer <ddkilzer@kilzer.net>
Acked-by: NEric Wong <normalperson@yhbt.net>

When doing dcommit git-svn must use subversion's config or newly created
files will not include svn's properties
(defined in [auto-props] with 'enable-auto-props = yes').
Signed-off-by: NKonstantin V. Arkhipov <voxus@onphp.org>
Acked-by: NEric Wong <normalperson@yhbt.net>

Some patches broke these commands in certain cases and were only
caught by manual testing.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

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

Brown paper bag fix to avoid using non portable sed syntax. The
test by itself didn't catch what it was supposed to, anyways.

The new test first checks if git-tag correctly errors out when
the user exited the editor without editing the file.  Then it
checks if what the user was presented in the editor was any
useful, which we define as the following:

 * It begins with a single blank line, where the invoked editor
   would typically place the editing curser at, so that the user
   can immediately start typing;

 * It has some instruction but that comes after that initial
   blank line, all lines prefixed with "#".  We specifically do
   not check for the wording of this instruction.

 * And it has nothing else, as the expected behaviour is "Hey
   you did not leave any message".
Signed-off-by: NMike Hommey <mh@glandium.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NSergei Organov <osv@javad.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NSergei Organov <osv@javad.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  Update draft release notes for 1.5.3.6
  Fix per-directory exclude handing for "git add"
  core.excludesfile clean-up
  Fix t9101 test failure caused by Subversion "auto-props"
  git-send-email: add charset header if we add encoded 'From'

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

* ds/maint-deflatebound:
  Improve accuracy of check for presence of deflateBound.

In "dir_struct", each exclusion element in the exclusion stack records a
base string (pointer to the beginning with length) so that we can tell
where it came from, but this pointer is just pointing at the parameter
that is given by the caller to the push_exclude_per_directory()
function.

While read_directory_recursive() runs, calls to excluded() makes use
the data in the exclusion elements, including this base string.  The
caller of read_directory_recursive() is not supposed to free the
buffer it gave to push_exclude_per_directory() earlier, until it
returns.

The test case Bruce Stephens gave in the mailing list discussion
was simplified and added to the t3700 test.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable.  The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.

 * git-ls-files does not notice any of the "ignore" files by
   default, as it predates the standardized set of ignore files.
   The calling scripts established the convention to use
   .git/info/exclude, .gitignore, and later core.excludesfile.

 * git-add and git-status know about it because they call
   add_excludes_from_file() directly with their own notion of
   which standard set of ignore files to use.  This is just a
   stupid duplication of code that need to be updated every time
   the definition of the standard set of ignore files is
   changed.

 * git-read-tree takes --exclude-per-directory=<gitignore>,
   not because the flexibility was needed.  Again, this was
   because the option predates the standardization of the ignore
   files.

 * git-merge-recursive uses hardcoded per-directory .gitignore
   and nothing else.  git-clean (scripted version) does not
   honor core.* because its call to underlying ls-files does not
   know about it.  git-clean in C (parked in 'pu') doesn't either.

We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way.  I am somewhat reluctant to make such a change.

On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands.  I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.

This patch is the first step to untangle this mess.

The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If a user has an "auto-prop" in his/her ~/.subversion/config file for
automatically setting the svn:keyword Id property on all ".c" files
(a reasonably common configuration in the Subversion world) then one
of the "svn propset" operations in the very first test would become a
no-op, which in turn would make the next commit a no-op.

This then caused the 25th test ('test propget') to fail because it
expects a certain number of commits to have taken place but the actual
number of commits was off by one.

Björn Steinbrink identified the "auto-prop" feature as the cause
of the failure. This patch avoids it by passing the "--no-auto-prop"
flag to "svn import" when setting up the test repository, thus ensuring
that the "svn propset" operation is no longer a no-op, regardless of the
users' settings in their config.
Signed-off-by: NWincent Colaiuta <win@wincent.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We sometimes pick out the original rfc822 'From' header and
include it in the body of the message. If the original
author's name needs encoding, then we should specify that in
the content-type header.

If we already had a content-type header in the mail, then we
may need to re-encode. The logic is there to detect
this case, but it doesn't actually do the re-encoding.
Signed-off-by: NJeff King <peff@peff.net>
Acked-by: NUwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When using an existing git repository to cache the perforce import we don't
fetch the branch mapping from perforce as that is a slow operation. However
the origin repository may not be fully up-to-date and therefore it may be
necessary to import more changes directly from Perforce.

Such a direct import needs self.knownBranches to be set up though, so
initialize it from the existing p4/* git branches.
Signed-off-by: NSimon Hausmann <simon@lst.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In "dir_struct", each exclusion element in the exclusion stack records a
base string (pointer to the beginning with length) so that we can tell
where it came from, but this pointer is just pointing at the parameter
that is given by the caller to the push_exclude_per_directory()
function.

While read_directory_recursive() runs, calls to excluded() makes use
the data in the exclusion elements, including this base string.  The
caller of read_directory_recursive() is not supposed to free the
buffer it gave to push_exclude_per_directory() earlier, until it
returns.

The test case Bruce Stephens gave in the mailing list discussion
was simplified and added to the t3700 test.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Customize diff-options depending on particular command as follows,
mostly to make git-diff and git-format-patch manuals less confusing:

* git-format-patch:

  - Mark --patch-with-stat as being the default.

  - Change -p description so that it matches what it actually does and
    so that it doesn't refer to absent "section on generating
    patches".

* git-diff: mark -p as being the default.

* git-diff-index/git-diff-files/git-diff-tree: mark --raw as being
  the default.
Signed-off-by: NSergei Organov <osv@javad.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This provides a way for scripts to get at the new standard exclude
function.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Solaris Workshop Compiler found a few unreachable statements.
Signed-off-by: NGuido Ostkamp <git@ostkamp.fastmail.fm>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable.  The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.

 * git-ls-files does not notice any of the "ignore" files by
   default, as it predates the standardized set of ignore files.
   The calling scripts established the convention to use
   .git/info/exclude, .gitignore, and later core.excludesfile.

 * git-add and git-status know about it because they call
   add_excludes_from_file() directly with their own notion of
   which standard set of ignore files to use.  This is just a
   stupid duplication of code that need to be updated every time
   the definition of the standard set of ignore files is
   changed.

 * git-read-tree takes --exclude-per-directory=<gitignore>,
   not because the flexibility was needed.  Again, this was
   because the option predates the standardization of the ignore
   files.

 * git-merge-recursive uses hardcoded per-directory .gitignore
   and nothing else.  git-clean (scripted version) does not
   honor core.* because its call to underlying ls-files does not
   know about it.  git-clean in C (parked in 'pu') doesn't either.

We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way.  I am somewhat reluctant to make such a change.

On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands.  I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.

This patch is the first step to untangle this mess.

The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* sp/fetch-fix:
  git-fetch: avoid local fetching from alternate (again)
  rev-list: Introduce --quiet to avoid /dev/null redirects
  run-command: Support sending stderr to /dev/null
  git-fetch: Always fetch tags if the object they reference exists

* bs/maint-commit-options:
  git-commit: Add tests for invalid usage of -a/--interactive with paths
  git-commit.sh: Fix usage checks regarding paths given when they do not make sense