- 12 11月, 2006 23 次提交
-
-
由 Shawn O. Pearce 提交于
Apparently <Button-3> doesn't work on my single button PowerBook mouse under Mac OS X. I'm guessing this is because Tk is stealing every event and doesn't realize that Control-Button-1 is actually supposed to invoke the context menu on this platform. So now we have a utility procedure is_MacOSX to guess if we are running on a Mac OS X system, and if so setup Control-Button-1 to also activate what Button-3 should have. This does mean that I need to stay away from using Control-Button-1 as a binding in any other context. Of course we should use $M1B for that, which is M1 (aka Command) on Mac OS X so that shouldn't prove to be a problem. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The native Tk font system is actually quite powerful and has the nice property that modifications to a named font are immediately reflected throughout all widgets currently displayed. This really saves us from needing to write all of the reconfigure code as part of our font display. I also fixed the way we detect and apply the system font on the main UI widgets as although it worked on a Windows 2000 system it does not work at all on my Mac OS 10.4 system. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When the user has enabled the Trust File Modification Timestamp option then we may display a file as being modified yet that file may not have a difference. When the user clicks on that file we wind up displaying an empty diff viewer, which makes no sense to the user. So instead if we get an empty diff and the user has this option enabled and the file's current state is _M (no change in index but the working file appears modified) then run a quick update-index on just that file and remove it from the list of modified files. We also give the user a quick dialog stating we are removing it, and why. Usually I don't run into this situation when I have the Trust File Modification Timestamp option enabled, so its not that annoying to have a dialog pop open to remind me why there are no differences. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because the diff area is one of the most important areas to be able to read users should be able to increase or decrease the size of the font used within that area. Currently we save that back to the global configuration, even if it may have originated from the local repository configuration. This is probably going to be considered to be a bug by at least one user who wants some sort of different font within a given repository, but I'm just going to ignore the problem for now. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Rather than hardcoding our fonts to something that I thought was reasonable, guess font_ui off the font used by the system in the menu bar. This way the application conforms by default to whatever the user's desktop is setup to. We also now let the user supply font configuration through their repository configuration as gui.fontui (the overall UI font) and gui.fontdiff (the font used for the diff viewer). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we sign off on a commit we want to add a blank line between whatever is in the commit buffer and the new Signed-off-by line, unless there already is a Signed-off-by (or Acked-by) tag at the end of the buffer already. This change makes us do the right thing more often. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The mouse cursor (at least on Windows) seemed to be picking up the cursor from the sash controls and then never resetting itself back to the standard text cursor (the I-beam) when it was over a text area that the user can edit (like the commit buffer) or over a text area the user can copy from (like the diff viewer). So now we always set the cursor to left_ptr (which according to the Tk documentation should be available everywhere) and only for the two text areas which we use to list file names, as the user clicks in these but is not permitted to select text. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This change adds a context menu to the commit message buffer providing fast access to the contents of the Edit menu, and to the console text buffer, providing easy ways to copy selections of the buffer or the entire buffer. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Make sure the file_lists array has both elements set at all times, otherwise we get Tcl errors during mouse clicks in the file list areas due to the list not being defined. Also added M1-A as a keyboard binding within the console window text area. This lets users select all text easily and copy it to the clipboard. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
A number of lines were line wrapping in a rather ugly way when opened in vim with line numbers enabled, so I split most of these lines over two lines using a sensible wrapping policy. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The gui.geometry config value was starting to contain the odd string \\{ as part of its value due to the way the Tcl lists were being supplied to git repo-config. Now we write out only three values: the overall window geomtry, the y position of the horizontal sash, and the x position of the vertical sash. All other data is skipped, which makes the gui.geometry value simpler. While debugging this I noticed that the save_my_config procedure was being invoked multiple times during exit due to do_quit getting invoked over and over again. So now we set a flag in do_quit and don't perform any of our "at exit" type of logic if we've already been through the do_quit procedure once. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Added an extra blank line between the first line of each error message and the rest of the message, as usually the rest of the message is coming from Tcl or is the stderr output of a git command we tried to invoke. This makes it easier to read the output (if any). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Rather than drawing our own toplevel for error messages we really should just use the the native tk_messageBox command to display any error messages. Major benefits for doing so are: - automatically centers over main window; - less code required on our part in git-gui; - includes a nifty error icon on most systems; - better fits the look-and-feel of the operating system. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I found difffont to be a very awkward varible name, due to the use of three f's in a row. So use easier to read variable names. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we reshow the current diff file it can be faster to just fetch the value from the file_states array than it is to ask for all paths whose name exactly matches the one we want to show. This is because [array names -exact] is O(n) in the number of files. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we commit we know that whatever was in the index went as part of the commit. Since we generally assume that the user does not update the index except through our user interface we can be reasonably certain that any file which was marked as A/M/D in the index will have had that A/M/D state changed to an _ (not different) by the commit. We can use this knowledge to update the user interface post commit by simply updating the index part of the file state of all files whose index state was A/M/D to _ and then removing any file memory any which wound up with a final state of __ (not different anywhere). Finally we redraw the file lists and update the diff view. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we are given a file whose path name contains an LF (\n) we now escape it by inserting the common escape string \n instead of the LF character whenever we display the name in the UI. This way the text fields don't start to span multiple lines just to display one file, and it keeps the line numbers correct within the file lists. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we did a rescan to update the file lists we lost the tag which indicated which file was currently in the diff viewer. This occurs because we delete every line from the two file list boxes (thus removing the tag) and then redisplay the diff in the diff viewer but then fail to restore the tag in the file list. Now we restore that tag by searching for the file in the file lists and adding the tag back when the diff viewer displays something. We also no longer obtain the file path directly from the file list text box. Instead we now keep two Tcl lists, one for each file list, holding the file names in sorted order. These lists can be searched with the native [lsearch -sorted] operation (which should be faster than our crude bsearch) or can be quickly accessed by index to return the file path. This should help make things safer should we ever be given a file name which contains an LF within it (as that would span two lines in the file list, not one). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we load a message file (e.g. MERGE_MSG) or we have just finished making a commit and are clearing out the commit buffer we should also clear out the undo/redo stack associated with that buffer. The prior undo/redo stack has no associated with the new content and therefore is not useful to the user. Also modified the sign-off operation to perform the entire update in a single undo/redo operation, allowing the user to undo the signoff in case they didn't actually want to do that. I also noticed what may be a crash on Windows related to the up and down arrow keys navigating within the diff viewer. Since I got back no stack trace (just an application exit with a loss of the commit message) I suspect that the binding to scroll the text widget crashed with an error and the wish process just terminated. So now we catch (and ignore) any sort of error related to the arrow keys in the diff viewer. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users have come to expect basic editing features within their applications, such as cut/copy/paste/undo/redo/select-all. I found these features to be lacking in git-gui so now we have them. I also added basic keyboard bindings for the diff viewing area so that the arrow keys move around single units (lines or columns) and the M1-X/C keys will copy the selected text and the M1-A key will select the entire diff. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that we call the update-index all files action "Include All" it makes more sense to make this M1-I (so Control-I or Command-I depending on platform) than M1-U, which stood for update but is somewhat confusing to users. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 09 11月, 2006 4 次提交
-
-
由 Shawn O. Pearce 提交于
I started to find it very annoying that my test application kept opening at the wrong location on my desktop, so now we save the basic window geometry and sash positions into the config file as gui.geometry. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Caching the Signed-Off-By line isn't very important (as its not performance critical). The major improvement here is that we now report an error to the user if we can't obtain their name from git-var. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
There's really no great reason to show the entire commit object id within the GUI, especially if the user is unable to copy and paste it into another interface such as gitk or a terminal window. So we'll just show them the first 8 digits and hope that is unique within their repository. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
At least one user was confused by the term 'check-in'; he thought that clicking that button would commit just that one file, but he wanted to include all modified files into his next commit. Since git doesn't really have a check-in concept this really was poor language to use. Git does have an update-index concept but that is a little too low level to show to the user. So instead we now talk about including files in a commit. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 08 11月, 2006 12 次提交
-
-
由 Shawn O. Pearce 提交于
When a file jumps between the file lists due to its state changing we crashed thanks to a stale variable reference within the procedure as we tried to setup the new icon. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If there are modified files present in the working directory then we should not let the user perform a pull as it may fail due to the modified files being uncommitted but needing to be merged at the file level. Yes there are many cases where a merge will complete successfully even though there are modified or untracked files sitting in the working directory. But users generally shouldn't be attempting merges like that, and if they are they probably are advanced enough to just use the command line and bypass this little safety check. We also no longer run a rescan after a successful pull has completed. Usually this is unnecessary as a successful pull won't leave modified files laying around. Instead we just update our HEAD and PARENT values with the new commit, if there is one. Unfortunately this does let the user get into an insane state as there are bugs in core Git's git-pull and git-merge programs where the exit status is sent back as a 0 rather than non-0 when a failure is detected. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we have the index locked then no pull command is allowed to proceed (as it would fail to get the index lock itself). So disable the pull menu items when we are doing any index based operations. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The user must not modify the index while a git pull operation is running, doing so might cause problems for the merge driver and specific strategy being used. Normally on the command line people are just really good and don't try to run index altering operations while they are also running a pull. But in a slick GUI like git-gui we can't trust the user quite as much. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
On very large projects (~1000 files) on Windows systems the update-index --refresh stage of the rescan process takes a nontrival amount of time. If the user is generally very careful with their file modification such that the modification timestamp of the file differs only when the content also differs then we can skip this somewhat expensive step and go right to the diff-index and diff-files processes. We save the user's prefernce in the current repository if they modify the setting during a git-gui session, but we also load it through our dump of repo-config --list so the user could move it to their ~/.gitconfig file if they wanted it globally disabled. We still keep update-index --refresh enabled by default however, as most users will probably want it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Most users of git-gui probably shouldn't be invoking git repack directly; instead we should be looking at how many loose objects they have and how many active packs they have and making the decision for them. But that's more work to code, and there's always going to be discussion about what is the right default threshold and how do we know that the user is willing to do the repack when we decide its time, etc. So instead we'll just keep it simple and offer up the menu option. Unfortunately right now we get now progress indication back from git-pack-objects as its being invoked not through a tty, which makes it disable progress output and the git-repack.sh wrapper won't let us pass through --progress. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since Tk will only supply new space gained from growing the top level to the bottom/right most widget within a panedwindow and most users will be growing a git-gui main window for the purposes of seeing more of the currently shown diff, flipping the order around makes Tk do what the user wants by default. Of course because we also removed the paned window from the commit buffer area it is now impossible to increase the visible space for the commit message. But I don't see this as a huge concern right now as its actually very awkward to try and balance three paned window dividers within the same top level window. We could always add it back if users really want to expand the commit buffer and see more. I also corrected a number of bugs that I accidentally introduced in the last commit. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Removed as much as possible from the merge_state proc, which is where we spent most of our time before UI update. This change makes our running time match that of git status, except that we then need about 7 additional seconds to draw 6900 files on screen. Apparently the [array names a -exact $v] operator in Tcl is O(n) rather than O(1), which is really quite disappointing given that each array can only have one entry for a given value. Switching to a lookup with a catch (whose error we ignore) runs in O(1) time and bought us most of that improvement. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Loading 6900 newly added files required about 90 seconds on one system. This is just far too long to perform a "status" type of operation. git-status on the same system completes in just 8.2 seconds if it is redirected to /dev/null. Most of our performance improvement comes from moving all of the UI updating out of the main fileevent handlers for the status process. Instead we are only updating the file_states array and then only doing the UI update when all states are known and have been finally determined. The rescan execution is now down to almost 30 seconds for the same case, a good (but not really all that impressive) improvement. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we were receiving a lot of output from diff-index we split records at the wrong locations and started using the file status information (mode and SHA1s) as path names, and then proceeded to try to use part of the path names as status data. This caused all sorts of havoc. So I rewrote the parsing implementation to scan for the pair of null bytes along the buffer and stop scanning (waiting for more data) if both can't be found during this event. This seems to work well under high load (like when processing 6,983 added files). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 07 11月, 2006 1 次提交
-
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-