- 11 5月, 2013 4 次提交
-
-
由 Knut Franke 提交于
Sometimes it's helpful (at least psychologically) to have this feature easily accessible. Code borrows heavily from cherrypick. Signed-off-by: NKnut Franke <Knut.Franke@gmx.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Felipe Contreras 提交于
git diff is perfectly able to do this with '-- files', no need for manual filtering. This makes gettreediffs consistent with getblobdiffs. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Anand Kumria 提交于
By selecting a tag within gitk you can display information about it. This information is output by using the command 'git cat-file tag <tagid>' This outputs the *raw* information from the tag, amongst which is the time - in seconds since the epoch. As useful as that value is, I find it a lot easier to read and process time which it is something like: "Mon Dec 31 14:26:11 2012 -0800" This change will modify the display of tags in gitk like so: @@ -1,7 +1,7 @@ object 5d417842 type commit tag v1.8.1 -tagger Junio C Hamano <gitster@pobox.com> 1356992771 -0800 +tagger Junio C Hamano <gitster@pobox.com> Mon Dec 31 14:26:11 2012 -0800 Git 1.8.1 -----BEGIN PGP SIGNATURE----- Signed-off-by: NAnand Kumria <wildfire@progsoc.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Paul Mackerras 提交于
The drop-down lists used for things like the criteria for finding commits (containing/touching paths/etc.) use a combobox if we are using the ttk widgets. By default the combobox exports its value as the selection when it is changed, which is unnecessary, and sometimes the combobox wouldn't release the selection, which is annoying. To fix this, we make these comboboxes not export their selection, and also clear their selection whenever they are changed. This makes them more like a simple selection of alternatives, improving the look and feel of gitk. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 01 4月, 2013 1 次提交
-
-
由 Gauthier Östervall 提交于
The Preferences dialog gives control of the colors of some elements of the gitk user interface, but many are hard-coded in the gitk script. In order to allow these to be customized through the gitk config file, these other colors are stored in variables which can be set in the config file, thus providing a way for color schemes to be stored and shared. For win32, this makes the default foreground color that of window text rather than button text. Signed-off-by: NGauthier Östervall <gauthier@ostervall.se> [paulus@samba.org: Reworded commit message to be clearer, changed filesepfgcolor to black] Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 30 1月, 2013 1 次提交
-
-
由 Christian Couder 提交于
gitk, when bound into the git.git project tree, used to live at the root level, but in 62ba5143 (Move gitk to its own subdirectory, 2007-11-17) it was moved to a subdirectory. The code used to track changes to TCLTK_PATH (which should cause gitk to be rebuilt to point at the new interpreter) was left in the main Makefile instead of being moved to the new Makefile that was created for the gitk project. Also add .gitignore file to list build artifacts for the gitk project. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 02 1月, 2013 1 次提交
-
-
由 Paul Mackerras 提交于
When there are more than $maxrefs descendant heads to display in the Branches field of the commit display, we currently just display "many", which is not very informative. To make the display more informative, we now look for "master" and whichever head is currently checked out, and display them even if there are too many heads to display them all. The display then looks like "Branches: master and many more (33)" for instance. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 01 1月, 2013 2 次提交
-
-
由 Paul Mackerras 提交于
This provides a control in the preferences pane for the limit on how many tags or heads are displayed with the commit details under the Branch(es), Precedes and Follows headings. This limit is now saved in ~/.gitk so that changes are persistent. This also applies word-wrapping to the list of tags or heads under the Branch, Precedes and Follows headings, so that long lists are more readable. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Paul Mackerras 提交于
Sometimes the code that divides commits up into arcs creates two successive arcs, but the commit between them (the commit at the end of the first arc and the beginning of the second arc) has only one parent and one child. If that commit is also the head of one or more branches, those branches get omitted from the "Branches" field in the commit display. The omission occurs because the commit gets erroneously identified as a commit which is part-way along an arc in [descheads]. This fixes it by changing the test to look at the arcouts array, which only contains elements for the commits at the start or end of an arc. Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 22 10月, 2012 6 次提交
-
-
由 Peter Krefting 提交于
Signed-off-by: NPeter Krefting <peter@softwolves.pp.se> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Stefan Haller 提交于
This fixes another regression that was introduced in b967135d ("gitk: Synchronize highlighting in file view when scrolling diff"): when searching for a string in tree mode, jumping to the next search hit would highlight the "Comments" entry in the file list. Signed-off-by: NStefan Haller <stefan@haller-berlin.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Stefan Haller 提交于
When clicking on the line that connects two commit nodes, gitk would bring up an error dialog saying "can't read "cflist_top": no such variable". This fixes a regression that was introduced with b967135d ("gitk: Synchronize highlighting in file view when scrolling diff"). Signed-off-by: NStefan Haller <stefan@haller-berlin.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Marcus Karlsson 提交于
When configured not to use themed widgets gitk may crash on launch with a message that says that the image "bm-left disabled bm-left-gray" doesn't exist. This happens when the left and right arrow buttons are created. The crash can be avoided by configuring the buttons differently depending on whether or not themed widgets are used. If themed widgets are not used then only set the images to bm-left and bm-right respectively, and keep the old behavior when themed widgets are used. The previous behaviour was added in f062e50f to work around a bug in Tk on OS X where the disabled state did not display properly. The buttons may still not display correctly, however the workaround added in f062e50f will still apply if gitk is used with themed widgets. Make gitk not crash on launch when not using themed widgets. Signed-off-by: NMarcus Karlsson <mk@acc.umu.se> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Andrew Wong 提交于
Signed-off-by: NAndrew Wong <andrew.kw.w@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Andrew Wong 提交于
The function includes a workaround for systems where F* keys are mapped to XF86_Switch_VT_* when modifiers are used. Signed-off-by: NAndrew Wong <andrew.kw.w@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 23 9月, 2012 4 次提交
-
-
由 Stefan Haller 提交于
On Mac, the back and forward buttons show an empty rectange instead of a grayed-out arrow when they are disabled. The reason is a Tk bug on Mac that causes disabled images not to draw correctly (not to draw at all, that is); see <https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.tcl/V-nW1JBq0eU>. To work around this, we explicitly provide gray images for the disabled state; I think this looks better than the default stipple effect that you get on Windows as well, but that may be a matter of taste. Signed-off-by: NStefan Haller <stefan@haller-berlin.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Stefan Haller 提交于
When typing in the "Search" field, select the current search result (so that it gets highlighted in orange). This makes it easier to understand what will happen if you then type Ctrl-S. Signed-off-by: NStefan Haller <stefan@haller-berlin.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Stefan Haller 提交于
When searching for text in the diff, and there are multiple occurrences of the search string, the current one is highlighted in orange, and the other ones in yellow. This makes it much easier to understand what happens when you then click the Search button or hit Ctrl-S repeatedly. Signed-off-by: NStefan Haller <stefan@haller-berlin.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Stefan Haller 提交于
Whenever the diff pane scrolls, highlight the corresponding file in the file list on the right. For a large commit with many files and long per-file diffs, this makes it easier to keep track of what you're looking at. This allows simplifying the prevfile and nextfile functions, because all they have to do is scroll the diff pane. In some situations we want to suppress this mechanism, for example when clicking on a file in the file list to select it, or when searching in the diff, in which case we want to highlight based on the current search hit and not the top line visible. In these cases it's not sufficient to set a "suppress" flag before scrolling and reset it afterwards, because the scrolltext notification is sent deferred from a timer or some such; so we need to remember the scroll position for which we want to suppress the auto-highlighting until the next call to scrolltext; a bit ugly, but does the job. Signed-off-by: NStefan Haller <stefan@haller-berlin.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 12 9月, 2012 1 次提交
-
-
- 09 9月, 2012 2 次提交
-
-
由 David Aguilar 提交于
Name the 'tagcontents' variable similarly to the rest of the variables cleared in the changedrefs() function. This makes the naming consistent and provides a hint that it should be cleared when reloading gitk's cache. Suggested-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NDavid Aguilar <davvid@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 David Aguilar 提交于
Tag contents, once read, are forever cached in memory. This makes gitk unable to notice when tag contents change. Allow users to cause a reload of the tag contents by using the "File->Reread references" action. Reported-by: NTim McCormack <cortex@brainonfire.net> Suggested-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NDavid Aguilar <davvid@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 8月, 2012 1 次提交
-
-
由 Aske Olsson 提交于
Check if GIT_TRACE env var is set and unset it if it is. If the environment var GIT_TRACE=1 exists gitk will fail when trying to find gitdir: $ git rev-parse --git-dir trace: built-in: git 'rev-parse' '--git-dir' .git Other git commands will also show debug output hence not work as intended. Signed-off-by: NAske Olsson <askeolsson@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 25 4月, 2012 1 次提交
-
-
由 Felipe Contreras 提交于
Meta1-F5 is commonly mapped by window managers and what not. Use Shift-F5 instead. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 03 4月, 2012 2 次提交
-
-
由 Pat Thoyts 提交于
The changes to the dialog window tree broke the preview of the selected font on the button. This corrects that issue. Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Pat Thoyts 提交于
In 8.5 the incr command creates the target variable if it does not exist but in 8.4 using incr on a non-existing variable raises an error. Ensure we have created our counter variable when creating the tabbed dialog for non-themed preferences. Reported-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 3月, 2012 1 次提交
-
-
由 Marcus Karlsson 提交于
In early days, all projects managed by git (except for git itself) had the product of a fairly mature development history in their first commit, and it was deemed unnecessary clutter to show additions of these thousands of paths as a patch. "git log" learned to show the patch for the initial commit without requiring --root command line option at 0f03ca94 (config option log.showroot to show the diff of root commits, 2006-11-23). Teach gitk to respect log.showroot. [paulus@samba.org: Cleaned up the Tcl a bit, use --bool on the git config call] Signed-off-by: NMarcus Karlsson <mk@acc.umu.se> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 23 3月, 2012 1 次提交
-
-
由 Paul Mackerras 提交于
Sometimes one wants to see the different between two commits that are a long distance apart in the graph display. This is difficult to do with the "Diff this -> selected" and "Diff selected -> this" menu items because the need to maintain the selection means that one can't use the find facilities or the reference list window to navigate from one to the other. This provides an alternative using the mark. Having found one commit, one marks it with the "Mark this commit" menu item, then navigates to the other commit and uses the new "Diff this -> marked commit" and/or "Diff marked commit -> this" menu items. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 19 3月, 2012 7 次提交
-
-
由 Paul Mackerras 提交于
On large repositories such as the Linux kernel, it can take quite a noticeable time (several seconds) for gitk to resolve short SHA1 IDs to their long form. This speeds up the process by maintaining lists of IDs indexed by the first 4 characters of the SHA1 ID, speeding up the search by a factor of 65536 on large repositories. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Jonathan Nieder 提交于
The following only concerns systems using X and the client-side font rendering framework from freedesktop.org. Windows and Mac OS X are not affected. Starting with version 8.5, Tk uses freetype and fontconfig by default to render fonts on platforms that support it. Gitk currently defaults to the font Helvetica for the interface and Courier for diffs, and both unfortunately look rather bad on screen in the default configuration on many Linux distros with anti-aliasing and poor hinting. It is better to default to "sans" and "monospace", which are mapped by fontconfig to some appropriate font of the sysadmin and user's choosing (typically Bitstream Vera Sans and Mono). The result looks more sensible and it makes gitk feel like a well-behaved software citizen since its fonts match other native apps. This patch does not change the appearance of gitk for users that have already run it, since gitk uses the remembered UI and diff font names from ~/.gitk. Requested-by: NMichael Biebl <biebl@debian.org> Reviewed-by: NJosh Triplett <josh@joshtriplett.org> Acked-by: NMark Hills <mark@pogo.org.uk> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Frédéric Brière 提交于
This prevents a search for a number like "105" on "All Fields" from matching against the raw author and commit timestamps. These timestamps were already not searchable by themselves, and the displayed format does not match the query string anyway. Signed-off-by: NFrédéric Brière <fbriere@fbriere.net> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Jim Meyering 提交于
Automake's contribution guidelines suggest using "git describe" output in commit logs to reference previous commits. By contrast, in coreutils, I had acquired the habit of using a bare SHA1 prefix (8 hex digits), since gitk creates clickable links for that, and not for "git describe" output. I prefer the readability of the full "git describe" output, yet want to retain the gitk links, so this renders as clickable not just SHA1-like strings, but also an SHA1-like string that is prefixed by "-g". Signed-off-by: NJim Meyering <meyering@redhat.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Pat Thoyts 提交于
Launching 'gitk -- .' or 'gitk -- ..\t' restricts the display to files under the given directory but the file list is left empty. This is because the path_filter function fails to match the filenames which are relative to the working tree to the filter which is filessytem relative. This solves the problem by making both names fully qualified filesystem paths before performing the comparison. Tested-by: NDavid Aguilar <davvid@gmail.com> Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Pat Thoyts 提交于
This commit converts the user preferences dialog into a tabbed property sheet grouping general properties, colours and font selections onto separate pages. The previous implementation was exceeding the screen height on some systems and this avoids such problems and permits extension using new pages in the future. If themed Tk is unavailable or undesired a reasonable facsimile of the tabbed notebook widget is used instead. Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
Previously, when run in a subdirectory, gitk would show the name of this subdirectory as title, which was misleading. When run with GIT_DIR set, it would show the cwd, which is even more misleading. In case of non-bare repos, the .git suffix in the path is skipped. Signed-off-by: NZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
-
- 08 10月, 2011 1 次提交
-
-
由 Jonathan Nieder 提交于
When commit 6e2dda35 (Add new keybindings, 2005-09-22) added vi-style keybindings to gitk (an excellent idea!), instead of adopting the usual "hjkl = left, down, up, right" bindings used by less, vi, rogue, and many other programs, it used "ijkl = up, left, down, right" to mimic the inverted-T formation of the arrow keys on a qwerty keyboard, in the style of Lode runner. So using 'j' and 'k' to scroll through commits produces utterly confusing results to the vi user, as 'k' moves down and 'j' moves to the previous commit. Luckily most non-vi-users are probably using an alternate set of keys (cursor keys or z/x + n/p) anyway. Switch to the expected vi/nethack convention. Requested-by: NJosh Triplett <josh@joshtriplett.org> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 24 7月, 2011 4 次提交
-
-
由 Yggy King 提交于
Gitk can search for commits touching a specified path. The search text is always treated as a regular expression, regardless of the matching option selected (Exact, IgnCase, or Regexp). In particular, backslashes escape the next character. This is inconvenient on Windows systems, where backslashes are the norm for path specifiers, for example when copy/pasting from Windows Explorer or a cmd shell -- these copy-pasted paths must be manually modified in the gitk search text edit box before they will work. This change uses the match option "Exact" to mean that a slash is a slash, not part of a regular expression. Backslashes are converted to frontslashes before searching, thus allowing easy copy/pasting of paths on Windows systems. If the previous behaviour of "touching paths" search is desired, simply select the "Regexp" search mode. One potential drawback is that the default setting for the match option ($findtype in the code) is "Exact", and so this change alters the default behaviour, which may confuse users and lead to bug reports. Signed-off-by: NYggy King <yggy@zeroandone.ca> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Martin von Zweigbergk 提交于
"git rev-parse --is-inside-work-tree" is currently used to determine whether to show modified files in gitk (the red and green fake commits). This does not work if the current directory is not inside the work tree, as can be the case e.g. if GIT_WORK_TREE is set. Instead, check if the repository is not bare and that we are not inside the .git directory. Signed-off-by: NMartin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Martin von Zweigbergk 提交于
Since 5024baa4 ([PATCH] Make gitk work when launched in a subdirectory, 2007-01-09), gitk has used 'git rev-parse --git-dir' to find the .git directory. However, gitk still first checks for the $GIT_DIR environment variable and that the value returned from git-rev-parse does not point to a file. Since git-rev-parse does both of these checks already, the checks can safely be removed from gitk. This makes the gitdir procedure small enough to inline. This cleanup introduces a UI regression in that the error message will now be "Cannot find a git repository here." even in the case where GIT_DIR points to a file, for which the error message was previously "Cannot find the git directory \"%s\".". It should be noted, though, that even before this patch, 'gitk --git-dir=path/to/some/file' would give the former error message. Signed-off-by: NMartin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Martin von Zweigbergk 提交于
It seems like gitk has been setting the global variable 'gitdir' at startup since aa81d974 (gitk: Fix Update menu item, 2006-02-28). It should therefore no longer be necessary to call the procedure with the same name (more than once to set the global variable). Remove the other call sites and use the global variable instead. Signed-off-by: NMartin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-