Merge branch 'maint'

* maint:
  git-am -i: report rewritten title
  git grep shows the same hit repeatedly for unmerged paths
  Do check_repository_format() early (re-fix)
  Do check_repository_format() early
  Add missing inside_work_tree setting in setup_git_directory_gently

git-am -i: report rewritten title

Jeff Garzik noticed that "git am -i" reports the applied patch with
the title before the user edited it.  This was confusing.

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

git grep shows the same hit repeatedly for unmerged paths

When the index is unmerged, e.g.

$ git ls-files -u
        100644 faf413748eb6ccb15161a212156c5e348302b1b6 1 setup.c
        100644 145eca50f41d811c4c8fcb21ed2604e6b2971aba 2 setup.c
        100644 cb9558c49b6027bf225ba2a6154c4d2a52bcdbe2 3 setup.c

running "git grep" for work tree files repeats hits for each unmerged
stage.

$ git grep -n -e setup_work_tree -- '*.[ch]'
        setup.c:209:void setup_work_tree(void)
        setup.c:209:void setup_work_tree(void)
        setup.c:209:void setup_work_tree(void)

This should fix it.

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

Merge branch 'nd/maint-work-tree-fix' into maint

* nd/maint-work-tree-fix:
  Do check_repository_format() early (re-fix)
  Do check_repository_format() early
  Add missing inside_work_tree setting in setup_git_directory_gently

Do check_repository_format() early (re-fix)

This pushes check_repository_format() (actually _gently() version)
to setup_git_directory_gently() in order to prevent from
using unsupported repositories.

New setup_git_directory_gently()'s behaviour is stop searching
for a valid gitdir and return as if there is no gitdir if a
unsupported repository is found. Warning will be thrown in these
cases.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Revert "git-am: catch missing author date early."

This reverts commit 6e9e0327b7d7f384d8a223b4bc40330ef3e7fb61.  People
can prepare a text file with Subject: and From: headers and feed it to
"am" (pretending the file is a piece of e-mail), and have actually been
doing so.  Strict checking for Date: breaks this established workflow,
which wants to record the time of the commit as the author time.

Thanks go to Jens Axboe for injection of sanity.

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

git config: Don't rely on regexec() returning 1 on non-match

Some systems don't return 1 from regexec() when the pattern does not
match (notably HP-UX which returns 20).

Bug identified by Dscho and H.Merijn Brand.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Tested-by: H.Merijn Brand <h.m.brand@xs4all.nl>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: add --patch option to synopsis of git-add

Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Set OLD_ICONV on Cygwin.

Cygwin still has old definition for the iconv() second
parameter. This patch fixes the last warning on Cygwin.
This has been tested with Cygwin 1.5.24.

Signed-off-by: Pascal Obry <pascal@obry.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5510: add a bit more tests for fetch

"git pull/fetch" that gets explicit refspecs from the command line should
not update configured tracking refs.

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

Merge branch 'wc/add-i'

* wc/add-i:
  git-add -i: add help text for list-and-choose UI
  add -i: allow prefix highlighting for "Add untracked" as well.
  Highlight keyboard shortcuts in git-add--interactive
  Document all help keys in "git add -i" patch mode.
  Add "--patch" option to git-add--interactive
  add -i: Fix running from a subdirectory
  builtin-add: fix command line building to call interactive
  git-add -i: allow multiple selection in patch subcommand
  Add path-limiting to git-add--interactive
  Teach builtin-add to pass multiple paths to git-add--interactive

Merge branch 'kh/commit'

* kh/commit: (33 commits)
  git-commit --allow-empty
  git-commit: Allow to amend a merge commit that does not change the tree
  quote_path: fix collapsing of relative paths
  Make git status usage say git status instead of git commit
  Fix --signoff in builtin-commit differently.
  git-commit: clean up die messages
  Do not generate full commit log message if it is not going to be used
  Remove git-status from list of scripts as it is builtin
  Fix off-by-one error when truncating the diff out of the commit message.
  builtin-commit.c: export GIT_INDEX_FILE for launch_editor as well.
  Add a few more tests for git-commit
  builtin-commit: Include the diff in the commit message when verbose.
  builtin-commit: fix partial-commit support
  Fix add_files_to_cache() to take pathspec, not user specified list of files
  Export three helper functions from ls-files
  builtin-commit: run commit-msg hook with correct message file
  builtin-commit: do not color status output shown in the message template
  file_exists(): dangling symlinks do exist
  Replace "runstatus" with "status" in the tests
  t7501-commit: Add test for git commit <file> with dirty index.
  ...

Merge branch 'sp/refspec-match'

* sp/refspec-match:
  refactor fetch's ref matching to use refname_match()
  push: use same rules as git-rev-parse to resolve refspecs
  add refname_match()
  push: support pushing HEAD to real branch name

Simplify crud() in ident.c

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Do not rely on the exit status of "unset" for unset variables

POSIX says that exit status "0" means that "unset" successfully unset
the variable.  However, it is kind of ambiguous if an environment
variable which was not set could be successfully unset.

At least the default shell on HP-UX insists on reporting an error in
such a case, so just ignore the exit status of "unset".

[Dscho: extended the patch to git-submodule.sh, as Junio realized that
 this is the only other place where we check the exit status of "unset".]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: use Perl built-in utf8 function for UTF-8 decoding.

Signed-off-by: İsmail Dönmez <ismail@pardus.org.tr>
Tested-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9600: require cvsps 2.1 to perform tests

git-cvsimport won't run at all with less than cvsps 2.1, because it
lacks the -A flag. But there's no point in preventing people who have an
old cvsps from running the full testsuite.

Tested-by: A Large Angry SCM <gitzilla@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

contrib: Make remotes2config.sh script more robust

The remotes2config.sh script replaced all 'unsafe' characters in repo
name with '.'; include '-' in the 'safe' characters set (the set is
probably even larger).

Script required also space after "URL:", "Push:" and "Pull:" in
remotes file. This for example made the following remote
  URL: git://git.kernel.org/pub/scm/git/git.git
  Pull: refs/heads/master:refs/heads/origin
  Pull:+refs/heads/pu:refs/heads/pu
miss 'pu' branch (forced branch) in config file after conversion.
Allow for any number of whitespace after "URL:", "Push:", "Pull:".

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Use a strbuf for copying the command line for the reflog.

Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/git.txt: typofix

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

Documentation: rerere is enabled by default these days.

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

Formatting fix for Documentation/git-help.txt

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

Update draft release notes for 1.5.4

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

Allow ':/<oneline-prefix>' syntax to work with save_commit_buffer == 0

Earlier, ':/<oneline-prefix>' would not work (i.e. die) with commands that
set save_commit_buffer = 0, such as blame, describe, pack-objects, reflog
and bundle.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add git-fast-export to list of commands.

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

fast-export: rename the signed tag mode 'ignore' to 'verbatim'

The name 'verbatim' describes much better what this mode does with
signed tags.  While at it, fix the documentation what it actually
does.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add remote.<name>.proxy

As well as allowing a default http.proxy option, allow it to be set
per-remote.

Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Allow HTTP proxy to be overridden in config

The http_proxy / HTTPS_PROXY variables used by curl to control
proxying may not be suitable for git.  Allow the user to override them
in the configuration file.

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

Trace and quote with argv: get rid of unneeded count argument.

Now that str_buf takes care of all the allocations, there is
no more gain to pass an argument count.

So this patch removes the "count" argument from:
- "sq_quote_argv"
- "trace_argv_printf"
and all the callers.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

install-sh from automake does not like -m without delimiting space

The install-sh script as shipped with automake requires a space between
the -m switch and its argument.  Since this is also the regular way of
doing it with other install implementations this change inserts the
missing space in all makefiles.

Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: add a new man page for "git-help"

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-commit documentation: fix unfinished sentence.

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

git-add -i: add help text for list-and-choose UI

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

git-commit --allow-empty

It does not usually make sense to record a commit that has the exact
same tree as its sole parent commit and that is why git-commit prevents
you from making such a mistake, but when data from foreign scm is
involved, it is a different story.  We are equipped to represent such an
(perhaps insane, perhaps by mistake, or perhaps done on purpose) empty
change, and it is better to represent it bypassing the safety valve for
native use.

This is primarily for use by foreign scm interface scripts.

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

git-commit --allow-empty

It does not usually make sense to record a commit that has the exact
same tree as its sole parent commit and that is why git-commit prevents
you from making such a mistake, but when data from foreign scm is
involved, it is a different story.  We are equipped to represent such an
(perhaps insane, perhaps by mistake, or perhaps done on purpose) empty
change, and it is better to represent it bypassing the safety valve for
native use.

This is primarily for use by foreign scm interface scripts.

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

git-commit: Allow to amend a merge commit that does not change the tree

Normally, it should not be allowed to generate an empty commit. A merge
commit generated with git 'merge -s ours' does not change the tree (along
the first parent), but merges are not "empty" even if they do not change
the tree. Hence, commit 8588452ceb7 allowed to amend a merge commit that
does not change the tree, but 4fb5fd5d301 disallowed it again in an
attempt to avoid that an existing commit is amended such that it becomes
empty. With this change, a commit can be edited (create a new one or amend
an existing one) either if there are changes or if there are at least two
parents.

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

git-commit: Allow to amend a merge commit that does not change the tree

Normally, it should not be allowed to generate an empty commit. A merge
commit generated with git 'merge -s ours' does not change the tree (along
the first parent), but merges are not "empty" even if they do not change
the tree. Hence, we should be careful not to forbid this case.

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

quote_path: fix collapsing of relative paths

The code tries to collapse identical leading components
between the prefix and the path. So if we're in "dir1", the
path "dir1/file" should become just "file". However, we were
ending up with "../dir1/file". The included test expected
the wrong output.

The "len" parameter to quote_path can be negative to mean
"this is a NUL terminated string".  Simply count it so that
the loop can rely on it being the length of the path.

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

Make git status usage say git status instead of git commit

git status shares the same usage information as git commit since it
shows what would be committed if the same options are given.  However,
when displaying the usage information for git status it should say it
is for git status not git commit.

Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix --signoff in builtin-commit differently.

Introduce fmt_name() specifically meant for formatting the name and
email pair, to add signed-off-by value.  This reverts parts of
13208572fbe8838fd8835548d7502202d1f7b21d (builtin-commit: fix --signoff)
so that an empty datestamp string given to fmt_ident() by mistake will
error out as before.

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

Merge branch 'js/prune-expire'

* js/prune-expire:
  Add "--expire <time>" option to 'git prune'

Merge branch 'js/export-with-assignment'

* js/export-with-assignment:
  Replace instances of export VAR=VAL with VAR=VAL; export VAR

Merge branch 'js/fast-export'

* js/fast-export:
  Add 'git fast-export', the sister of 'git fast-import'

Merge branch 'js/rebase-i-rerere'

* js/rebase-i-rerere:
  rebase -i: give rerere a chance

Merge branch 'js/pull-rebase'

* js/pull-rebase:
  Teach 'git pull' about --rebase

Merge branch 'wc/rebase-insn'

* wc/rebase-insn:
  Mention that git-rm can be an appropriate resolution as well as git-add.
  revert/cherry-pick: Allow overriding the help text by the calling Porcelain

Merge branch 'jc/typebreak'

* jc/typebreak:
  Enable rewrite as well as rename detection in git-status
  rename: Break filepairs with different types.

Enable rewrite as well as rename detection in git-status

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

Merge branch 'jc/color'

* jc/color:
  git-config --get-color: get configured color
  "color.diff = true" is not "always" anymore.

Add 'git fast-export', the sister of 'git fast-import'

This program dumps (parts of) a git repository in the format that
fast-import understands.

For clarity's sake, it does not use the 'inline' method of specifying
blobs in the commits, but builds the blobs before building the commits.

Since signed tags' signatures will not necessarily be valid (think
transformations after the export, or excluding revisions, changing
the history), there are 4 modes to handle them: abort (default),
ignore, warn and strip.  The latter just turns the tags into
unsigned ones.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'dc/gitweb'

* dc/gitweb:
  gitweb: the commitdiff is very commonly used, it's needed on search page, too

gitweb: Update and improve gitweb/README file

Update list of build configuration variables, add references
to gitweb/INSTALL, add description of runtime and per-repository
runtime configuration.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-stash: Display help message if git-stash is run with wrong sub-commands

The current git-stash behaviour is very error prone to typos. For example,
if you typed "git-stash llist", git-stash would think that you wanted to
save to a stash named "llist", but in fact, you meant "git-stash list".

Signed-off-by: Kevin Leung <kevinlsk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-am: catch missing author date early.

Even though commit-tree would default to the current time if the incoming
e-mail message somehow did not record the timestamp, it is safer to catch
the breakage sooner.

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

add -i: allow prefix highlighting for "Add untracked" as well.

These changes make the automatic prefix highlighting work with the "Add
untracked" subcommand in git-add--interactive by explicitly handling
arrays, hashes and strings internally (previously only arrays and hashes
were handled).

In addition, prefixes which have special meaning for list_and_choose
(things like "*" for "all" and "-" for "deselect) are explicitly
excluded (highlighting these prefixes would be misleading).

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  t9600: test cvsimport from CVS working tree

t9600: test cvsimport from CVS working tree

This test passes with v1.5.3.7, but not with v1.5.3.6.

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

gitweb: the commitdiff is very commonly used, it's needed on search page, too

Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rename: Break filepairs with different types.

When we consider if a path has been totally rewritten, we did not
touch changes from symlinks to files or vice versa.  But a change
that modifies even the type of a blob surely should count as a
complete rewrite.

While we are at it, modernise diffcore-break to be aware of gitlinks (we
do not want to touch them).

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

git-commit: clean up die messages

These are three types of cleanups here:

  1. remove newline from die message (die/report adds it
     already)
  2. typo: s/merger/merge/
  3. the old "* no commit message?  aborting commit." is now
     prepended with "fatal: ", making the asterisk look a
     little funny. Let's just remove it.

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

Update draft release notes for 1.5.4

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

Consolidate command list to one.

The categorized list of commands in git(7) and the list of common
commands in "git help" output were maintained separately, which was
insane.  This consolidates them to a single command-list.txt file.

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

Resurrect peek-remote

8951d7c1f1ae38f34617b6c2490bf65e73e371f7 (Build in ls-remote) made
peek-remote as a synonym to ls-remote by enhancing the latter, but
at the same time actually _removed_ it, before we officially gave
removal notice.  This was bad.

Resurrect it for v1.5.4.

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

Merge branch 'tt/help'

* tt/help:
  Remove hint to use "git help -a"
  Make the list of common commands more exclusive

Merge branch 'jc/move-gitk'

* jc/move-gitk:
  Move gitk to its own subdirectory

Merge branch 'jc/branch-contains'

* jc/branch-contains:
  git-branch --contains: doc and test
  git-branch --contains=commit
  parse-options: Allow to hide options from the default usage.

Merge branch 'cr/tag-options'

* cr/tag-options:
  git-tag: test that -s implies an annotated tag
  "git-tag -s" should create a signed annotated tag
  builtin-tag: accept and process multiple -m just like git-commit
  Make builtin-tag.c use parse_options.

Update draft release notes for 1.5.4

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

Merge 1.5.3.7 in

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

GIT 1.5.3.7

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

Fix typo in t4008 test title

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

git-svn: Don't create a "master" branch every time rebase is run

If you run "git-svn rebase" while sitting on a topic branch, there is
no need to create a "master" branch if one didn't exist already. The
branch was created implicitly by the automatic checkout after fetching,
which in the case of rebase isn't actually necessary anyway.

Signed-off-by: Steven Grimm <koreth@midwinter.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: add a show-externals command.

show-externals can be used by scripts to provide svn:externals-like
functionality.  For example, a script can list all of the externals and then
use check out the listed URLs at the appropriate paths, similar to what the svn
client does.  Said script (or perhaps git-svn itself, in the future) could
simply invoke svn export on the paths, or it could go one further, using
git-svn clone and even git-submodule together to better integrate externals
checkouts.

The implementation is shamelessly copied from show-ignores.  A more general
command to list user-specified properties is probably a better idea.

Signed-off-by: Vineet Kumar <vineet@doorstop.net>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: Remove unnecessary Git::SVN::Util package

Digest::MD5 is loaded regardless of the package in which it's
declared, so move its 'use' statement and the md5sum() function
into the main package.

Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: add support for pulling author from From: and Signed-off-by:

Add support for pulling the real author of a commit from the From:
and first Signed-off-by: fields of the SVN commit message.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn now reads settings even if called in subdirectory

Previously, git-svn first read the .git/config file for settings as if
current working directory was the repository top-directory, and after
that made sure to cd into top-directory.  The result was a silent
failur to read configuration settings.  This patch changes the order
these two things are done.

Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Acked-by: Eric Wong <normalperson@yhbt.net>

Merge branch 'maint'

* maint:
  Replace the word 'update-cache' by 'update-index' everywhere
  cvsimport: fix usage of cvsimport.module
  t7003-filter-branch: Fix test of a failing --msg-filter.
  cvsimport: miscellaneous packed-ref fixes
  cvsimport: use rev-parse to support packed refs
  Add basic cvsimport tests

Fix a pathological case in git detecting proper renames

On Thu, 29 Nov 2007, Jeff King wrote:
>
> I think it will get worse, because you are simultaneously calculating
> all of the similarity scores bit by bit rather than doing a loop. Though
> perhaps you mean at the end you will end up with a list of src/dst pairs
> sorted by score, and you can loop over that.

Well, after thinking about this a bit, I think there's a solution that may
work well with the current thing too: instead of looping just *once* over
the list of rename pairs, loop twice - and simply refuse to do copies on
the first loop.

This trivial patch does that, and turns Kumar's test-case into a perfect
rename list.

It's not pretty, it's not smart, but it seems to work. There's something
to be said for keeping it simple and stupid.

And it should not be nearly as expensive as it may _look_. Yes, the loop
is "(i = 0; i < num_create * num_src; i++)", but the important part is
that the whole array is sorted by rename score, and we have a

if (mx[i].score < minimum_score)
break;

in it, so uthe loop actually would tend to terminate rather quickly.

Anyway, Kumar, the thing to take away from this is:

 - git really doesn't even *care* about the whole "rename detection"
   internally, and any commits you have done with renames are totally
   independent of the heuristics we then use to *show* the renames.

 - the rename detection really is for just two reasons: (a) keep humans
   happy, and keep the diffs small and (b) help automatic merging across
   renames. So getting renames right is certainly good, but it's more of a
   "politeness" issue than a "correctness" issue, although the merge
   portion of it does matter a lot sometimes.

 - the important thing here is that you can commit your changes and not
   worry about them being somehow "corrupted" by lack of rename detection,
   even if you commit them with a version of git that doesn't do rename
   detection the way you expected it. The rename detection is an
   "after-the-fact" thing, not something that actually gets saved in the
   repository, which is why we can change the heuristics _after_ seeing
   examples, and the examples magically correct themselves!

 - try out the two patches I've posted, and see if they work for you. They
   pass the test-suite, and the output for your example commit looks sane,
   but hey, if you have other test-cases, try them out.

Here's Kumar's pretty diffstat with both my patches:

 Makefile                                         |    6 +++---
 board/{cds => freescale}/common/cadmus.c         |    0
 board/{cds => freescale}/common/cadmus.h         |    0
 board/{cds => freescale}/common/eeprom.c         |    0
 board/{cds => freescale}/common/eeprom.h         |    0
 board/{cds => freescale}/common/ft_board.c       |    0
 board/{cds => freescale}/common/via.c            |    0
 board/{cds => freescale}/common/via.h            |    0
 board/{cds => freescale}/mpc8541cds/Makefile     |    0
 board/{cds => freescale}/mpc8541cds/config.mk    |    0
 board/{cds => freescale}/mpc8541cds/init.S       |    0
 board/{cds => freescale}/mpc8541cds/mpc8541cds.c |    0
 board/{cds => freescale}/mpc8541cds/u-boot.lds   |    4 ++--
 board/{cds => freescale}/mpc8548cds/Makefile     |    0
 board/{cds => freescale}/mpc8548cds/config.mk    |    0
 board/{cds => freescale}/mpc8548cds/init.S       |    0
 board/{cds => freescale}/mpc8548cds/mpc8548cds.c |    0
 board/{cds => freescale}/mpc8548cds/u-boot.lds   |    4 ++--
 board/{cds => freescale}/mpc8555cds/Makefile     |    0
 board/{cds => freescale}/mpc8555cds/config.mk    |    0
 board/{cds => freescale}/mpc8555cds/init.S       |    0
 board/{cds => freescale}/mpc8555cds/mpc8555cds.c |    0
 board/{cds => freescale}/mpc8555cds/u-boot.lds   |    4 ++--
 23 files changed, 9 insertions(+), 9 deletions(-)

and here it is before:

 Makefile                                           |    6 +-
 board/cds/mpc8548cds/Makefile                      |   60 -----
 board/cds/mpc8555cds/Makefile                      |   60 -----
 board/cds/mpc8555cds/init.S                        |  255 --------------------
 board/cds/mpc8555cds/u-boot.lds                    |  150 ------------
 board/{cds => freescale}/common/cadmus.c           |    0
 board/{cds => freescale}/common/cadmus.h           |    0
 board/{cds => freescale}/common/eeprom.c           |    0
 board/{cds => freescale}/common/eeprom.h           |    0
 board/{cds => freescale}/common/ft_board.c         |    0
 board/{cds => freescale}/common/via.c              |    0
 board/{cds => freescale}/common/via.h              |    0
 board/{cds => freescale}/mpc8541cds/Makefile       |    0
 board/{cds => freescale}/mpc8541cds/config.mk      |    0
 board/{cds => freescale}/mpc8541cds/init.S         |    0
 board/{cds => freescale}/mpc8541cds/mpc8541cds.c   |    0
 board/{cds => freescale}/mpc8541cds/u-boot.lds     |    4 +-
 .../mpc8541cds => freescale/mpc8548cds}/Makefile   |    0
 board/{cds => freescale}/mpc8548cds/config.mk      |    0
 board/{cds => freescale}/mpc8548cds/init.S         |    0
 board/{cds => freescale}/mpc8548cds/mpc8548cds.c   |    0
 board/{cds => freescale}/mpc8548cds/u-boot.lds     |    4 +-
 .../mpc8541cds => freescale/mpc8555cds}/Makefile   |    0
 board/{cds => freescale}/mpc8555cds/config.mk      |    0
 .../mpc8541cds => freescale/mpc8555cds}/init.S     |    0
 board/{cds => freescale}/mpc8555cds/mpc8555cds.c   |    0
 .../mpc8541cds => freescale/mpc8555cds}/u-boot.lds |    4 +-
 27 files changed, 9 insertions(+), 534 deletions(-)

so it certainly makes the diffs prettier.

Linus

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

Fix a pathological case in git detecting proper renames

Kumar Gala had a case in the u-boot archive with multiple renames of files
with identical contents, and git would turn those into multiple "copy"
operations of one of the sources, and just deleting the other sources.

This patch makes the git exact rename detection prefer to spread out the
renames over the multiple sources, rather than do multiple copies of one
source.

NOTE! The changes are a bit larger than required, because I also renamed
the variables named "one" and "two" to "target" and "source" respectively.
That makes the logic easier to follow, especially as the "one" was
illogically the target and not the soruce, for purely historical reasons
(this piece of code used to traverse over sources and targets in the wrong
order, and when we fixed that, we didn't fix the names back then. So I
fixed them now).

The important part of this change is just the trivial score calculations
for when files have identical contents:

/* Give higher scores to sources that haven't been used already */
score = !source->rename_used;
score += basename_same(source, target);

and when we have multiple choices we'll now pick the choice that gets the
best rename score, rather than only looking at whether the basename
matched.

It's worth noting a few gotchas:

 - this scoring is currently only done for the "exact match" case.

   In particular, in Kumar's example, even after this patch, the inexact
   match case is still done as a copy+delete rather than as two renames:

 delete mode 100644 board/cds/mpc8555cds/u-boot.lds
 copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%)
 rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%)

   because apparently the "cds/mpc8541cds/u-boot.lds" copy looked
   a bit more similar to both end results. That said, I *suspect* we just
   have the exact same issue there - the similarity analysis just gave
   identical (or at least very _close_ to identical) similarity points,
   and we do not have any logic to prefer multiple renames over a
   copy/delete there.

   That is a separate patch.

 - When you have identical contents and identical basenames, the actual
   entry that is chosen is still picked fairly "at random" for the first
   one (but the subsequent ones will prefer entries that haven't already
   been used).

   It's not actually really random, in that it actually depends on the
   relative alphabetical order of the files (which in turn will have
   impacted the order that the entries got hashed!), so it gives
   consistent results that can be explained. But I wanted to point it out
   as an issue for when anybody actually does cross-renames.

   In Kumar's case the choice is the right one (and for a single normal
   directory rename it should always be, since the relative alphabetical
   sorting of the files will be identical), and we now get:

 rename board/{cds => freescale}/mpc8541cds/init.S (100%)
 rename board/{cds => freescale}/mpc8548cds/init.S (100%)

   which is the "expected" answer. However, it might still be better to
   change the pedantic "exact same basename" on/off choice into a more
   graduated "how similar are the pathnames" scoring situation, in order
   to be more likely to get the exact rename choice that people *expect*
   to see, rather than other alternatives that may *technically* be
   equally good, but are surprising to a human.

It's also unclear whether we should consider "basenames are equal" or
"have already used this as a source" to be more important. This gives them
equal weight, but I suspect we might want to just multiple the "basenames
are equal" weight by two, or something, to prefer equal basenames even if
that causes a copy/delete pair. I dunno.

Anyway, what I'm just saying in a really long-winded manner is that I
think this is right as-is, but it's not the complete solution, and it may
want some further tweaking in the future.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add "--expire <time>" option to 'git prune'

Earlier, 'git prune' would prune all loose unreachable objects.
This could be quite dangerous, as the objects could be used in
an ongoing operation.

This patch adds a mode to expire only loose, unreachable objects
which are older than a certain time.  For example, by

git prune --expire 14.days

you can prune only those objects which are loose, unreachable
and older than 14 days (and thus probably outdated).

The implementation uses st.st_mtime rather than st.st_ctime,
because it can be tested better, using 'touch -d <time>' (and
omitting the test when the platform does not support that
command line switch).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Replace the word 'update-cache' by 'update-index' everywhere

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Do check_repository_format() early

Repository version check is only performed when
setup_git_directory() is called. This makes sure
setup_git_directory_gently() does the check too.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cvsimport: fix usage of cvsimport.module

There were two problems:

  1. We only look at the config variable if there is no module
     given on the command line. We checked this by comparing
     @ARGV == 0. However, at the time of the comparison, we
     have not yet parsed the dashed options, meaning that
     "git cvsimport" would read the variable but "git
     cvsimport -a" would not. This is fixed by simply moving
     the check after the call to getopt.

  2. If the config variable did not exist, we were adding an
     empty string to @ARGV. The rest of the script, rather
     than barfing for insufficient input, would then try to
     import the module '', leading to rather confusing error
     messages. Based on patch from Emanuele Giaquinta.

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

receive-pack: allow deletion of corrupt refs

Occasionally, in some setups (*cough* forks on repo.or.cz *cough*) some
refs go stale, e.g. when the forkee rebased and lost some objects needed
by the fork.  The quick & dirty way to deal with those refs is to delete
them and push them again.

However, git-push first would first fetch the current commit name for the
ref, would receive a null sha1 since the ref does not point to a valid
object, then tell receive-pack that it should delete the ref with this
commit name.  delete_ref() would be subsequently be called, and check that
resolve_ref() (which does _not_ check for validity of the object) returns
the same commit name.  Which would fail.

The proper fix is to avoid corrupting repositories, but in the meantime
this is a good fix in any case.

Incidentally, some instances of "cd .." in the test cases were fixed, so
that subsequent test cases run in t/trash/ irrespective of the outcome of
the previous test cases.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jk/maint-cvsimport-fix' into maint

* jk/maint-cvsimport-fix:
  cvsimport: miscellaneous packed-ref fixes
  cvsimport: use rev-parse to support packed refs
  Add basic cvsimport tests

t7003-filter-branch: Fix test of a failing --msg-filter.

The test passed for the wrong reason: If the script given to --msg-filter
fails, it is expected that git-filter-branch aborts. But the test forgot
to tell the branch name to rewrite, and so git-filter-branch failed due to
incorrect usage.

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

Mention that git-rm can be an appropriate resolution as well as git-add.

Especially when using git-cherry-pick, removing files that are unmerged can be
a logical action. This patch merely changes the informative text to be less
confusing.

Signed-off-by: David Symonds <dsymonds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revert/cherry-pick: Allow overriding the help text by the calling Porcelain

A Porcelain command that uses cherry-pick or revert may make a commit
out of resolved index itself, in which case telling the user to commit
the result is not appropriate at all.  This allows GIT_CHERRY_PICK_HELP
environment variable to be set by the calling Porcelain in order to
override the built-in help text.

[jc: this is heavily modified from the original but should be equivalent
 in spirit]

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

Add config_int() method to the Git perl module

Integer variables can have optional 'k', 'm' or 'g' suffix.
config_int() method will return simple decimal number, taking
care of those suffixes.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Error out when user doesn't have access permission to the repository

Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>

Highlight keyboard shortcuts in git-add--interactive

The user interface provided by the command loop in git-add--interactive
gives the impression that subcommands can only be launched by entering
an integer identifier from 1 through 8.

A "hidden" feature is that any string can be entered, and a regex search
anchored at the beginning of the string is used to find the uniquely
matching option.

This patch makes this feature a little more obvious by highlighting the
first character of each subcommand (for example "patch" is displayed as
"[p]atch").

A new function is added to detect the shortest unique prefix and this
is used to decide what to highlight. Highlighting is also applied when
choosing files.

In the case where the common prefix may be unreasonably large
highlighting is omitted; in this patch the soft limit (above which the
highlighting will be omitted for a particular item) is 0 (in other words,
there is no soft limit) and the hard limit (above which highlighting will
be omitted for all items) is 3, but this can be tweaked.

The actual highlighting is done by the highlight_prefix function, which
will enable us to implement ANSI color code-based highlighting (most
likely using underline or boldface) in the future.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

per-directory-exclude: lazily read .gitignore files

Operations that walk directories or trees, which potentially need to
consult the .gitignore files, used to always try to open the .gitignore
file every time they entered a new directory, even when they ended up
not needing to call excluded() function to see if a path in the
directory is ignored.  This was done by push/pop exclude_per_directory()
functions that managed the data in a stack.

This changes the directory walking API to remove the need to call these
two functions.  Instead, the directory walk data structure caches the
data used by excluded() function the last time, and lazily reuses it as
much as possible.  Among the data the last check used, the ones from
deeper directories that the path we are checking is outside are
discarded, data from the common leading directories are reused, and then
the directories between the common directory and the directory the path
being checked is in are checked for .gitignore file.  This is very
similar to the way gitattributes are handled.

This API change also fixes "ls-files -c -i", which called excluded()
without setting up the gitignore data via the old push/pop functions.

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

dir.c: minor clean-up

Replace handcrafted reallocation with ALLOC_GROW().
Reindent "file_exists()" helper function.

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

rebase -i: give rerere a chance

Like non-interactive rebase, interactive mode now calls rerere when
appropriate.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-config --get-color: get configured color

This new option allows scripts to grab color setting from the user
configuration, translated to ANSI color escape sequence.

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

"color.diff = true" is not "always" anymore.

Too many people got burned by setting color.diff and color.status to
true when they really should have set it to "auto".

This makes only "always" to do the unconditional colorization, and
change the meaning of "true" to the same as "auto": colorize only when
we are talking to a terminal.

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

Teach 'git pull' about --rebase

When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + merge.

This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted and needs to be update.

fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
repository, such as WINE's.

As a convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool.  This setting can be overridden on the command
line by --rebase and --no-rebase.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Replace instances of export VAR=VAL with VAR=VAL; export VAR

It might be POSIX, but there are shells that do not like the
expression 'export VAR=VAL'.  To be on the safe side, rewrite them
into 'VAR=VAL' and 'export VAR'.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  scripts: do not get confused with HEAD in work tree
  Improve description of git-branch -d and -D in man page.

scripts: do not get confused with HEAD in work tree

When you have a file called HEAD in your work tree, many commands that
our scripts feed "HEAD" to would complain about the rev vs path
ambiguity.  A solution is to form command line more carefully by
appending -- to them, which makes it clear that we mean HEAD rev not
HEAD file.

This patch would apply to maint.

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