- 05 9月, 2008 8 次提交
-
-
由 Alexander Gavrilov 提交于
If an untracked file is selected, F5 and other manual rescan synonyms would try to select a tracked file instead. Also, clicking on an icon in the unstaged changes list skips over untracked files, unless the file clicked is untracked itself. The objective is to make it easier to ignore untracked files showing up in the Unstaged Changes list, and ensure that no modifications to tracked objects are left unstaged. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Generalize the next_diff system, and implement auto-reselection for merge tool resolution and reshow_diff. Also add auto-selection of diffs after rescan, if no diff is already selected. New auto-select rules: - Rescan auto-selects the first conflicting file, or if none a modified tracked file, if nothing was selected previously. - Resolving a conflict auto-selects the nearest conflicting file, or nothing if everything is resolved. - Staging the last remaining hunk auto-selects the nearest modified staged file. - Staging a file through its icon auto-selects the nearest file. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Support _U (local deleted, remote modified) and UT (file type changed in conflict) modes. Note that 'file type changed' does not refer to changes in the executable bit, instead it denotes replacing a file with a link, or vice versa. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Add native support for Araxis Merge, WinMerge and Perforce merge. Custom merge tools are not implemented by mergetool.tcl; besides, native support allows constructing the command lines in a more intelligent way. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Prevent staging files with conflict markers by clicking on the icon in the 'Unstaged Changes' list. Instead, pretend that the user clicked the name, and show the diff. Originally it made some sense to allow staging conflicting files, because git-gui did not provide any tools to resolve them from within the GUI. But now that we have added mergetool capabilities, it is more likely to cause accidental and non-undoable errors. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Adds an item to the diff context menu in conflict mode, which invokes a merge tool for the selected file. Tool command-line handling code was ported from git-mergetool. Automatic default tool selection and custom merge tools are not supported. If merge.tool is not set, git-gui defaults to meld. This implementation uses a checkout-index hack in order to retrieve all stages with autocrlf and filters properly applied. It requires temporarily moving the original conflict file out of the way. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
If the file has merge conflicts, show a special version of the diff context menu, which includes conflict resolution commands instead of Stage Hunk/Line. This patch only supports resolving by discarding all sides except one. Discarding is the only way to resolve conflicts involving symlinks and/or deletion, excluding manual editing. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Christian Stimming 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 02 9月, 2008 3 次提交
-
-
由 Shawn O. Pearce 提交于
* maint: git-gui: Fix string escaping in po2msg.sh git gui: show diffs with a minimum of 1 context line Conflicts: lib/option.tcl
-
由 Alexander Gavrilov 提交于
Escape '$', because otherwise git-gui crashes while trying to load malformed Japanese localization strings. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Clemens Buchacher 提交于
Staging hunks without context does not work, because line number information would have to be recomputed for individual hunks. Since it is already possible to stage individual lines using 'Stage Line for Commit', zero context diffs are not really necessary for git gui. Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 25 8月, 2008 5 次提交
-
-
由 Alexander Gavrilov 提交于
Add a command-line option to make git gui blame automatically scroll to a specific line in the file. Useful for integration with other tools. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Invoke diff-tree between the commit and its parent, and use the hunks to fix the target line number, accounting for addition and removal of lines. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Add a context menu item that switches the view to the parent of the commit under cursor. It is useful to see how the file looked before the change, and find older changes in the same lines. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Add a context menu command to load commits that are within a certain time range from the selected commit into gitk. It can be useful for understanding of the code, especially if the repository is imported from a VCS that does not support atomic commits. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Gustaf Hendeby 提交于
Signed-off-by: NGustaf Hendeby <hendeby@isy.liu.se> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 13 8月, 2008 2 次提交
-
-
由 Alexandre Bourget 提交于
Simply.. Signed-off-by: NAlexandre Bourget <alexandre.bourget@savoirfairelinux.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexandre Bourget 提交于
Signed-off-by: NAlexandre Bourget <alexandre.bourget@savoirfairelinux.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 10 8月, 2008 1 次提交
-
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 05 8月, 2008 1 次提交
-
-
由 Johannes Sixt 提交于
The new execdir is two levels below the root directory, while the old execdir 'bin' was only one level below. This commit adapts the discovery of oguilib that uses relative paths accordingly. We determine whether we have the extra level in the same way in which the Makefile defines sharedir, i.e. whether the last directory part is 'git-core'. Inspired-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 04 8月, 2008 3 次提交
-
-
由 Michele Ballabio 提交于
This should help tranlators that need to reorder words and strings. Original explanation by Christian Stimming. Also remove unneeded backslashes. Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Michele Ballabio 提交于
Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 しらいしななこ 提交于
This updates Japanese translation to match the updated git-gui.pot. Signed-off-by: Nしらいしななこ <nanako3@lavabit.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 03 8月, 2008 3 次提交
-
-
由 Mikael Magnusson 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Christian Stimming 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 30 7月, 2008 4 次提交
-
-
由 Steffen Prohaska 提交于
git-gui needs bindir in PATH to be able to run 'git'. bindir however is not necessarily in PATH if started directly through a Windows shortcut. Therefore, we used to add the directory git-gui is located in. But with the new 'libexec/git-core' layout this directory is no longer identical to bindir. This commit modifies the wrapper script to discover the bindir and add it to PATH. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Steffen Prohaska 提交于
Instead of using an absolute path, git-gui can discover its gui library using a relative path from execdir. We want to use the relative path discovery on MinGW to avoid issues with translation of absolute paths. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Steffen Prohaska 提交于
We always wanted the library for git-gui to install into the $prefix/share directory, not $prefix/libexec/share. All of the files in our library are platform independent and may be reused across systems, like any other content stored in the share directory. Our computation of where our library should install to was broken when git itself started installing to $prefix/libexec/git-core, which was one level down from where we expected it to be. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Back in 15430be5 ("Look for gitk in $PATH, not $LIBEXEC/git-core") git-gui learned to use [_which gitk] to locate where gitk's script is as Git 1.6 will install gitk to $prefix/bin (in $PATH) and all of the other tools are in $gitexecdir. This failed on Windows because _which adds the ".exe" suffix as it searches for the program on $PATH, under the assumption that we can only execute something from Tcl if it is a proper Windows executable. When scanning for gitk on Windows we need to omit the ".exe" suffix. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 27 7月, 2008 4 次提交
-
-
由 Alexander Gavrilov 提交于
It is especially useful for Stage/Unstage Line, because they invoke full state scan and diff reload, which originally would reset the scroll position to the top of the file. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
It was positioned incorrectly (offset by one position) if the menu had a tear-off handle. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Johannes Sixt 提交于
Assume that we want to commit these states: Old state == HEAD Intermediate state New state -------------------------------------------------------- context before context before context before old 1 new 1 new 1 old 2 old 2 new 2 context after context after context after that is, want to commit two changes in this order: 1. transform "old 1" into "new 1" 2. transform "old 2" into "new 2" [This discussion and this patch is about this very case and one other case as outlined below; any other intermediate states that one could imagine are not affected by this patch.] Now assume further, that we have not staged and commited anything, but we have already changed the working file to the new state. Then we will see this hunk in the "Unstaged Changes": @@ -1,4 +1,4 @@ context before -old 1 -old 2 +new 1 +new 2 context after The obvious way to stage the intermediate state is to apply "Stage This Line" to "-old 1" and "+new 1". Unfortunately, this resulted in this intermediate state: context before old 2 new 1 context after which is not what we wanted. In fact, it was impossible to stage the intermediate state using "Stage Line". The crux was that if a "+" line was staged, then the "-" lines were converted to context lines and arranged *before* the "+" line in the forged hunk that we fed to 'git apply'. With this patch we now treat "+" lines that are staged differently. In particular, the "-" lines before the "+" block are moved *after* the staged "+" line. Now it is possible to get the correct intermediate state by staging "-old 1" and "+new 1". Problem solved. But there is a catch. Noticing that we didn't get the right intermediate state by staging "-old 1" and "+new 1", we could have had the idea to stage the complete hunk and to *unstage* "-old 2" and "+new 2". But... the result is the same. The reason is that there is the exact symmetric problem with unstaging the last "-" and "+" line that are in adjacent blocks of "-" and "+" lines. This patch does *not* change the way in which "-" lines are *unstaged*. Why? Because if we did (i.e. move "+" lines before the "-" line after converting them to context lines), then it would be impossible to stage this intermediate state: context before old 1 new 2 context after that is, it would be impossible to stage the two independet changes in the opposite order. Let's look at this case a bit further: The obvious way to get this intermediate state would be to apply "Stage This Line" to "-old 2" and "+new 2". Before this patch, this worked as expected. With this patch, it does not work as expected, but it can still be achieved by first staging the entire hunk, then *unstaging* "-old 1" and "+new 1". In summary, this patch makes a common case possible, at the expense that a less common case is made more complicated for the user. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Johannes Sixt 提交于
To "Stage/Unstage Line" we construct a patch that contains exactly one change (either addition or removal); the hunk header was forged by counting the old side and adjusting the count by +/-1 for the new side. But when we counted the context we never counted the changed line itself. If the hunk had only one removal line and one line of context, like this: @@ -1,3 +1,2 @@ context 1 -removal context 2 We had constructed this patch: @@ -1,2 +1,1 @@ context 1 -removal context 2 which does not apply because git apply deduces that it must apply at the end of the file. ("context 2" is considered garbage and ignored.) The fix is that removal lines must be counted towards the context of the old side. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 26 7月, 2008 2 次提交
-
-
由 Shawn O. Pearce 提交于
In Git 1.6 and later gitk is in $prefix/bin while git-gui and all of the other commands are in $gitexecdir, which is typically not the same as $prefix/bin. So we cannot launch $gitexecdir/gitk and expect it to actually start gitk properly. By allowing git-gui to locate the script via $PATH and then using exactly that path when we source it during the application start we can correctly run gitk on any Git 1.5 or later. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Abhijit Menon-Sen 提交于
Signed-off-by: NAbhijit Menon-Sen <ams@toroid.org> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 17 7月, 2008 4 次提交
-
-
由 Alexander Gavrilov 提交于
Add a context menu item to invoke blame -C -C -C on a chunk of the file. The results are used to update the 'original location' column of the blame display. The chunk is computed as the smallest line range that covers both the 'last change' and 'original location' ranges of the line that was clicked to open the menu. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Currently 'git-gui blame' does not kill its back-end process, hoping that it will die anyway when the pipe is closed. However, in some cases the process works for a long time without producing any output. This behavior results in a runaway CPU hog. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
On huge repositories, -C -C can be way too slow to be unconditionally enabled, and it can also be useful to control its precision. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Alexander Gavrilov 提交于
Apply the work-around for checking the executable permission of hook files not only on Cygwin, but on Windows in general. Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-