Colored word diff without context lines firstly printed all the hunk
headers among each other and then printed the diff.
This was due to the code relying on getting at least one context line at
the end of each hunk, where the colored words would be flushed (it is
done that way to be able to ignore rewrapped lines).
Noticed by Markus Heidelberg.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of having all PDB files for all projects named "vc90.pdb", name them
after the respective project to make the relation more clear (and to avoid name
clashes when copying files around).
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When compiling with MSVC on x86-compatible, use an intrinsic for byte swapping.
In contrast to the GCC path, we do not prefer inline assembly here as it is not
supported for the x64 platform.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add p4merge to the set of built-in diff/merge tools, and update
bash completion and documentation.
Signed-off-by: Scott Chacon <schacon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users seem to call git-describe without reading the manpage, and then
wonder why it doesn't work with unannotated tags by default.
Make a minimal effort towards seeing if there would have been
unannotated tags, and tell the user. Specifically, we say that --tags
could work if we found any unannotated tags. If not, we say that
--always would have given results.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I personally use "git bisect visualize" all the time when I bisect, but it
turns out that that is not a very flexible model. Sometimes I want to do
bisection based on all commits (no pathname limiting), but then visualize
the current bisection tree with just a few pathnames because I _suspect_
those pathnames are involved in the problem but am not totally sure about
them.
And at other times, I want to use other revision parsing logic, none of
which is available with "git bisect visualize".
So this adds "--bisect" as a revision parsing argument, and as a result it
just works with all the normal logging tools. So now I can just do
gitk --bisect --simplify-by-decoration filename-here
etc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
help -a: do not unnecessarily look for a repository
Do not try to remove directories when removing old links
rebase -i: more graceful handling of invalid commands
help -i: properly error out if no info viewer can be found
'git commit -s' will insert a blank line before the Signed-off-by
line at the end of the message, unless this last line is a
Signed-off-by line itself. Common use has other trailing lines
at the ends of commit text, in the style of RFC2822 headers.
Be more generous in considering lines to be part of this footer.
If the last paragraph of the commit message reasonably resembles
RFC-2822 formatted lines, don't insert that blank line.
The new Signed-off-by line is still only suppressed when the
author's existing Signed-off-by is the last line of the message.
Signed-off-by: David Brown <davidb@quicinc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So complete refs, files after the double-dash and some diff options that
make sense for difftool.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although 'git help -a' actually doesn't need to be run inside a git
repository and uses no repository-specific information, it looks for a git
directory. On 'git <TAB><TAB>' the bash completion runs 'git help -a' and
unnecessary 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 with the -a option.
Reported by Vincent Danjean through http://bugs.debian.org/539273
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Complete all long options for 'git rebase' except --no-verify
(probably used very seldom) and the long options corresponding
to -v, -q, and -f.
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>
When building Git with MSVC on Windows, directories named after the Git alias
are created for the output files, e.g. there is a "git-merge-index" directory
next to the "git-merge-index.exe" executable in the build root. Previously,
"make all" just checked if "git-merge-index" and "git-merge-index.exe" are the
same file, and if not, tried to remove "git-merge-index". This fails in the
case of "git-merge-index" being a directory, which is why this is checked now.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When there are large numbers of refs, calling read_ref for each ref is
inefficent (and infact downright slow) - so instead use for_each_ref
to build up a string list of all the refs that we currently have,
which significantly improves the volume.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The ref_remove_duplicates function was very slow at dealing with very
large numbers of refs. This is because it was using a linear search
through all remaining refs to find any duplicates of the current ref.
Rewriting it to use a string list to keep track of which refs have
already been seen and removing duplicates when they are found is much
more efficient.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Usually we show deletion as a big hunk deleting all of the
file's text. However, for files with no content, the diff
shows just the 'deleted file mode ...' line. This patch
cause "add -p" (and related commands) to recognize that line
and explicitly ask about deleting the file.
We only add the "stage this deletion" hunk for empty files,
since other files will already ask about the big content
deletion hunk. We could also change those files to simply
display "stage this deletion", but showing the actual
deleted content is probably what an interactive user wants.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, when there is an invalid command, the rest of the line is
still treated as if the command had been valid, i.e. rebase -i attempts
to produce a patch, using the next argument as a SHA1 name. If there is
no next argument or an invalid one, very confusing error messages
appear (the line was '.'; path to git-rebase-todo substituted):
Unknown command: .
fatal: ambiguous argument 'Please fix this in the file $somefile.':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name Please fix this in the file $somefile.
fatal: bad revision 'Please fix this in the file $somefile.'
Instead, verify the validity of the remaining line and error out earlier
if necessary.
Signed-off-by: Jan Krüger <jk@jk.gs>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this commit, git help -i <cmd> prints an error message and exits
non-zero instead of being silent and exit code 0.
Reported by Trent W. Buck through
http://bugs.debian.org/537664
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our gitignore doesn't use a preceding "/" to root its
patterns in the top of the repository. This means that if
you add a file or directory called "git" (for example)
inside a subdirectory, it will be erroneously ignored.
This patch was done mechanically with "s/^[^*]/\/&/" with
one exception: instead of ignoring gitk-wish, we should
gitk-git/gitk-wish (arguably, this should be done in
gitk-git/.gitignore, but because that is a subtree merge
from elsewhere, this is easier).
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: convert SVN 1.5+ / svnmerge.py svn:mergeinfo props to parents
git-svn: add test data for SVN 1.5+ merge, with script.
git-svn: convert SVK merge tickets to extra parents
git-svn: allow test setup script to support PERL env. var
git-svn: add test data for SVK merge, with script.
git svn: fix fetch where glob is on the top-level URL
* git://repo.or.cz/git-gui:
git-gui: adjust the minimum height of diff pane for shorter screen height
git-gui: fix use of uninitialized variable
git-gui: store wm state and fix wm geometry
git-gui: Ensure submodule path is quoted properly
git-gui: fix diff for partially staged submodule changes
git-gui: Update russian translation
git-gui: Limit display to a maximum number of files
git-gui: remove warning when deleting correctly merged remote branch
git-gui: Added Greek translation & glossary
git-gui: display summary when showing diff of a submodule
With the --dirty option, git describe works on HEAD but append s"-dirty"
iff the contents of the work tree differs from HEAD. E.g.
$ git describe --dirty
v1.6.5-15-gc274db7
$ echo >> Makefile
$ git describe --dirty
v1.6.5-15-gc274db7-dirty
The --dirty option can also be used to specify what is appended, instead
of the default string "-dirty".
$ git describe --dirty=.mod
v1.6.5-15-gc274db7.mod
Many build scripts use `git describe` to produce a version number based on
the description of HEAD (on which the work tree is based) + saying that if
the build contains uncommitted changes. This patch helps the writing of
such scripts since `git describe --dirty` does directly the intended thing.
Three possiblities were considered while discussing this new feature:
1. Describe the work tree by default and describe HEAD only if "HEAD" is
explicitly specified
Pro: does the right thing by default (both for users and for scripts)
Pro: other git commands that works on the work tree by default
Con: breaks existing scripts used by the Linux kernel and other projects
2. Use --worktree instead of --dirty
Pro: does what it says: "git describe --worktree" describes the work tree
Con: other commands do not require a --worktree option when working
on the work tree (it often is the default mode for them)
Con: unusable with an optional value: "git describe --worktree=.mod"
is quite unintuitive.
3. Use --dirty as in this patch
Pro: makes sense to specify an optional value (what the dirty mark is)
Pro: does not have any of the big cons of previous alternatives
* does not break scripts
* is not inconsistent with other git commands
This patch takes the third approach.
Signed-off-by: Jean Privat <jean@pryen.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the main window is maximized, if the screen height is shorter (e.g.
Netbook screen 1024x600), both the partial commit pane and the status bar
are hidden. The diff pane is resizable, so that it can use less vertical
height, allowing the overall window to be shorter and still display both
the entire commit pane and status bar.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This feature is long overdue; convert SVN's merge representation to git's
as revisions are imported. This works by converting the list of revisions
in each line of the svn:mergeinfo into git revision ranges, and then
checking the latest of each of these revision ranges for A) being new and
B) now being completely merged.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Dump generated with SVN 1.5.1 (on lenny amd64). This test
should hopefully cover all but a few intermediate versions of
the svnmerge.py script.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
SVK is a simple case to start with, as its idea of merge parents
matches git's one. When a svk:merge ticket is encountered, check each
of the listed merged revisions to see if they are in the history of
this commit; if not, then we have encountered a merge - record it.
[ew: minor formatting cleanups]
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Possibly the 'perl' in the PATH is not the one to be used for the tests;
let PERL set in the environment select it.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Dump generated with SVK 2.0.2 and SVN 1.5.1 (on lenny amd64).
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
In cases where the top-level URL we're tracking is the path we
glob against, we can once again track odd repositories that keep
branches/tags at the top level. This regression was introduced
in commit 6f5748e14c.
Thanks to Daniel Cordero for the original bug report and
bisection.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is needed because we want to use the
advice.pushnonfastforward variable.
Previously, we would load the config on demand only when we
needed to look at push.default. Which meant that "git push"
would load it, but "git push remote" would not, leading to
differing behavior.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/receive-pack-auto:
receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
gc --auto --quiet: make the notice a bit less verboase
GIT_DIFFTOOL_PROMPT doesn't have any effect if overridden with --prompt.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first argument of the tar command is interpreted as a bundle of
letters specifying the mode of operation and additional options, with
any option arguments taken from subsequent words on the command line
as needed. The implementation of tar in busybox treats this bundle
as if preceded by a dash and then parses it by getopt rules, which
mishandles 'tar xfo -'. Use 'tar xof -' instead to work this around.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
