* 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
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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
The intent of this particular call to 'git read-tree' was to fill an
index. But in fact, it only allocated an empty index. Later in the
program, the index is filled anyway by calling read-tree with specific
commits, and considering that elsewhere the index is even removed (i.e.,
it is not relied upon that the index file exists), this first call of
read-tree is completely redundant.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The example was taken from aa4ed402c9
(Add 'filter' attribute and external filter driver definition).
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit b4d1690 (Teach Git to respect skip-worktree bit (reading part))
fails to make "git commit -- a b c" respect skip-worktree
(i.e. not committing paths that are skip-worktree). This is because
when the index is reset back to HEAD, all skip-worktree information is
gone.
This patch saves skip-worktree information in the string list of
committed paths, then reuse it later on to skip skip-worktree paths.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously CE_MATCH_IGNORE_VALID flag is used by both valid and
skip-worktree bits. While the two bits have similar behaviour, sharing
this flag means "git update-index --really-refresh" will ignore
skip-worktree while it should not. Instead another flag is
introduced to ignore skip-worktree bit, CE_MATCH_IGNORE_VALID only
applies to valid bit.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MSG, PARENT, and CNT are never used, just assigned to.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fast-forward logic is never being triggered because $common and
$MRC are never equivalent. $common is initialized to a commit id by
merge-base and MRC is initialized to HEAD. Fix this by initializing
$MRC to the commit id for HEAD so that its possible for $MRC and
$common to be equal.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Its not very easy to understand what heads are being merged given
the current output of an octopus merge. Fix this by replacing the
sha1 with the (usually) better description in GITHEAD_<SHA1>.
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace refs are useful to change some git objects after they
have started to be shared between different repositories. One
might want to ignore them to see the original state, and
"--no-replace-objects" option can be used from the command
line to do so.
This option simply sets the GIT_NO_REPLACE_OBJECTS environment
variable, and that is enough to make gitk ignore replace refs.
The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
safer on some platforms, thanks to Johannes Sixt and Michael J
Gruber.
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
Suggesting "'reset HEAD <path>' to unstage" is dead wrong if we are about
to record a merge commit. For either an unmerged path (i.e. with
unresolved conflicts), or an updated path, it would result in discarding
what the other branch did.
Note that we do not do anything special in a case where we are amending a
merge. The user is making an evil merge starting from an already
committed merge, and running "reset HEAD <path>" is the right way to get
rid of the local edit that has been added to the index.
Once "reset --unresolve <path>" becomes available, we might want to
suggest it for a merged path that has unresolve information, but until
then, just remove the incorrect advice.
We might also want to suggest "checkout --conflict <path>" to revert the
file in the work tree to the state of failed automerge for an unmerged
path, but we never did that, and this commit does not change that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the desired resolution is to remove the path, "git rm <path>" is the
command the user needs to use. Just like in "Changed but not updated"
section, suggest to use "git add/rm" as appropriate.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code checked for the MERGE_HEAD file to see if we were about
to commit a merge twice in the codepath; also one of them used a
variable merge_head_sha1[] which was set but was never used.
Just check it once, but do so also in "git status", too, as
we will be using this for status generation in the next patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Print the sha1 of the deleted tag (in addition to the tag name) so that
one can easily recreate a mistakenly deleted tag:
git tag -d tagname
Deleted tag 'tagname' (was DEADBEEF)
git tag 'tagname' DEADBEEF
We output the previous ref also in the case of forcefully overwriting
tags.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Helped-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
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>
This hook runs after "git fetch" in the repository the objects are
fetched from as the user who fetched, and has security implications.
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
Add support for taking over transports that turn out to be smart.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor the transport options parsing so that protocols that aren't
directly smart transports (file://, git://, ssh:// & co) can record
the smart transport options for the case if it turns that transport
can actually be smart.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change URL handling to allow external protocol handlers to implement
new protocols without the '::' syntax if helper name does not conflict
with any built-in protocol.
foo:// now invokes git-remote-foo with foo:// as the URL.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for marking capability as mandatory for hosting git version
to understand. This is useful for helpers which require various types
of assistance from main git binary.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remote helpers deadlock easily, so support debug mode which shows the
interaction steps.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 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
Conflicts:
merge-recursive.c
Move a useful script function to decode colored output to
text form from t4034 and use it in this test as well.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
This reverts commit c0ecb07048 "git-pull.sh:
Fix call to git-merge for new command format" and
commit b81e00a965 "git-merge: a deprecation
notice of the ancient command line syntax".
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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
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:
r32
+empty_dir: packages/sipb-xen-remctl-auto/sipb-xen-remctl-auto/files/etc/remctl/sipb-xen-auto/acl
+empty_dir: packages/sipb-xen-remctl-auto/sipb-xen-remctl-auto/files/etc/remctl/sipb-xen-auto/machine.d
+empty_dir: packages/sipb-xen-remctl-auto/sipb-xen-remctl-auto/files/etc/remctl/sipb-xen-auto/moira-acl
[...]
r314
-empty_dir: packages/sipb-xen-remctl-auto
[ew: rewrote to be line-wrapped at <= 80-columns]
Reported-by: Evan Broder <broder@mit.edu>
Signed-off-by: Greg Price <price@ksplice.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
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>
This patch adds testcases verifying correct behaviour in several scenarios
regarding fast-import of notes:
- using a mixture of 'N' and 'M' commands
- updating existing notes
- concatenation of notes
- 'deleteall' also removes notes
- fanout schemes is added/removed when needed
- git-fast-import's branch unload/reload preserves notes
- non-notes are not clobbered in the presence of notes
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch teaches 'git fast-import' to automatically organize note objects
in a fast-import stream into an appropriate fanout structure. The notes API
in notes.h is NOT used to accomplish this, because trying to keep the
fast-import and notes data structures in sync would yield a significantly
larger patch with higher complexity.
Note objects are added with the 'N' command, and accounted for with a
per-branch counter, which is used to trigger fanout restructuring when
needed. Note that when restructuring the branch tree, _any_ entry whose
path consists of 40 hex chars (not including directory separators) will
be recognized as a note object. It is therefore not advisable to
manipulate note entries with M/D/R/C commands.
Since note objects are stored in the same tree structure as other objects,
the unloading and reloading of a fast-import branches handle note objects
transparently.
This patch has been improved by the following contributions:
- Shawn O. Pearce: Several style- and logic-related improvements
Cc: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
