* maint:
rebase -i: abort cleanly if the editor fails to launch
technical-docs: document hash API
api-strbuf.txt: fix typos and document launch_editor()
rebase -i: abort cleanly if the editor fails to launch
If the user's configured editor is emacsclient, the editor
will fail to launch if emacs is not running and the git
command that tried to lanuch the editor will abort. For most
commands, all you have to do is to start emacs and repeat
the command.
The "git rebase -i" command, however, aborts without cleaning
the "$GIT_DIR/rebase-merge" directory if it fails to launch the
editor, so you'll need to do "git rebase --abort" before
repeating the rebase command.
Change "git rebase -i" to terminate using "die_abort" (instead of
with "die") if the initial launch of the editor fails.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Git 1.6.5.7
worktree: don't segfault with an absolute pathspec without a work tree
ignore unknown color configuration
help.autocorrect: do not run a command if the command given is junk
Illustrate "filter" attribute with an example
worktree: don't segfault with an absolute pathspec without a work tree
If a command is run with an absolute path as a pathspec inside a bare
repository, e.g. "rev-list HEAD -- /home", the code tried to run strlen()
on NULL, which is the result of get_git_work_tree(), and segfaulted. It
should just fail instead.
Currently the function returns NULL even inside .git/ in a repository
with a work tree, but that is a separate issue.
When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).
The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.
However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.
This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
help.autocorrect: do not run a command if the command given is junk
If a given command is not found, then help.c tries to guess which one the
user could have meant. If help.autocorrect is 0 or unset, then a list of
suggestions is given as long as the dissimilarity between the given command
and the candidates is not excessively high. But if help.autocorrect was
non-zero (i.e., a delay after which the command is run automatically), the
latter restriction on dissimilarity was not obeyed.
In my case, this happened:
$ git ..daab02
WARNING: You called a Git command named '..daab02', which does not exist.
Continuing under the assumption that you meant 'read-tree'
in 4.0 seconds automatically...
The patch reuses the similarity limit that is also applied when the list of
suggested commands is printed.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support the new options --all, --prune, and --dry-run for
'git fetch'.
As the --multiple option was primarily introduced to enable
'git remote update' to be re-implemented in terms of 'git fetch'
(16679e37) and is not likely to be used much from the command
line, it does not seems worthwhile to complicate the code
(to support completion of multiple remotes) to handle it.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Giving --format from the command line, or using output file extention to
DWIM the output format, with a pathspec that is disambiguated with an
explicit double-dash on the command line, e.g.
git archive -o file --format=zip HEAD -- path
git archive -o file.zip HEAD -- path
didn't work correctly.
This was because the code reordered (when one was given) or added (when
the format was inferred) a --format argument at the end, effectively
making it to "archive HEAD -- path --format=zip", i.e. an extra pathspec
that is unlikely to match anything.
The command line argument list should always be "options, revs and then
paths", and we should set a good example by inserting the --format at the
beginning instead.
Reported-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://repo.or.cz/git-gui:
git-gui: suppress RenderBadPicture X error caused by Tk bug
git-gui: Increase blame viewer usability on MacOS.
git-gui: search 4 directories to improve statistic of gc hint
git gui: make current branch default in "remote delete branch" merge check
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix selection of tags
gitk: Default to the system colours on Windows
gitk: Update Japanese translation
gitk: Fix "git gui blame" invocation when called from top-level directory
gitk: Disable checkout of remote branches
gitk: Improve appearance of radiobuttons and checkbuttons
gitk: Skip translation of "wrong Tcl version" message
gitk: Add Japanese translation
gitk: Use the --submodule option for displaying diffs when available
gitk: Fix diffing committed -> staged (typo in diffcmd)
gitk: Add configuration for UI colour scheme
gitk: Don't compare fake children when comparing commits
gitk: Show diff of commits at end of compare-commits output
gitk: Add a user preference to enable/disable use of themed widgets
gitk: Fix errors in the theme patch
gitk: Use themed tk widgets
gitk: Restore scrolling position of diff pane on back/forward in history
Merge branch 'mm/maint-merge-ff-error-message-fix' into maint
* mm/maint-merge-ff-error-message-fix:
builtin-merge: show user-friendly error messages for fast-forward too.
merge-recursive: make the error-message generation an extern function
If a clone errors out because of a missing author, or user interrupt,
this allows `git svn fetch` to resume seamlessly, rather than forcing
the user to re-provide the path to the authors file.
[ew: shortened subject] Signed-off-by: Alex Vandiver <alex@chmrr.net> Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: Set svn.authorsfile to an absolute path when cloning
If --authors-file is passed a relative path, cloning will work, but
future `git svn fetch`es will fail to locate the authors file
correctly. Thus, use File::Spec->rel2abs to determine an absolute
path for the authors file before setting it.
Signed-off-by: Alex Vandiver <alex@chmrr.net> Acked-by: Eric Wong <normalperson@yhbt.net>
They caused a "git pull" (without any arguments, and without any local
commits---only to update to the other side) to warn that commit log
message is ignored because the merge resulted in a fast-forward.
Another possible solution is to add an extra option to "git merge" so that
"git pull" can tell it that the message given is not coming from the end
user (the canned message is passed just in case the merge resulted in a
non-ff and caused commit), but I think it is easier _not_ to deprecate the
old syntax.
Commit 24ab81a fixed the deletion of empty files, but broke
deletion of non-empty files. The approach it took was to
factor out the "deleted" line from the patch header into its
own hunk, the same way we do for mode changes. However,
unlike mode changes, we only showed the special "delete this
file" hunk if there were no other hunks. Otherwise, the user
would annoyingly be presented with _two_ hunks: one for
deleting the file and one for deleting the content.
This meant that in the non-empty case, we forgot about the
deleted line entirely, and we submitted a bogus patch to
git-apply (with "/dev/null" as the destination file, but not
marked as a deletion).
Instead, this patch combines the file deletion hunk and the
content deletion hunk (if there is one) into a single
deletion hunk which is either staged or not.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also adds a test case for:
"git svn: Don't create empty directories whose parents were deleted"
which was the reason we found this bug in the first place.
git svn: Don't create empty directories whose parents were deleted
Commit 6111b93 "git svn: attempt to create empty dirs on clone+rebase"
will create empty directories 'a/b' and 'a/c' if they were previously
created in SVN, even if their parent directory 'a' was deleted.
For example, unhandled.log may contain lines like this:
git-svn: sort svk merge tickets to account for minimal parents
When merging branches based on svk:merge properties, a single merge
can have updated or added multiple svk:merge lines. Attempt to
include the minimal set of parents by sorting the merge properties in
order of revision, highest to lowest.
Signed-off-by: Alex Vandiver <alex@chmrr.net> Acked-by: Sam Vilain <sam@vilain.net> Acked-by: Eric Wong <normalperson@yhbt.net>
git-gui: suppress RenderBadPicture X error caused by Tk bug
Due to a bug in Tk, git-gui almost always (unless git-gui is closed
right after starting) produces an X window error message on exit,
something like:
X Error of failed request: RenderBadPicture (invalid Picture parameter)
Major opcode of failed request: 150 (RENDER)
Minor opcode of failed request: 7 (RenderFreePicture)
Picture id in failed request: 0x3a000dc
Serial number of failed request: 1965
Current serial number in output stream: 1980
This bug is triggered only when the send command is blocked via
rename send {} . The following patch re-enables send just before
quiting git-gui to suppress the error.
Signed-off-by: Jindrich Makovicka <makovick@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I just wanted to add the recently learnt '--reset-author' option, but
then noticed that there are many more options missing. This patch
adds support for all of 'git commit's options, except '--allow-empty',
because it is primarily there for foreign scm interfaces.
Furthermore, this patch also adds support for completing the arguments
of those options that take a non-filename argument: valid modes are
offered for '--cleanup' and '--untracked-files', while refs for
'--reuse-message' and '--reedit-message', because these two take a
commit as argument.
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>
git-gui: Increase blame viewer usability on MacOS.
On MacOS raising a window causes the focus to be transferred
to it -- although it may actually be a bug in the Tcl/Tk port.
When this happens with the blame viewer tooltips, it makes
the interface less usable, because Entry and Leave handlers
on the text view cause the tip to disappear once the mouse
is moved even 1 pixel.
This commit makes the code raise the main window on MacOS
when Tk 8.5 is used. This version seems to properly support
wm transient by making the tip stay on top of the master,
so reraising the master does not cause it to disappear. Thus
the only remaining sign of problems is slight UI flicker
when focus is momentarily transferred to the tip and back.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: search 4 directories to improve statistic of gc hint
On Windows, git-gui suggests running the garbage collector if it finds
1 or more files in .git/objects/42 (as opposed to 8 files on other
platforms). The probability of that happening if the repo contains
about 100 loose objects is 32%. The probability for the same to happen
when searching 4 directories is only 8%, which is bit more reasonable.
Also remove $objects_limit from the message, because we already know
that we are above (or close to) that limit. Telling the user about
that number does not really give him any useful information.
The following octave script shows the probability for at least m*q
objects to be found in q subdirectories of .git/objects if n is the
total number of objects.
q = 4;
m = [1 2 8];
n = 0:10:2000;
P = zeros(length(n), length(m));
for k = 1:length(n)
P(k, :) = 1-binocdf(q*m-1, n(k), q/(256-q));
end
plot(n, P);
Fix diff -B/--dirstat miscounting of newly added contents
What used to happen is that diffcore_count_changes() simply ignored any
hashes in the destination that didn't match hashes in the source. EXCEPT
if the source hash didn't exist at all, in which case it would count _one_
destination hash that happened to have the "next" hash value. As a
consequence, newly added material was often undercounted, making output
from --dirstat and "complete rewrite" detection used by -B unrelialble.
This changes it so that:
- whenever it bypasses a destination hash (because it doesn't match a
source), it counts the bytes associated with that as "literal added"
- at the end (once we have used up all the source hashes), we do the same
thing with the remaining destination hashes.
- when hashes do match, and we use the difference in counts as a value,
we also use up that destination hash entry (the 'd++').
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing code checked to make sure we were not in a bare
repository when doing a hard reset. However, we should take
this one step further, and make sure we are in a worktree.
Otherwise, we can end up munging files inside of '.git'.
Furthermore, we should do the same check for --merge resets,
which have the same properties. Actually, a merge reset of
HEAD^ would already complain, since further down in the code
we want a worktree. However, it is nicer to check up-front;
then we are sure we cover all cases ("git reset --merge"
would run, even though it wasn't doing anything) and we can
give a more specific message.
Add tests to t7103 to cover these cases and some missing ones.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --stringparam option is not available on older xmlto versions.
Instead, set man.base.url.for.relative.links via a .xsl file. Older
docbook versions will ignore this without causing grief to users of
older xmlto versions.
Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
rerere: don't segfault on failure to open rr-cache
The rr-cache directory should always exist if we are doing
garbage collection (earlier code paths check this
explicitly), but we may not necessarily succeed in opening
it (for example, due to permissions problems). In that case,
we should print an error message rather than simply
segfaulting.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mm/maint-hint-failed-merge' into maint
* mm/maint-hint-failed-merge:
user-manual: Document that "git merge" doesn't like uncommited changes.
merge-recursive: point the user to commit when file would be overwritten.
Merge branch 'mm/config-pathname-tilde-expand' into maint
* mm/config-pathname-tilde-expand:
Documentation: avoid xmlto input error
expand_user_path: expand ~ to $HOME, not to the actual homedir.
Expand ~ and ~user in core.excludesfile, commit.template
Merge branch 'jk/maint-break-rename-reduce-memory' into maint
* jk/maint-break-rename-reduce-memory:
diffcore-rename: reduce memory footprint by freeing blob data early
diffcore-break: save cnt_data for other phases
diffcore-break: free filespec data as we go
Documentation: xmlto 0.0.18 does not know --stringparam
Newer DocBook stylesheets want man.base.url.for.relative.links
parameter set when formatting manpages with external references
to turn them into full URLs, and leave a helpful "you should
set this parameter" message in the output. Earlier we added
the MAN_BASE_URL make variable to specify the value for it.
When MAN_BASE_URL is not given, it ought to be safe to set the
parameter to empty; it would result in an empty leading path for
older stylesheets that ignore the parameter, and newer ones
would produce the same "relative URL" without the message.
Unfortunately, older xmlto (at least version 0.0.18 released in
early 2004 that comes with RHEL/CentOS 5) does not understand
the --stringparam command line option, so we cannot add the
parameter definition unconditionally to the command line. Work
it around by passing the parameter only when set.
If you do not have a suitable URL prefix, you can pass a quoted empty
string to it, like so:
Fix crasher on encountering SHA1-like non-note in notes tree
When loading a notes tree, the code primarily looks for SHA1-like paths
whose total length (discounting directory separators) are 40 chars
(interpreted as valid note entries) or less (interpreted as subtree
entries that may in turn contain note entries when unpacked).
However, there is an additional condition that must hold for valid
subtree entries: They must be _tree_ objects (duh).
This patch adds an appropriate test for this condition, thereby fixing
the crash that occured when passing a non-tree object to the tree-walk
API.
The patch also adds another selftest verifying correct behaviour of
non-notes in note trees.
Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-chain-reply-to) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--nochain-reply-to'. More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some ancient platforms do not have an extensive list of alternate names for
character encodings. For example, Solaris 7 and IRIX 6.5 do not know that
ISO-8859-1 is the same as ISO8859-1. Modern platforms do know this, so use
the older name.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
pull: clarify advice for the unconfigured error case
When pull --rebase fails because it cannot find what branch to
merge against, the error message implies we are trying to merge.
Say "rebase against" instead of "merge with" to avoid confusion.
The configuration suggested to remedy the situation uses a
confusing syntax, with variables specified in the dotted form
accepted by 'git config' but separated from their values by the
'=' delimiter used by config files. Since the user will have to
edit this output anyway, it is more helpful to provide a config
file snippet to paste into an editor and modify.
Signed-off-by: Jan Krüger <jk@jk.gs> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Prepare for 1.6.5.4
merge: do not add standard message when message is given with -m option
Do not misidentify "git merge foo HEAD" as an old-style invocation
merge: do not add standard message when message is given with -m option
Even if the user explicitly gave her own message to "git merge", the
command still added its standard merge message. It resulted in a
useless repetition like this:
% git merge -m "Merge early part of side branch" `git rev-parse side~2`
% git show -s
commit 37217141e7519629353738d5e4e677a15096206f
Merge: e68e646a1d2374
Author: しらいし ななこ <nanako3@lavabit.com>
Date: Wed Dec 2 14:33:20 2009 +0900
The gave her own message because she didn't want git to add the
standard message (if she wanted to, she wouldn't have given one,
or she would have prepared it using git-fmt-merge-msg command).
Do not misidentify "git merge foo HEAD" as an old-style invocation
This was misinterpreted as an ancient style "git merge <message> HEAD
<commit> <commit>..." that merges one (or more) <commit> into the current
branch and record the resulting commit with the given message. Then a
later sanity check found that there is no <commit> specified and gave
a usage message.
Tested-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
help: Do not unnecessarily look for a repository
Documentation: Fix a few i.e./e.g. mix-ups
Documentation: Document --branch option in git clone synopsis
git-merge: a deprecation notice of the ancient command line syntax
The ancient form of git merge command used in the original sample script
has been copied from Linus and are still found everywhere, I think, and
people may still have it in their scripts, but on the other hand, it is so
unintuitive that even people reasonably familiar with git are surprised by
accidentally triggering the support to parse this ancient form.
Gently nudge people to upgrade their script to more recent and readable
style for eventual removal of the original syntax.
get_ref_states: strdup entries and free util in stale list
The entries in states->stale list is filled in handle_one_branch() that is
a call-back funcation to for_each_ref() using the callback parameter given
to it. We need to strdup() the refnames (both the string list key and the
value stored in util) for more permanent storage and free them when we are
done.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although 'git help' actually doesn't need to be run inside a git
repository and uses no repository-specific information, it looks for a git
directory. Searching for a git directory can be annoying in auto-mount
environments. With this commit, 'git help' no longer searches for a
repository when run without any options.
7c3baa9 originally modified 'git help -a' to not require a repository.
This applies the same fix for 'git help'.
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/gitweb-blame:
gitweb: Add link to other blame implementation in blame views
gitweb: Make linking to actions requiring JavaScript a feature
gitweb.js: fix padLeftStr() and its usage
gitweb.js: Harden setting blamed commit info in incremental blame
gitweb.js: fix null object exception in initials calculation
gitweb: Minify gitweb.js if JSMIN is defined
gitweb: Create links leading to 'blame_incremental' using JavaScript
gitweb: Colorize 'blame_incremental' view during processing
gitweb: Incremental blame (using JavaScript)
gitweb: Add optional "time to generate page" info in footer
gitweb: Make linking to actions requiring JavaScript a feature
Let gitweb turn some links (like 'blame' links) into linking to actions
which require JavaScript (like 'blame_incremental' action) only if
'javascript-actions' feature is enabled.
This means that links to such actions would be present only if both
JavaScript is enabled and 'javascript-actions' feature is enabled.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>