index-pack --strict looks up and follows parent commits. If shallow
information is not ready by the time index-pack is run, index-pack may
be led to non-existent objects. Make fetch-pack save shallow file to
disk before invoking index-pack.
git learns new global option --shallow-file to pass on the alternate
shallow file path. Undocumented (and not even support --shallow-file=
syntax) because it's unlikely to be used again elsewhere.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
file:///path/to/repo.git/ is converted to a hyperlink while others are
not. Put a backslash to avoid the conversion. Tested with asciidoc
8.6.5.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ec55559 (push: Add support for pre-push hooks, 2013-01-13) forgot to
add a note to git-push(1) about the new --no-verify option.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, when no (valid) upstream is configured for a branch, you get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
The "error: " line actually appears twice, and the rest of the error
message is useless. In sha1_name.c:interpret_branch_name(), there is
really no point in processing further if @{u} couldn't be resolved, and
we might as well die() instead of returning an error(). After making
this change, you get:
$ git show @{u}
fatal: No upstream configured for branch 'upstream-error'
Also tweak a few tests in t1507 to expect this output.
This only turns error() that may be called after we know we are
dealing with an @{upstream} marker into die(), without touching
silent error returns "return -1" from the function. Any caller that
wants to handle an error condition itself will not be hurt by this
change, unless they want to see the message from error() and then
exit silently without giving its own message, which needs to be
fixed anyway.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently the __git_ps1 git prompt gives the following error with a
repository converted by git-svn, when used with zsh:
__git_ps1_show_upstream:19: bad pattern: svn_remote[
__git_ps1_show_upstream:45: bad substitution
To reproduce the problem, the __git_ps1_show_upstream function can be
executed in a repository converted with git-svn. Both those errors are
triggered by spaces after the '['.
Zsh also doesn't support initializing an array with `local var=(...)`.
This triggers the following error:
__git_ps1_show_upstream:41: bad pattern: svn_upstream=(commit
Use
local -a
var=(...)
instead to make is compatible.
This was introduced by 6d158cba (bash completion: Support "divergence
from upstream" messages in __git_ps1), when the script was for bash
only.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Acked-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability. Silence the warnings by using Apple's
CommonCrypto HMAC replacement functions.
[es: reworded commit message; check APPLE_COMMON_CRYPTO instead of
abusing COMMON_DIGEST_FOR_OPENSSL]
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The other configurations were added in the wrong place.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Follow the style of the previous configurations.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
zsh completion wrapper doesn't reimplement __gitcompadd(). Although it
should be trivial to do that, let's use __gitcomp_nl() which achieves
exactly the same thing, specially since the suffix ($4) has to be empty.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree:
it's required for systems which don't use bash by default (for example,
FreeBSD), while there seem to be no bashisms in the script (confirmed
by looking through the source and tesing subtree functionality with
FreeBSD's /bin/sh) to require specifically bash and not the generic
posix shell.
Signed-off-by: Dmitry Marakasov <amdmi3@amdmi3.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: introduce --parents parameter for commands branch and tag
git-svn: clarify explanation of --destination argument
git-svn: multiple fetch/branches/tags keys are supported
"diff-index" can be used to compare a tree with the tracked working
tree files (when used without the --index option), or with the index
(when used with the --index option).
The text however did not say anything about the comparison with the
working tree at all. Fix this.
Reported-by: Albert Netymk <albertnetymk@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This parameter is equivalent to the parameter --parents on svn cp commands
and is useful for non-standard repository layouts.
Signed-off-by: Tobias Schulte <tobias.schulte@gliderpilot.de>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The existing documentation for "-d" does not make it obvious whether
its argument is supposed to be a full svn path, a partial svn path,
the glob from the config file, or what. Clarify the text and add an
example to get the reader started.
Reported-by: Nathan Gray <n8gray@n8gray.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
"git svn" can be configured to use multiple fetch, branches, and tags
refspecs by passing multiple --branches or --tags options at init time
or editing the configuration file later, which can be handy when
working with messy Subversion repositories. Add a note to the
configuration section documenting how this works.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git clone hangs on windows, and file.write would return errno 22 inside
of mercurial's windows.winstdout wrapper class. This patch sets stdout's
mode to binary, fixing both issues.
[fc: cleaned up]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability, thus leading to build diagnostics such as:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using Apple's CommonCrypto SHA-1 replacement
functions for SHA1_Init(), SHA1_Update(), and SHA1_Final().
COMMON_DIGEST_FOR_OPENSSL is defined to instruct
<CommonCrypto/CommonDigest.h> to provide compatibility macros
associating OpenSSL SHA-1 functions with their CommonCrypto
counterparts.
[es: reworded commit message]
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability, thus leading to build warnings. As a
replacement, Apple encourages developers to migrate to its own (stable)
CommonCrypto facility.
Introduce boilerplate which controls whether Apple's CommonCrypto
facility is employed (enabled by default). Also add a
NO_APPLE_COMMON_CRYPTO build flag with which the user can opt out to
use OpenSSL instead.
[es: extracted CommonCrypto-related Makefile boilerplate into separate
introductory patch]
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Due to a bug in the Darwin kernel, write(2) calls have a maximum size
of INT_MAX bytes.
Introduce a new compat function, clipped_write(), that only writes
at most INT_MAX bytes and returns the number of bytes written, as
a substitute for write(2), and allow platforms that need this to
enable it from the build mechanism with NEEDS_CLIPPED_WRITE.
Set it for Mac OS X by default. It may be necessary to include this
function on Windows, too.
Signed-off-by: Filipe Cabecinhas <filcab+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
White-spaces, missing braces, standardize --[no-]foo.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 02c5631 (difftool --dir-diff: symlink all files matching the
working tree, 2013-03-14) does not handle the case where a file that is
being compared does not exist in the working tree. Fix this by checking
for existence explicitly before running git-hash-object.
Reported-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Down to v2.0, by using older but still valid interfaces.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It looks like commit f8246281af
unintentionally removed the documentation for the `-e` option.
Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 24317ef32a.
Different versions of Mercurial have different arguments for
bookmarks.updatefromremote(), while it should be possible to call the
right function with the right arguments depending on the version, it's
safer to restore the old behavior for now.
Reported by Rodney Lorrimar.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you were on 'frotz' branch before you checked out your current
branch, "git merge @{-1}~22" means the same as "git merge frotz~22".
The strbuf_branchname() function, when interpret_branch_name() gives
up resolving "@{-1}~22" fully, returns "frotz" and tells the caller
that it only resolved "@{-1}" part of the input, mistakes this as a
total failure, and appends the whole thing to the result, yielding
"frotz@{-1}~22", which does not make any sense.
Inspect the return value from interpret_branch_name() a bit more
carefully. When it errored out without consuming anything, we will
get -1 and we should return the whole thing. Otherwise, we should
append the remainder (i.e. "~22" in the earlier example) to the
partially resolved name (i.e. "frotz").
The test suite adds enough number of checkout to make @{-12} in the
last test in t0100 that tried to check "we haven't flipped branches
that many times" error case succeed; raise the number to a hundred.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe how 'add' sets the submodule's logical name, which is used in
the configuration entry names.
Clarify that 'init' only sets up the configuration entries for
submodules that have already been added elsewhere. Describe that
<path> arguments limit the submodules that are configured.
Signed-off-by: Dale Worley <worley@ariadne.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation assures users that "A...B" is defined as "A B --not
$(git merge-base --all A B)". This wasn't in fact quite true, because
the calculated merge bases were not sent to add_rev_cmdline().
The main effect of this was that although
git rev-list --ancestry-path A B --not $(git merge-base --all A B)
worked, the simpler form
git rev-list --ancestry-path A...B
failed with a "no bottom commits" error.
Other potential users of bottom commits could also be affected by this
problem, if they examine revs->cmdline_info; I came across the issue in
my proposed history traversal refinements series.
So ensure that the calculated merge bases are sent to add_rev_cmdline(),
flagged with new 'whence' enum value REV_CMD_MERGE_BASE.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 95b0c60 (remote-bzr: add support for bzr repos) introduced a
regression by assuming all bzr remote repos are listable, but they are
not.
If they are not listable they are basically useless, so let's assume
there is no bzr repo.
Reported-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise, the user would never ever see new bookmarks, only the
ones that (s)he initially cloned.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We skip it locally, but not for the remote, so let's do so.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In certain situations we might end up pushing garbage revisions
(e.g. in a rebase), and the patches to deal with that haven't been
merged yet. So let's disable forced pushes by default.
We are essentially reverting back to the old v1.8.2 behavior, to
minimize the possibility of regressions, but in a way the user can
configure.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a user creates a new branch with git:
% git checkout -b branches/devel
and then pushes this branch
% git push origin branches/devel
which is the way to push new mercurial branches, we do want to
create a branch, but the command would fail without newbranch=True.
This only matters when force_push=False, but setting newbranch=True
unconditionally does not hurt.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove try/except check because we are no longer calling
check_output(), which may throw an exception.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Drop unused "global", and remove redundant comparison of two files.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a deletion is followed by exactly 3 (or whatever the number of
context lines) unchanged lines, followed by another change, the combined
diff output would hide the first deletion, resulting in a malformed
diff.
This happened because the 3 lines before each change are painted
interesting, but also marked as no_pre_delete to prevent showing deletes
that were previously marked as uninteresting. This behaviour was
introduced in c86fbe53 (diff -c/--cc: do not include uninteresting
deletion before leading context). However, as a side effect, this could
also mark deletes that were already interesting as no_pre_delete. This
would happen only if the delete was exactly 3 lines away from the next
change, since lines farther away would not be touched by the "paint
three lines before the change" code and lines closer would be painted
by the "merge two adjacent hunks" code instead, which does not set the
no_pre_delete flag.
This commit fixes this problem by only setting the no_pre_delete flag
for changes that were previously uninteresting.
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a clone exists with the old organization (v1.8.2) it will prevent
the new shared bzr repository organization from working, so let's
remove this repository, which is not used any more.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://ozlabs.org/~paulus/gitk:
gitk: On OSX, bring the gitk window to front
gitk: Add support for -G'regex' pickaxe variant
gitk: Add menu item for reverting commits
gitk: Simplify file filtering
gitk: Display the date of a tag in a human-friendly way
gitk: Improve behaviour of drop-down lists
gitk: Move hard-coded colors to .gitk
On OSX, Tcl/Tk application windows are created behind all
the applications down the stack of windows. This is very
annoying, because once a gitk window appears, it's the
downmost window and switching to it is pain.
The patch is: if we are on OSX, use osascript to
bring the current Wish process window to front.
Signed-off-by: Tair Sabirgaliev <tair.sabirgaliev@gmail.com>
Thanks-to: Stefan Haller <lists@haller-berlin.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
