* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix "can't unset prevlines(...)" Tcl error
gitk: Avoid an error when cherry-picking if HEAD has moved on
gitk: Check that we are running on at least Tcl/Tk 8.4
gitk: Do not pick up file names of "copy from" lines
gitk: Add support for OS X mouse wheel
gitk: disable colours when calling git log
This fixes the error reported by Michele Ballabio, where gitk will
throw a Tcl error "can't unset prevlines(...)" when displaying a
commit that has a parent commit listed more than once, and the commit
is the first child of that parent.
The problem was basically that we had two variables, prevlines and
lineends, and were relying on the invariant that prevlines($id) was
set iff $id was in the lineends($r) list for some $r. But having
a duplicate parent breaks that invariant since we end up with the
parent listed twice in lineends.
This fixes it by simplifying the logic to use only a single variable,
lineend. It also rearranges things a little so that we don't try to
draw the line for the duplicated parent twice.
Signed-off-by: Paul Mackerras <paulus@samba.org>
There is already logic in the git wrapper to deduce the exec_path from
argv[0], when the git wrapper was called with an absolute path. Extend
that logic to handle relative paths as well.
For example, when you call "../../hello/world/git", it will not turn
"../../hello/world" into an absolute path, and use that.
Initial implementation by Scott R Parish.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The current git-p4 implementation does support file renames. However, because
it does not use the "p4 integrate" command, the history for the renamed file is
not linked to the new file.
This changeset adds support for perforce renames with the integrate command.
Currently this feature is only enabled when calling git-p4 submit with the -M
option. This is intended to look and behave similar to the "detect renames"
feature of other git commands.
The following sequence is used for renamed files:
p4 integrate -Dt x x'
p4 edit x'
rm x'
git apply
p4 delete x
By default, perforce will not allow an integration with a target file that has
been deleted. That is, if x' in the example above is the name of a previously
deleted file then perforce will fail the integrate. The -Dt option tells
perforce to allow the target of integrate to be a previously deleted file.
Signed-off-by: Chris Pettitt <cpettitt@gmail.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
This fixes an error reported by Adam Piątyszek: if the current HEAD
is not in the graph that gitk knows about when we do a cherry-pick
using gitk, then gitk hits an error when trying to update its
internal representation of the topology. This avoids the error by
not doing that update if the HEAD before the cherry-pick was a
commit that gitk doesn't know about.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This checks that we have Tcl/Tk 8.4 or later, and puts up an error
message in a window and quits if not.
This was prompted by a patch submitted by Steffen Prohaska, but is
done a bit differently (this uses package require rather than
looking at [info tclversion], and uses show_error to display the
error rather than printing it to stderr).
Signed-off-by: Paul Mackerras <paulus@samba.org>
A file copy would be detected only if the original file was modified in the
same commit. This implies that there will be a patch listed under the
original file name, and we would expect that clicking the original file
name in the file list warps the patch window to that file's patch. (If the
original file was not modified, the copy would not be detected in the first
place, the copied file would be listed as "new file", and this whole matter
would not apply.)
However, if the name of the copy is sorted after the original file's patch,
then the logic introduced by commit d1cb298b0b (which picks up the link
information from the "copy from" line) would overwrite the link
information that is already present for the original file name, which was
parsed earlier. Hence, this patch reverts part of said commit.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
(Väinö Järvelä supplied this patch a while ago for 1.5.2. It no longer
applied cleanly, so I'm reposting it.)
MacBook doesn't seem to recognize MouseRelease-4 and -5 events, at all.
So i added a support for the MouseWheel event, which i limited to Tcl/tk
aqua, as i couldn't test it neither on Linux or Windows. Tcl/tk needs to
be updated from the version that is shipped with OS X 10.4 Tiger, for
this patch to work.
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In 89d750bf6f I got a little too
aggressive with changing "git diff" to "git diff-tree". This is
shown to the user, who expects to see a full diff on their console,
and will want to see the output of their custom diff drivers (if
any) as the whole point of this call site is to show the diff to
the end-user.
Noticed by Johannes Sixt <j.sixt@viscovery.net>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Further 1.5.3.5 fixes described in release notes
Avoid invoking diff drivers during git-stash
attr: fix segfault in gitattributes parsing code
Define NI_MAXSERV if not defined by operating system
Ensure we add directories in the correct order
Avoid scary errors about tagged trees/blobs during git-fetch
This patch tries to make the description of --auto a little
more clear for new users, especially those referred by the
"git-gc --auto" notification message.
It also cleans up some grammatical errors and typos in the
original description, as well as rewording for clarity.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that git-gc --auto tells the user to look at the man
page, it makes sense to mention the auto behavior near the
top (since this is likely to be most users' first exposure
to git-gc).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The previous message had too much of a "boy, you should
really turn off this annoying gc" flair to it. Instead,
let's make sure the user understands what is happening, that
they can run it themselves, and where to find more info.
Suggested by Brian Gernhardt.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-stash needs to restrict itself to plumbing when running automated
diffs as part of its operation as the user may have configured a
custom diff driver that opens an interactive UI for certain/all
files. Doing that during scripted actions is very unfriendly to
the end-user and may cause git-stash to fail to work.
Reported by Johannes Sixt
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git may segfault if gitattributes contains an invalid
entry. A test is added to t0020 that triggers the segfault.
The parsing code is fixed to avoid the crash.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I found I needed NI_MAXSERV as it is defined in netdb.h, which is
not included by daemon.c. Rather than including the whole header
we can define a reasonable fallback value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CVS gets understandably upset if you try and add a subdirectory
before it's parent directory. This patch fixes that.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Ok, what is going on is:
- append_fetch_head() looks up the SHA1 for all heads (including tags):
if (get_sha1(head, sha1))
return error("Not a valid object name: %s", head);
- it then wants to check if it's a candidate for merging (because
fetching also does the whole "list which heads to merge" in case
it is going to be part of a "pull"):
commit = lookup_commit_reference(sha1);
if (!commit)
not_for_merge = 1;
- and that "lookup_commit_reference()" is just very vocal about the
case where it fails. It really shouldn't be, and it shouldn't
affect the actual end result, but that basically explains why
you get that scary warning.
In short, the warning is just bogus, and should be harmless, but
I agree that it's ugly. I think the appended patch should fix it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Yet more 1.5.3.5 fixes mentioned in release notes
cvsserver: Use exit 1 instead of die when req_Root fails.
git-blame shouldn't crash if run in an unmerged tree
git-config: print error message if the config file cannot be read
fixing output of non-fast-forward output of post-receive-email
This was causing test failures because die was exiting 255.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are in the middle of resolving a merge conflict there may be
one or more files whose entries in the index represent an unmerged
state (index entries in the higher-order stages).
Attempting to run git-blame on any file in such a working directory
resulted in "fatal: internal error: ce_mode is 0" as we use the magic
marker for an unmerged entry is 0 (set up by things like diff-lib.c's
do_diff_cache() and builtin-read-tree.c's read_tree_unmerged())
and the ce_match_stat_basic() function gets upset about this.
I'm not entirely sure that the whole "ce_mode = 0" case is a good
idea to begin with, and maybe the right thing to do is to remove
that horrid freakish special case, but removing the internal error
seems to be the simplest fix for now.
Linus
[sp: Thanks to Björn Steinbrink for the test case]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Pass the fake commit through convert_to_git, so that the
file is adjusted for local line-ending convention.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Instead of simply exiting with 255, print an error message including
the reason why a config file specified through --file cannot be opened
or read.
The problem was noticed by Joey Hess, reported through
http://bugs.debian.org/445208
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
post-receive-email has one place where the variable fast_forward is not
spelled correctly. At the same place the logic was reversed. The
combination of both bugs made the script work correctly for fast-forward
commits but not for non-fast-forward ones. This change fixes this to
be correct in both cases.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user specifies 'diff.color = 1' in their configuration file,
then gitk will not start. Disable colours when calling git log.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-svn.perl (&fatal): Append the newline at the end of the error
message.
Adjust all callers.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This allows one to easily retrieve a list of svn properties from within
git-svn without requiring svn or knowing the URL of a repository.
* git-svn.perl (%cmd): Add the command `proplist'.
(&cmd_proplist): New.
* t/t9101-git-svn-props.sh: Test git svn proplist.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This allows one to easily retrieve a single SVN property from within
git-svn without requiring svn or remembering the URL of a repository
* git-svn.perl (%cmd): Add the new command `propget'.
($cmd_dir_prefix): New global.
(&get_svnprops): New helper.
(&cmd_propget): New. Use &get_svnprops.
* t/t9101-git-svn-props.sh: Add a test case for propget.
[ew: make sure the rev-parse --show-prefix call doesn't break
the `git-svn clone' command]
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git svn create-ignore (to create one .gitignore per directory
from the svn:ignore properties. This has the disadvantage of
committing the .gitignore during the next dcommit, but when you
import a repo with tons of ignores (>1000), using git svn show-ignore
to build .git/info/exclude is *not* a good idea, because things like
git-status will end up doing >1000 fnmatch *per file* in the repo,
which leads to git-status taking more than 4s on my Core2Duo 2Ghz 2G
RAM)
* git-svn.perl (%cmd): Add the new command `create-ignore'.
(&cmd_create_ignore): New.
* t/t9101-git-svn-props.sh: Adjust the test-case for show-ignore and
add a test case for create-ignore.
[ew: added commit message from
<05CAB148-56ED-4FF1-8AAB-4BA2A0B70C2C@lrde.epita.fr> ]
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-svn.perl (&traverse_ignore): Remove.
(&prop_walk): New.
(&cmd_show_ignore): Use prop_walk.
[ew: This will ease the implementation of the `create-ignore',
`propget', and `proplist' commands]
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Document additional 1.5.3.5 fixes in release notes
Avoid 'expr index' on Mac OS X as it isn't supported
filter-branch: update current branch when rewritten
fix filter-branch documentation
helpful error message when send-pack finds no refs in common.
Fix setup_git_directory_gently() with relative GIT_DIR & GIT_WORK_TREE
Correct typos in release notes for 1.5.3.5
This fixes git-instaweb so it can start an httpd without warning
about an invalid test command. Yes its ugly, but its also quite
portable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Earlier, "git filter-branch --<options> HEAD" would not update the
working tree after rewriting the branch. This commit fixes it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The man page for filter-branch still talked about writing the result
to the branch "newbranch". This is hopefully the last place where the
old behaviour was described.
Noticed by Bill Lear.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some variables coming from the Subversion's Perl bindings are used
in our code only once, so the interpreter warns us about it. These
warnings are false-positives, because the variables themselves are
initialized in the binding's guts, that are made by SWIG.
Credits to Sam Vilain for his note about "no warnings 'once'".
[ew: minor formatting change]
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There are a few programs, such as config and diff, which allow running
without a git repository. Therefore, they have to call
setup_git_directory_gently().
However, when GIT_DIR and GIT_WORK_TREE were set, and the current
directory was a subdirectory of the work tree,
setup_git_directory_gently() would return a bogus NULL prefix.
This patch fixes that.
Noticed by REPLeffect on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since commit e86ad71fe5 we do not use
a temporary directory in cvsexportcommit. So there is no need to set
one up.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-rebase uses format-patch's --ignore-if-in-upstream
option, but we never document the user-visible behavior. The
example is placed near the top of the example list rather
than at the bottom because it is:
a. a simple example
b. a reasonably common scenario for many projects (mail
some patches which get accepted upstream, then rebase)
[sp: Corrected direction of 'HEAD..<upstream>' set comparsion]
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
