tokkee.org

receive-pack: Send hook output over side band #2

If the client requests to enable side-band-64k capability we can
safely send any hook stdout or stderr data down side band #2,
so the client can present it to the user.

If side-band-64k isn't enabled, hooks continue to inherit stderr
from the parent receive-pack process.

When the side band channel is being used the push client will wind up
prefixing all server messages with "remote: ", just like fetch does,
so our test vector has to be updated with the new expected output.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

receive-pack: Wrap status reports inside side-band-64k

If the client requests the side-band-64k protocol capability we
now wrap the status report data inside of packets sent to band #1.
This permits us to later send additional progress or informational
messages down band #2.

If side-band-64k was enabled, we always send a final flush packet
to let the client know we are done transmitting.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

receive-pack: Refactor how capabilities are shown to the client

Moving capability advertisement into the packet_write call itself
makes it easier to add additional capabilities to the list, be
it optional by configuration, or always present in the protocol.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-pack: demultiplex a sideband stream with status data

If the server advertises side-band-64k capability, we request
it and pull the status report data out of side band #1, and let
side band #2 go to our stderr.  The latter channel be used by the
remote side to send our user messages.  This basically mirrors the
side-band-64k capability in upload-pack.

Servers may choose to use side band #2 to send error messages from
hook scripts that are meant for the push end user.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

run-command: support custom fd-set in async

This patch adds the possibility to supply a set of non-0 file
descriptors for async process communication instead of the
default-created pipe.

Additionally, we now support bi-directional communiction with the
async procedure, by giving the async function both read and write
file descriptors.

To retain compatiblity and similar "API feel" with start_command,
we require start_async callers to set .out = -1 to get a readable
file descriptor.  If either of .in or .out is 0, we supply no file
descriptor to the async process.

[sp: Note: Erik started this patch, and a huge bulk of it is
     his work.  All bugs were introduced later by Shawn.]

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

run-command: Allow stderr to be a caller supplied pipe

Like .out, .err may now be set to a file descriptor > 0, which
is a writable pipe/socket/file that the child's stderr will be
redirected into.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update git fsck --full short description to mention packs

The '--full' option to git fsck does two things:

  1) Check objects in packs
  2) Check alternate objects

This is documented in the git fsck manual; this patch reflects that in
the short git fsck option help message as well.

Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/maint-limit-note-output' into maint

* jc/maint-limit-note-output:
  Fix "log --oneline" not to show notes
  Fix "log" family not to be too agressive about showing notes

Merge branch 'maint-1.6.5' into maint

* maint-1.6.5:
  fix memcpy of overlapping area

fix memcpy of overlapping area

Caught by valgrind in t5500, but it is pretty obvious from
reading the code that this is shifting elements of an array
to the left, which needs memmove.

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

bash: don't offer remote transport helpers as subcommands

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: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint' of git://git.spearce.org/git-gui into maint

* '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

git-gui: work from the .git dir

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: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Fix applying a line when all following lines are deletions

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: Jeff Epler <jepler@unpythonic.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Correct file_states when unstaging partly staged entry

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: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Fix gitk for branch whose name matches local file

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: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Keep repo_config(gui.recentrepos) and .gitconfig in sync

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=362
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: handle really long error messages in updateindex.

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: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

ignore duplicated slashes in make_relative_path()

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

merge-recursive: do not return NULL only to cause segfault

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

retry request without query when info/refs?query fails

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: Tay Ray Chuan <rctay89@gmail.com>
Reported-and-tested-by: Yaroslav Halchenko <debian@onerussian.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix "log --oneline" not to show notes

This option should be treated pretty much the same as --format="%h %s".

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

Merge branch 'jc/maint-refresh-index-is-optional-for-status' into maint

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

Fix "log" family not to be too agressive about showing notes

Giving "Notes" information in the default output format of "log" and
"show" is a sensible progress (the user has asked for it by having the
notes), but for some commands (e.g. "format-patch") spewing notes into the
formatted commit log message without being asked is too aggressive.

Enable notes output only for "log", "show", "whatchanged" by default and
only when the user didn't ask any specific --pretty/--format from the
command line; users can explicitly override this default with --show-notes
and --no-notes option.

Parts of tests are taken from Jeff King's fix.

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

Git 1.6.6.1

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

Merge branch 'bg/maint-remote-update-default' into maint

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

Merge branch 'sb/maint-octopus' into maint

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

Conflicts:
git-merge-octopus.sh

Merge branch 'bg/maint-add-all-doc' into maint

* 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

Merge branch 'maint-1.6.5' into maint

* 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

Git 1.6.5.8

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

Merge branch 'jk/maint-1.6.5-reset-hard' into maint-1.6.5

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

Merge branch 'tr/maint-1.6.5-bash-prompt-show-submodule-changes' into maint-1.6.5

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

Merge branch 'dp/maint-1.6.5-fast-import-non-commit-tag' into maint-1.6.5

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

Merge branch 'jm/maint-1.6.5-grep-NUL-terminate' into maint-1.6.5

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

status: don't require the repository to be writable

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

bisect: fix singular/plural grammar nit

Remove the trailing 's' from "revisions" and "steps" when there is
only one.

Signed-off-by: David Ripton <dripton@ripton.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.4' into maint-1.6.5

* 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

Merge branch 'maint-1.6.3' into maint-1.6.4

* 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

Merge branch 'maint-1.6.2' into maint-1.6.3

* 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

Merge commit 'v1.6.4.4-8-g8de6518' into maint-1.6.4

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

Fix mis-backport of t7002

The original patch that became cfe370c (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: Junio C Hamano <gitster@pobox.com>

Update draft release notes to 1.6.6.1

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

Merge branch 'dp/maint-1.6.5-fast-import-non-commit-tag' into maint

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

Merge branch 'jm/maint-1.6.5-grep-NUL-terminate' into maint

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

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: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix uninitialized variable in get_refs_via_rsync().

This fixes a crash when cloning via rsync://.

Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Document git-blame triple -C option

Lift the explanation of -CCC option in the source to the documentation.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fast-import: tag may point to any object type

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: Dmitry Potapov <dpotapov@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote-curl: Fix Accept header for smart HTTP connections

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

grep: -L should show empty files

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

rebase--interactive: Ignore comments and blank lines in peek_next_command

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: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.2' into maint

* 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

Conflicts:
diff.c

Merge branch 'maint-1.6.1' into maint-1.6.2

* maint-1.6.1:
  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

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  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".

base85: Make the code more obvious instead of explaining the non-obvious

Here is another cleanup ...

Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

base85: encode_85() does not use the decode table

Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

base85 debug code: Fix length byte calculation

Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: tiny git config manual tweaks

As a verb, 'setup' is spelled 'set up'.  “diff commands such as
diff-files” scans better without a comma.  Clarify that shallow
and deep are special non-boolean values for format.thread rather
than boolean values with some other name.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: git gc packs refs by default now

In commit 56752391 (Make "git gc" pack all refs by default,
2007-05-24), 'git gc' was changed to run pack-refs by default

Versions before v1.5.1.2 cannot clone repos with packed refs over
http, and versions before v1.4.4 cannot handled packed refs at
all, but more recent git should have no problems.  Try to make
this more clear in the git-config manual.

The analagous passage in git-gc.txt was updated already with
commit fe2128a (Change git-gc documentation to reflect
gc.packrefs implementation., 2008-01-09).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-rm doc: Describe how to sync index & work tree

Newcomers to git that want to remove from the index only the
files that have disappeared from the working tree will probably
look for a way to do that in the documentation for 'git rm'.

Therefore, describe how that can be done (even though it involves
other commands than 'git rm'). Based on a suggestion by Junio,
but re-arranged and rewritten to better fit into the style of
command reference.

While at it, change a single occurrence of "work tree" to "working
tree" for consistency.

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout -m: do not try to fall back to --merge from an unborn branch

If switching from an unborn branch (= empty tree) to a valid commit failed
without -m, it would fail with -m option as well.

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

git-gui: Add hotkeys for "Unstage from commit" and "Revert changes"

Signed-off-by: Vitaly _Vi Shukela <public_vi@tut.by>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Makefile: consolidate .FORCE-* targets

Providing multiple targets to force a rebuild is unnecessary
complication.

Avoid using a name that could conflict with future special
targets in GNU make (a leading period followed by uppercase
letters).

Cc: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

stash: mention --patch in usage string.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  branch: die explicitly why when calling "git branch [-a|-r] branchname".

branch: die explicitly why when calling "git branch [-a|-r] branchname".

The -a and -r options used to be silently ignored in such a command.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fast-import: Document author/committer/tagger name is optional

The fast-import parser does not validate that the author, committer
or tagger name component contains both a name and an email address.
Therefore the name component has always been optional.  Correct the
documentation to match the implementation.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

SubmittingPatches: hints to know the status of a submitted patch.

"What happened to my patch" is pretty much a FAQ on the Git mailing list,
it deserves a few paragraphs in SubmittingPatches...

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bash completion: factor submodules into dirty state

In the implementation of GIT_PS1_SHOWDIRTYSTATE in 738a94a (bash:
offer to show (un)staged changes, 2009-02-03), I cut&pasted the
git-diff invocations from dirty-worktree checks elsewhere, carrying
along the --ignore-submodules option.

As pointed out by Kevin Ballard, this doesn't really make sense: to
the _user_, a changed submodule counts towards uncommitted changes.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix "git remote update" with remotes.defalt set

Starting from commit 8db35596, "git remote update" (with no
group name given) will fail with the following message if
remotes.default has been set in the config file:

fatal: 'default' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

The problem is that the --multiple option is not passed to
"git fetch" if no remote or group name is given on the command
line. Fix the problem by always passing the --multiple
option to "git fetch" (which actually simplifies the code).

Reported-by: YONETANI Tomokazu
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.1' into maint

* maint-1.6.1:
  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
diff.c

textconv: stop leaking file descriptors

We read the output from textconv helpers over a pipe, but we
never actually closed our end of the pipe after using it.

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

reset: unbreak hard resets with GIT_WORK_TREE

Commit 952dfc6 tried to tighten the safety valves for doing
a "reset --hard" in a bare repository or outside the work
tree, but accidentally broke the case for GIT_WORK_TREE.
This patch unbreaks it.

Most git commands which need a work tree simply use
NEED_WORK_TREE in git.c to die before they get to their
cmd_* function. Reset, however, only needs a work tree in
some cases, and so must handle the work tree itself. The
error that 952dfc6 made was to simply forbid certain
operations if the work tree was not set up; instead, we need
to do the same thing that NEED_WORK_TREE does, which is to
call setup_work_tree(). We no longer have to worry about dying
in the non-worktree case, as setup_work_tree handles that
for us.

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

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  commit: --cleanup is a message option
  t7102: make the test fail if one of its check fails

commit: --cleanup is a message option

In the usage message for "git commit", the --cleanup option appeared
at the end, as one of the "contents options":

usage: git commit [options] [--] <filepattern>...
...
Commit message options
...
Commit contents options
...
    --allow-empty         ok to record an empty change
    --cleanup <default>   how to strip spaces and #comments from message

This is confusing, in part because it makes it ambiguous whether
--allow-empty, just above, refers to an empty diff or an empty message.

Move --cleanup into the 'message options' group.  Also add a pair of
comments to prevent similar oversights in the future.

Signed-off-by: Greg Price <price@ksplice.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git count-objects: handle packs bigger than 4G

Use off_t to count sizes of packs and objects to avoid overflow after
4Gb.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7102: make the test fail if one of its check fails

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

Documentation: always respect core.worktree if set

The value of core.worktree in a ".git/config" is honored even when it
differs from the directory that has the ".git" directory as its
subdirectory.  This is likely to be a misconfiguration, so warn users
about it.  Also, drop the part of the documentation that incorrectly
claimed that we ignore such a misconfigured value.

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

Merge branch 'nf/maint-fix-index-ext-len-on-be64' into maint

* nf/maint-fix-index-ext-len-on-be64:
  read_index(): fix reading extension size on BE 64-bit archs

read_index(): fix reading extension size on BE 64-bit archs

On big endian platforms with 8-byte unsigned long, the code reads the
size of the index extension section (which is a 4-byte network byte
order integer) incorrectly.

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

Makefile: FreeBSD (both 7 and 8) needs OLD_ICONV

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

Start 1.6.6.X maintenance track

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

Merge branch 'jc/maint-obsd46' into maint

* jc/maint-obsd46:
  t4019 "grep" portability fix
  t1200: work around a bug in some implementations of "find"

Add git-http-backend to command-list.

Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t4019 "grep" portability fix

Input to "grep" is supposed to be "text", but we deliberately feed output
from "git diff --color" to sift it into two sets of lines (ones with
errors, the other without).  Some implementations of "grep" only report
matches with the exit status, without showing the matched lines in their
output (e.g. OpenBSD 4.6, which says "Binary file .. matches").

Fortunately, "grep -a" is often a way to force the command to treat its
input as text.

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

t1200: work around a bug in some implementations of "find"

"find path ..." command should exit with zero status only when all path
operands were traversed successfully.  When a non-existent path is given,
however, some implementations of "find" (e.g. OpenBSD 4.6) exit with zero
status and break the last test in t1200.

Rewrite the test to check that there is no regular files in the objects
fan-out directories to work around this bug; it is closer to what we are
testing anyway.

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

Git 1.6.6

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

git svn: add test for a git svn gc followed by a git svn mkdirs

git svn gc will compress the unhandled.log files that git svn mkdirs reads,
causing git svn mkdirs to skip directory creation.

[ew: trivial whitespace cleanups]
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>

git svn: branch/tag commands detect username in URLs

svn+ssh:// repositories often have userinfo embedded in the URL
which were stripped out of the "git-svn-id:" trailers.  Since
the SVN::Client::copy function takes userinfo into account when
matching URLs for SVN repositories, we need to retrieve the full
URL with embedded userinfo in it to avoid mismatched URLs.

Tested-by: Florian Köberle <florian@fkoeberle.de>
Signed-off-by: Eric Wong <normalperson@yhbt.net>

Merge branch 'maint'

* maint:
  Prevent git blame from segfaulting on a missing author name

git svn: lookup new parents correctly from svn:mergeinfo

This appears to be a trivial case where array indices were being
passed to git rev-list, instead of the contents stored in the
array itself.

Signed-off-by: Eric Wong <normalperson@yhbt.net>

Prevent git blame from segfaulting on a missing author name

The human-readable author and committer name can be missing from
commits imported from foreign SCM interfaces.  Make sure we parse
the "author" and "committer" line a bit more leniently and avoid
segfaulting by assuming the name always exists.

Signed-off-by: David Reiss <dreiss@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: Remove obsolete MAXPARENT check

Change git-svn not to impose a limit of 16 parents on a merge.

This limit in git-svn artificially prevents cloning svn repositories
that contain commits with more than 16 merge parents.

The limit was removed from builtin-commit-tree.c for git v1.6.0 in commit
ef98c5cafb3e799b1568bb843fcd45920dc62f16, so there is no need to check for it
it in git-svn.

Signed-off-by: Andrew Myrick <amyrick@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: detect cherry-picks correctly.

The old function was incorrect; in some instances it marks a cherry picked
range as a merged branch (because of an incorrect assumption that
'rev-list COMMIT --not RANGE' would work).  This is replaced with a
function which should detect them correctly, memoized to limit the expense
of dealing with branches with many cherry picks to one 'merge-base' call
per merge, per branch which used cherry picking.

Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: exclude already merged tips using one rev-list call

The old function would have to check all mentioned merge tips, every time
that the mergeinfo ticket changed.  This involved 1-2 rev-list operation
for each listed mergeinfo line.  If there are a lot of feature branches
being merged into a trunk, this makes for a very expensive operation for
detecting the new parents on every merge.

This new version first uses a single 'rev-list' to figure out which commit
ranges are already reachable from the parents.  This is used to eliminate
the already merged branches from the list.

Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: fix some mistakes with interpreting SVN mergeinfo commit ranges

SVN's list of commit ranges in mergeinfo tickets is inclusive, whereas
git commit ranges are exclusive on the left hand side.  Also, the end
points of the commit ranges may not exist; they simply delineate
ranges of commits which may or may not exist.  Fix these two mistakes.

Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: memoize conversion of SVN merge ticket info to git commit ranges

Each time the svn mergeinfo ticket changes, we look it up in the rev_map;
when there are a lot of merged branches, this will result in many repeated
lookups of the same information for subsequent commits.  Arrange the slow
part of the function so that it may be memoized, and memoize it.  The more
expensive revision walking operation can be memoized separately.

[ew: changed "next" to "return" for function exit]

Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: expand the svn mergeinfo test suite, highlighting some failures

As shown, git-svn has some problems; not all svn merges are correctly
detected, and cherry picks may incorrectly be detected as real merges.
These test cases will be marked as _success once the relevant fixes are in.

Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>

update release notes for git svn in 1.6.6

Signed-off-by: Eric Wong <normalperson@yhbt.net>

git svn: fix --revision when fetching deleted paths

When using the -r/--revision argument to fetch deleted history,
calling SVN::Ra::get_log() from an SVN::Ra object initialized
to track the deleted URL will fail.

This regression was introduced in:
  commit 4aacaeb3dc82bb6479e70e120053dc27a399460e
  "fix shallow clone when upstream revision is too new"

We now ignore errors from SVN::Ra::get_log() here because using
--revision will always override the value of $head here if
(and only if) we're tracking deleted directories.

Signed-off-by: Eric Wong <normalperson@yhbt.net>