* da/difftool:
mergetool--lib: simplify API usage by removing more global variables
Fix misspelled mergetool.keepBackup
difftool/mergetool: refactor commands to use git-mergetool--lib
mergetool: use $( ... ) instead of `backticks`
bash completion: add git-difftool
difftool: add support for a difftool.prompt config variable
difftool: add various git-difftool tests
difftool: move 'git-difftool' out of contrib
difftool/mergetool: add diffuse as merge and diff tool
difftool: add a -y shortcut for --no-prompt
difftool: use perl built-ins when testing for msys
difftool: remove the backup file feature
difftool: remove merge options for opendiff, tkdiff, kdiff3 and xxdiff
git-mergetool: add new merge tool TortoiseMerge
git-mergetool/difftool: make (g)vimdiff workable under Windows
doc/merge-config: list ecmerge as a built-in merge tool
The gitattributes documentation has a section on the "diff"
attribute, with subsections for each of the things you might
want to configure in your diff config section (external
diff, hunk headers, etc). The first such subsection
specifically notes that the definition of the diff driver
should go into $GIT_DIR/config, but subsequent sections do
not.
This location is implied if you are reading the
documentation sequentially, but it is not uncommon for a new
user to jump to (or be referred to) a specific section. For
a new user who does not know git well enough to recognize
the config syntax, it is not clear that those directives
don't also go into the gitattributes file.
This patch just mentions the config file in each subsection,
similar to the way it is mentioned in the first.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since git doesn't provide a receive.denyBranchCreation or similar, here is
an example of how to be sure users cannot create branches remotely by
pushing a new reference.
This setup has been proven useful to prevent creation of spurious branches
because of users having their remote.origin.push set to HEAD, when they
use `git push` while being on a local topic branch of theirs instead of
the proper one.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test script for all archive attributes and their handling in
normal and bare repositories. export-ignore and export-subst are
tested, as well as the effect of the option --worktree-attributes.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old behaviour still remains with --worktree-attributes, and it is
always on for the legacy "git tar-tree".
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This instructs attr mechanism, not to look into working .gitattributes
at all. Needed by tools that does not handle working directory, such
as "git archive".
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We are interested in using archive mostly from a bare repository, so it
should not add .gitattributes to the work tree.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When interpreting a config value, the config parser reads in 1+ space
character(s) and puts -one- space character in the buffer as soon as
the first non-space character is encountered (if not inside quotes).
Unfortunately the buffer size check lacks the extra space character
which gets inserted at the next non-space character, resulting in
a crash with a specially crafted config entry.
The unit test now uses Java to compile a platform independent
.NET framework to output the test string in C# :o)
Read: Thanks to Johannes Sixt for the correct printf call
which replaces the perl invocation.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the new shorten_unambiguous_ref() for simplifying the output of
upstream branch names. This affects status and checkout.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
it's silly to do this:
mkdir foo && cd foo && git init && git push somewhere.git
but segfault should not happen even in that case.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As recorded in msysGit issue 125, if the user closes gitk while it
reports itself as still reading references then Tk will crash in the
geometry management code. This has been fixed for Tk 8.5.7 and above.
This patch avoids the problem by flushing outstanding geometry events
before calling the readrefs procedure.
See also http://code.google.com/p/msysgit/issues/detail?id=125
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes the launching of external diff to handle a diff tool
that has spaces in the path. This ensures a correctly formed
tcl list is passed to the open command with a single pipe character
prefixing the list (as per the tcl manual page for open).
The specific fault observed was that selecting WinMerge as the diff
tool from the default installed location in Program Files failed to
be launched from the context menu.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This records the window state in ~/.gitk. On startup, if the gitk
window was previously maximized (zoomed), then we restore that state.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Commit 97bed034 changed the behavior of the '/' key on the keyboard,
but the '/' on the keypad was left unused. They now both do the same
thing.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The text is merely cut-and-pasted from git-add--interactive.perl. The
cut-and-paste also fixes a typo.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original implementation considered the mode separately
from the rest of the hunks, asking about it outside the main
hunk-selection loop. This patch instead places a mode change
as the first hunk in the loop. This has two advantages:
1. less duplicated code (since we use the main selection
loop). This also cleans up an inconsistency, which is
that the main selection loop separates options with a
comma, whereas the mode prompt used slashes.
2. users can now skip the mode change and come back to it,
search for it (via "/mode"), etc, as they can with other
hunks.
To facilitate this, each hunk is now marked with a "type".
Mode hunks are not considered for splitting (which would
make no sense, and also confuses the split_hunk function),
nor are they editable. In theory, one could edit the mode
lines and change to a new mode. In practice, there are only
two modes that git cares about (0644 and 0755), so either
you want to move from one to the other or not (and you can
do that by staging or not staging).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's already 'd' to stop staging hunks in a file, but no explicit
command to stop the interactive staging (for the current files and the
remaining ones). Of course you can do 'd' and then ^C, but it would be
more intuitive to allow 'quit' action.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Example correct diff generated by `diff -M -B' might look like this:
diff --git a/file1 b/file2
similarity index 100%
rename from file1
rename to file2
diff --git a/file2 b/file1
similarity index 100%
rename from file2
rename to file1
Information about removing `file2' comes after information about creation
of new `file2' (renamed from `file1'). Existing implementation isn't able to
apply such patch, because it has to know in advance which files will be
removed.
This patch populates fn_table with information about removal of files
before calling check_patch() for each patch to be applied.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not only was it a repeat, but it also had no effect.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If someone responded with a negative (n|no) to the confirmation,
then the Message-ID of the discarded email is no longer used
in the References: header of subsequent emails.
Consequently, send_message() now returns 1 if the message was
sent and 0 otherwise.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This should make things a little more robust in terms of user input;
before, even the program got it wrong by outputting a line with only
"GIT:", which was left in place as a header, because there would be
no following space character.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace description of sendemail.multiedit in --annotate docs
with a reference to the CONFIGURATION section.
Add such a reference to the --compose documentation.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Modified the graph drawing logic to colorize edges based on parent-child
relationships similiarly to gitk.
Signed-off-by: Allan Caffee <allan.caffee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally reported by Linus in $gmane/116198
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This applies the shorten_unambiguous_ref function to the object name.
Default mode is controlled by core.warnAmbiguousRefs. Else it is given as
optional argument to --abbrev-ref={strict|loose}.
This should be faster than 'git for-each-ref --format="%(refname:short)" <ref>'
for single refs.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
core.warnAmbiguousRefs is used to select strict mode for the
abbreviation for the ":short" format specifier of "refname" and "upstream".
In strict mode, the abbreviated ref will never trigger the
'warn_ambiguous_refs' warning. I.e. for these refs:
refs/heads/xyzzy
refs/tags/xyzzy
the abbreviated forms are:
heads/xyzzy
tags/xyzzy
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the strict mode of abbreviation to shorten_unambiguous_ref(), i.e. the
resulting ref won't trigger the ambiguous ref warning.
All users of shorten_unambiguous_ref() still use the loose mode.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the code we literally stick "refs/heads/" on the front
and see if it resolves, so that is probably the best
explanation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These can really be thought of as two different modes, since
the "<branch>" parameter is treated differently in the two
(in one it is the branch to be checked out, but in the other
it is really a start-point for branch creation).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of description for the branch creation options is
simply cut and paste from git-branch. There are two reasons
to fix this:
1. It can grow stale with respect to what's in "git
branch" (which it is now is).
2. It is not just an implementation detail, but rather the
desired mental model for the command that we are using
"git branch" here. Being explicit about that can help
the user understand what is going on.
It also makes sense to strip the branch creation options
from the synopsis, as they are making it a long,
hard-to-read line. They are still easily discovered by
reading the options list, and --track is explicitly
referenced when branch creation is described.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The term "tracking" often creates confusion between remote
tracking branches and local branches which track a remote
branch. The term "upstream" captures more clearly the idea
of "branch A is based on branch B in some way", so it makes
sense to mention it.
At the same time, upstream branches are used for more
than just git-pull these days; let's mention that here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is not really about ignoring the config option; it is
about turning off tracking, _even if_ the config option is
set.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
People sometimes wonder why they cannot apply a patch that only
creates new files to an unborn branch.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow
- more clarity into who "owns" the name (ie now when we free the name in
the show_object callback, it's because we generated it ourselves by
calling path_name())
- not calling path_name() at all, either because we don't care about the
name in the first place, or because we are actually happy walking the
linked list of "struct name_path *" and the last component.
Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.
Why? We use that name for two things:
- add_preferred_base_object(), which actually _wants_ to traverse the
path, and now does it by looking for '/' characters!
- for 'name_hash()', which only cares about the last 16 characters of a
name, so again, generating the full name seems to be just unnecessary
work.
Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.
This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
