If a blob is larger than the configured big-file-threshold, instead
of reading it into a single buffer obtained from malloc, stream it
onto the end of the current pack file.  Streaming the larger objects
into the pack avoids the 4+ GiB memory footprint that occurs when
fast-import is processing 2+ GiB blobs.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since commits a2d725b7 (Use an external program to implement fetching
with curl, 2009-08-05) and c9e388bb (Make the
"traditionally-supported" URLs a special case, 2009-09-03) remote
transport helpers like 'remote-ftp' and 'remote-curl' are offered by the
completion script as available subcommands.  Not good, since they are
helpers, therefore should not be offered, so filter them out.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'maint' of git://git.spearce.org/git-gui:
  git-gui: work from the .git dir
  git-gui: Fix applying a line when all following lines are deletions
  git-gui: Correct file_states when unstaging partly staged entry
  git-gui: Fix gitk for branch whose name matches local file
  git-gui: Keep repo_config(gui.recentrepos) and .gitconfig in sync
  git-gui: handle really long error messages in updateindex.
  git-gui: Add hotkeys for "Unstage from commit" and "Revert changes"
  git-gui: Makefile: consolidate .FORCE-* targets

When git-gui is run from a .git dir, _gitdir would be set to "." by
rev-parse, something that confuses the worktree detection.

Fix by expanding the value of _gitdir to pwd in this special case.
Signed-off-by: NGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If a diff looked like:

 @@
  context
 -del1
 -del2

and you wanted to stage the deletion 'del1', the generated patch
wouldn't apply because it was missing the line 'del2' converted to
context, but this line was counted in the @@-line
Signed-off-by: NJeff Epler <jepler@unpythonic.net>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When unstaging a partly staged file or submodule, the file_states
list was not updated properly (unless unstaged linewise). Its
index_info part did not contain the former head_info as it should
have but kept its old value.

This seems not to have had any bad effects but diminishes the value
of the file_states list for future enhancements.
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When trying to run gitk on a branch name whose name matches a local
file, it will toss an error saying that the name is ambiguous. Adding
a pair of dashes will make gitk parse the options to the left of
it as branch names. Since wish eats the first pair of dashes we
throw at it, we need to add a second one to ensure they get through.
Signed-off-by: NPeter Krefting <peter@softwolves.pp.se>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When the number of recent repo's gets to ten there can be a
situation where an item is removed from the .gitconfig file via
a call to git config --unset, but the internal representation of
that file (repo_config(gui.recentrepo)) is not updated.  Then a
subsequent attempt to remove an item from the list fails because
git-gui attempts to call --unset on a value that has already
been removed.  This leads to duplicates in the .gitconfig file,
which then also cause errors if the git-gui tries to --unset them
(rather than using --unset-all. --unset-all is not used because it
is not expected that duplicates should ever be allowed to exist.)

When loading the list of recent repositories (proc _get_recentrepos)
if a repo in the list is not considered a valid git reposoitory
then we should go ahead and remove it so it doesn't take up a slot
in the list (since we limit to 10 items). This will prevent a bunch
of invalid entries in the list (which are not shown) from making
valid entries dissapear off the list even when there are less than
ten valid entries.

See: http://code.google.com/p/msysgit/issues/detail?id=362Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

As reported to msysGit (bug #340) it is possible to get some very
long error messages when updating the index. The use of a label to
display this prevents scrolling the output. This patch replaces the
label with a scrollable text widget configured to look like a label.
Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The function takes two paths, an early part of abs is supposed to match
base; otherwise abs is not a path under base and the function returns the
full path of abs.  The caller can easily confuse the implementation by
giving duplicated and needless slashes in these path arguments.

Credit for test script, motivation and initial patch goes to Thomas Rast.
A follow-up fix (squashed) is by Hannes.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

merge-recursive calls write_tree_from_memory() to come up with a virtual
tree, with possible conflict markers inside the blob contents, while
merging multiple common ancestors down.  It is a bug to call the function
with unmerged entries in the index, even if the merge to come up with the
common ancestor resulted in conflicts.  Otherwise the result won't be
expressible as a tree object.

We _might_ want to suggest the user to set GIT_MERGE_VERBOSITY to 5 and
re-run the merge in the message.  At least we will know which part of
process_renames() or process_entry() functions is not correctly handling
the unmerged paths, and it might help us diagnosing the issue.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When "info/refs" is a static file and not behind a CGI handler, some
servers may not handle a GET request for it with a query string
appended (eg. "?foo=bar") properly.

If such a request fails, retry it sans the query string. In addition,
ensure that the "smart" http protocol is not used (a service has to be
specified with "?service=<service name>" to be conformant).
Signed-off-by: NTay Ray Chuan <rctay89@gmail.com>
Reported-and-tested-by: NYaroslav Halchenko <debian@onerussian.com>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jc/maint-refresh-index-is-optional-for-status:
  status: don't require the repository to be writable

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

* bg/maint-remote-update-default:
  Fix "git remote update" with remotes.defalt set

* sb/maint-octopus:
  octopus: remove dead code
  octopus: reenable fast-forward merges
  octopus: make merge process simpler to follow

Conflicts:
	git-merge-octopus.sh

* bg/maint-add-all-doc:
  git-rm doc: Describe how to sync index & work tree
  git-add/rm doc: Consistently back-quote
  Documentation: 'git add -A' can remove files

* maint-1.6.5:
  Git 1.6.5.8
  Fix mis-backport of t7002
  bash completion: factor submodules into dirty state
  reset: unbreak hard resets with GIT_WORK_TREE

Conflicts:
	Documentation/git.txt
	GIT-VERSION-GEN
	RelNotes

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

* jk/maint-1.6.5-reset-hard:
  reset: unbreak hard resets with GIT_WORK_TREE

* tr/maint-1.6.5-bash-prompt-show-submodule-changes:
  bash completion: factor submodules into dirty state

* dp/maint-1.6.5-fast-import-non-commit-tag:
  fast-import: tag may point to any object type

* jm/maint-1.6.5-grep-NUL-terminate:
  grep: NUL terminate input from a file

We need to update the index before hooks run when actually making a
commit, but we shouldn't have to write the index when running "status".
If we can, then we have already spent cycles to refresh the index and
it is a waste not to write it out, but it is not a disaster if we cannot
write it out.  The main reason the user is running "git status" is to get
the "status", and refreshing the index is a mere side effect that we can
do without.

Discovery and initial attempted fix by Dscho.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Remove the trailing 's' from "revisions" and "steps" when there is
only one.
Signed-off-by: NDavid Ripton <dripton@ripton.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.6.4:
  Fix mis-backport of t7002
  base85: Make the code more obvious instead of explaining the non-obvious
  base85: encode_85() does not use the decode table
  base85 debug code: Fix length byte calculation
  checkout -m: do not try to fall back to --merge from an unborn branch
  branch: die explicitly why when calling "git branch [-a|-r] branchname".
  textconv: stop leaking file descriptors
  commit: --cleanup is a message option
  git count-objects: handle packs bigger than 4G
  t7102: make the test fail if one of its check fails

* maint-1.6.3:
  base85: Make the code more obvious instead of explaining the non-obvious
  base85: encode_85() does not use the decode table
  base85 debug code: Fix length byte calculation
  checkout -m: do not try to fall back to --merge from an unborn branch
  branch: die explicitly why when calling "git branch [-a|-r] branchname".
  textconv: stop leaking file descriptors
  commit: --cleanup is a message option
  git count-objects: handle packs bigger than 4G
  t7102: make the test fail if one of its check fails

Conflicts:
	builtin-commit.c

* maint-1.6.2:
  base85: Make the code more obvious instead of explaining the non-obvious
  base85: encode_85() does not use the decode table
  base85 debug code: Fix length byte calculation
  checkout -m: do not try to fall back to --merge from an unborn branch
  branch: die explicitly why when calling "git branch [-a|-r] branchname".
  textconv: stop leaking file descriptors
  commit: --cleanup is a message option
  git count-objects: handle packs bigger than 4G
  t7102: make the test fail if one of its check fails

Conflicts:
	diff.c

* commit 'v1.6.4.4-8-g8de65185':
  Fix mis-backport of t7002

The original patch that became cfe370c6 (grep: do not segfault when -f is
used, 2009-10-16), was made against "maint" or newer branch back then, but
the fix addressed the issue that was present as far as in 1.6.4 series.

The maintainer backported the patch to the 1.6.4 maintenance branch, but
failed to notice that the new tests assumed the setup done by the script
in "maint", which did quite a lot more than the same test script in 1.6.4
series, and the output didn't match the expected result.

This should fix it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* dp/maint-1.6.5-fast-import-non-commit-tag:
  fast-import: tag may point to any object type

* jm/maint-1.6.5-grep-NUL-terminate:
  grep: NUL terminate input from a file

Internally "git grep" runs regexec(3) that expects its input string
to be NUL terminated.  When searching inside blob data, read_sha1_file()
automatically gives such a buffer, but builtin-grep.c forgot to put
the NUL at the end, even though it allocated enough space for it.
Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This fixes a crash when cloning via rsync://.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Lift the explanation of -CCC option in the source to the documentation.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If you tried to export the official git repository, and then to import it
back then git-fast-import would die complaining that "Mark :1 not a commit".

Accordingly to a generated crash file, Mark 1 is not a commit but a blob,
which is pointed by junio-gpg-pub tag. Because git-tag allows to create such
tags, git-fast-import should import them.
Signed-off-by: NDmitry Potapov <dpotapov@gmail.com>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We actually expect to see an application/x-git-upload-pack-result
but we lied and said we Accept *-response.  This was a typo on my
part when I was writing the code.

Fortunately the wrong Accept header had no real impact, as the
deployed git-http-backend servers were not testing the Accept
header before they returned their content.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The -L (--files-without-match) option is supposed to show paths that
produced no matches.  When running the internal grep on work tree files,
however, we had an optimization to just return on zero-sized files,
without doing anything.

This optimization doesn't matter too much in practice (a tracked empty
file must be rare, or there is something wrong with your project); to
produce results consistent with GNU grep, we should stop the optimization
and show empty files as not having the given pattern.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Previously, blank lines and/or comments within a series of
squash/fixup commands would confuse "git rebase -i" into thinking that
the series was finished.  It would therefore require the user to edit
the commit message for the squash/fixup commits seen so far.  Then,
after continuing, it would ask the user to edit the commit message
again.

Ignore comments and blank lines within a group of squash/fixup
commands, allowing them to be processed in one go.
Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>