* git://repo.or.cz/git-gui:
git-gui: Automatically spell check commit messages as the user types
git-gui: support Git Gui.app under OS X 10.5
git-gui: Update German translation.
git-gui: (i18n) Fix a bunch of still untranslated strings.
It's really not very easy to visualize the commit walker,
because - on purpose - it obvously doesn't show the
uninteresting commits!
We will soon add a "--show-all" flag to the revision walker,
which will make it show uninteresting commits too, and they'll
have a '^' in front of them.
This is to update 'gitk' to show those negative commits in gray
to futureproof it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When using the '-w $cvsdir' option to cvsexportcommit, it will chdir into
$cvsdir before executing several other git commands. If $GIT_DIR is set to
a relative path (e.g. '.'), the git commands executed by cvsexportcommit
will naturally fail.
Therefore, ensure that $GIT_DIR is absolute before the chdir to $cvsdir.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The testcase verifies that 'git cvsexportcommit' functions correctly when
the '-w' option is used, and GIT_DIR is set to a relative path (e.g. '.').
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many user friendly tools like word processors, email editors and web
browsers allow users to spell check the message they are writing
as they type it, making it easy to identify a common misspelling
of a word and correct it on the fly.
We now open a bi-directional pipe to Aspell and feed the message
text the user is editing off to the program about once every 300
milliseconds. This is frequent enough that the user sees the results
almost immediately, but is not so frequent as to cause significant
additional load on the system. If the user has modified the message
text during the last 300 milliseconds we delay until the next period,
ensuring that we avoid flooding the Aspell process with a lot of
text while the user is actively typing their message.
We wait to send the current message buffer to Aspell until the user
is at a word boundary, thus ensuring that we are not likely to ask
for misspelled word detection on a word that the user is actively
typing, as most words are misspelled when only partially typed,
even if the user has thus far typed it correctly.
Misspelled words are highlighted in red and are given an underline,
causing the word to stand out from the others in the buffer. This is
a very common user interface idiom for displaying misspelled words,
but differs from one platform to the next in slight variations.
For example the Mac OS X system prefers using a dashed red underline,
leaving the word in the original text color. Unfortunately the
control that Tk gives us over text display is not powerful enough
to handle such formatting so we have to work with the least common
denominator.
The top suggestions for a misspelling are saved in an array and
offered to the user when they right-click (or on the Mac ctrl-click)
a misspelled word. Selecting an entry from this menu will replace
the misspelling with the correction shown. Replacement is integrated
with the undo/redo stack so undoing a replacement will restore the
misspelled original text.
If Aspell could not be started during git-gui launch we silently eat
the error and run without spell checking support. This way users
who do not have Aspell in their $PATH can continue to use git-gui,
although they will not get the advanced spelling functionality.
If Aspell started successfully the version line and language are
shown in git-gui's about box, below the Tcl/Tk versions. This way
the user can verify the Aspell function has been activated.
If Aspell crashes while we are running we inform the user with an
error dialog and then disable Aspell entirely for the rest of this
git-gui session. This prevents us from fork-bombing the system
with Aspell instances that always crash when presented with the
current message text, should there be a bug in either Aspell or in
git-gui's output to it.
We escape all input lines with ^, as recommended by the Aspell manual
page, as this allows Aspell to properly ignore any input line that is
otherwise looking like a command (e.g. ! to enable terse output). By
using this escape however we need to correct all word offsets by -1 as
Aspell is apparently considering the ^ escape to be part of the line's
character count, but our Tk text widget obviously does not.
Available dictionaries are offered in the Options dialog, allowing
the user to select the language they want to spellcheck commit
messages with for the current repository, as well as the global
user setting that all repositories inherit.
Special thanks to Adam Flott for suggesting connecting git-gui
to Aspell for the purpose of spell checking the commit message,
and to Wincent Colaiuta for the idea to wait for a word boundary
before passing the message over for checking.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tk Framework moved its location in 10.5 compared to 10.4
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Tested-by: Seth Falcon <seth@userprimary.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* lt/in-core-index:
lazy index hashing
Create pathname-based hash-table lookup into index
read-cache.c: introduce is_racy_timestamp() helper
read-cache.c: fix a couple more CE_REMOVE conversion
Also use unpack_trees() in do_diff_cache()
Make run_diff_index() use unpack_trees(), not read_tree()
Avoid running lstat(2) on the same cache entry.
index: be careful when handling long names
Make on-disk index representation separate from in-core one
When creating a tag through gitk, and the tag name includes a slash (or
slashes), gitk errors out in a popup window. This patch makes gitk use
'git tag' to create the tag instead of modifying files in refs/tags/,
which fixes the issue; if 'git tag' throws an error, gitk pops up with
the error message.
The problem was reported by Frédéric Brière through
http://bugs.debian.org/464104
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Ignoring space changes can be helpful. For example, a commit
claims to only reformat source code and you quickly want to
verify if this claim is true. Or a commit accidentally changes
code formatting and you want to focus on the real changes.
In such cases a button to toggle of whitespace changes would be
quite handy. You could quickly toggle between seeing and
ignoring whitespace changes.
This commit adds such a checkbutton right above the diff view.
However, in general it is a good thing to see whitespace changes
and therefore the state of the checkbutton is not saved. For
example, space changes might happen unintentionally. But they are
real changes yielding different sha1s for the blobs involved.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The "Key bindings" message under the "Help" menu was too long
and could not be parsed by the translation engine.
Fix both issues by translating one line at a time.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Change the default operation to show 'when (day the commit was made),
who (who made the commit), what (what the commit log was)' in the
minibuffer instead of SHA1 and title of the commit log.
Since the user may prefer other displaying options, it is made as a
user-configurable option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This establishes what the "bad" whitespaces are for this
project.
The rules are:
- Unless otherwise specified, indent with SP that could be
replaced with HT are not "bad". But SP before HT in the
indent is "bad", and trailing whitespaces are "bad".
- For C source files, initial indent by SP that can be replaced
with HT is also "bad".
- Test scripts in t/ and test vectors in its subdirectories can
contain anything, so we make it unrestricted for now.
Anything "bad" will be shown in WHITESPACE error indicator in
diff output, and "apply --whitespace=warn" will warn about it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This command is identical to `git blame', but it shows SVN revision
numbers instead of git commit hashes.
[ew: support "^initial commit" and minor formatting fixes]
Signed-off-by: Tim Stoakes <tim@stoakes.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
user.{name,email}, core.{pager,editor,excludesfile,whitespace} and
i18n.{commit,logoutput}encoding all expect string values.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff.external, diff.*.command, diff.color.*, color.diff.* and
diff.*.funcname configuration variables expect a string value.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gc.reflogexpire and gc.reflogexpireunreachable configuration expect
a string value suitable for calling approxidate() with.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is used to report misconfigured configuration file that does not
give any value to a non-boolean variable, e.g.
[section]
var
It is perfectly fine to say it if the section.var is a boolean (it means
true), but if a variable expects a string value it should be flagged as
a configuration error.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
curl versions 7.16.3 to 7.18.0 included had a regression in which https
requests following curl_global_cleanup/init sequence would fail with ASN1
parser errors with curl-gnutls. Such sequences happen in some cases such
as git fetch.
We work around this by removing the http_init and http_cleanup calls from
get_refs_via_curl, replacing them with a transport->data initialization
with the http_walker (which does http_init).
While the http_walker is not currently used in get_refs_via_curl, http
and walker code refactor will make it use it.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458
> Julian Phillips:
> > Are you using docbook xsl 1.72? There are known problems building the
> > manpages with that version. 1.71 works, and 1.73 should work when it get
> > released.
I was able to solve this problem with this patch, which adds a XSL file
used specifically for DOCBOOK_XSL_172=YesPlease and where dots and
backslashes are escaped properly so they won't be substituted to the
wrong thing further down the "DocBook XSL pipeline". Doing the escaping
in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end
this part of the manpage nightmare.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
