If the client has requested side-band-64k capability, send any
of the internal error or warning messages in the muxed side-band
stream using the same band as our hook output, band #2. By putting
everything in one stream we ensure all messages are processed by
the side-band demuxer, avoiding interleaving between our own stderr
and the side-band demuxer's stderr buffers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We want to avoid the warnings (or later, test failures) about
updating the current branch. It was never my intention to have
this test deal with a repository with a working directory, and it
is a very old bug that the test even used a non-bare repository
for the remote side of the push operations.
This fixes the interleaved output error we were seeing as a test
failure by avoiding the giant warning message we were getting back
about updating the current branch being risky.
Its not a real fix, but is something we should do no matter what,
because the behavior will change in the future to reject, and the
test would break at that time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* '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: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Shawn 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: Jeff Epler <jepler@unpythonic.net>
Signed-off-by: Shawn 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: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn 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: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Shawn 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=362
Signed-off-by: Shawn 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: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Shawn 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: Junio 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: Junio 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: 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>
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>
* 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
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>
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>
* 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
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>
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>
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>
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>
