- 09 2月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
We already replace \n with \\n so that Tk widgets don't start a new display line with part of a file path which is just unlucky enough to contain an LF. But then its confusing to read a path whose name actually contains \n as literal characters. Escaping \ to \\ would make that case display as \\n, clarifying the output. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users want to navigate the file list shown in our branch browser windows using the keyboard. So we now support basic traversal with the arrow keys: Up/Down: Move the "selection bar" to focus on a different name. Return: Move into the subtree, or open the annotated file. M1-Right: Ditto. M1-Up: Move to the parent tree. M1-Left: Ditto. Probably the only feature missing from this is to key a leading part of the file name and jump directly to that file (or subtree). This change did require a bit of refactoring, to pull the navigation logic out of the mouse click procedure and into more generic routines which can also be used in bindings. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user has created (or deleted) a branch through an external tool, and uses Rescan, they probably are trying to make git-gui update to show their newly created branch. So now we load all known heads and update the branch menu during any rescan operation, just in-case the set of known branches was modified. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 29 1月, 2007 12 次提交
-
-
由 Shawn O. Pearce 提交于
To help the user visually see which lines are associated with each other in the file we attempt to sign a unique background color to each commit and then render all text associated with that commit using that color. This works out OK for a file which has very few commits in it; but most files don't have that property. What we really need to do is look at what colors are used by our neighboring commits (if known yet) and pick a color which does not conflict with our neighbor. If we have run out of colors then we should force our neighbor to recolor too. Yes, its the graph coloring problem. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Using a panedwindow to display the blame viewer's individual columns just doesn't make sense. Most of the important data fits within the columns we have allocated, and those that don't the leading part fits and that's good enough. There are just too many columns within this viewer to let the user sanely control individual column widths. This change shouldn't really be an issue for most git-gui users as their displays should be large enough to accept this massive dump of data. We now also have a properly working horizontal scrollbar for the current file data area. This makes it easier to get away with a narrow window when screen space is limited, as you can still scroll around within the file content. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I started to get confused about what each column meant in the blame viewer, and I'm the guy who wrote the code! So now git-gui hints to the user about what each column is by drawing headers at the top. Unfortunately this meant I had to use those dreaded frame objects which seem to cause so much pain on Windows. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we annotate a file and show its line data, we're already asking for copy and movement detection (-M -C). This costs extra time, but gives extra data. Since we are asking for the extra data we really should show it to the user. Now the blame UI has two additional columns, one for the original filename (in the case of a move/copy between files) and one for the original line number of the current line of code. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Anytime are about to open a pipe on what may be user data we need to make sure the value is escaped correctly into a Tcl list, so that the executed subprocess will receive the right arguments. For the most part we were already doing this correctly, but a handful of locations did not. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since we run blame incrementally in the background we might as well get as much data as we can from the file. Adding -M and -C definately makes it take longer to compute the revision annotations, but since they are streamed in and updated as they are discovered we'll get recent data almost immediately anyway. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users may need to be able to alter their user.name or user.email configuration settings. If they are mostly a git-gui user they should be able to view/set these important values from within the git-gui environment, rather than needing to edit a raw text file on their local filesystem. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Rather than using HEAD for the current branch, use the actual name of the current branch in the browser. This way the user knows what a browser is browsing if they open up different browsers while on different branches. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Real icons which seem to indicate going up to the parent (an up arrow) and a subdirectory (an open folder). Files are now drawn with the file_mod icon, like a modified file is. This just looks better as it is more consistent with the rest of our UI. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This rather huge change provides a browser for the current branch. The browser simply shows the contents of tree HEAD, and lets the user drill down through the tree. The icons used really stink, as I just copied in icon which we already had. I really need to replace the file_dir and file_uplevel icons with something more useful. If the user double clicks on a file within the browser we open it in a blame viewer. This makes use of the new incremental blame feature that Linus just added yesterday to core Git. Fortunately the feature will be in 1.5.0 final so we can rely on having it available here. Since the blame engine is incremental the user will get blame data for groups which can be determined early. Git will slowly fill in the remaining lines as it goes. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Running on Cygwin is different than if we were running through MinGW. In the Cygwin case we have cygpath available to us, we need to perform UNIX<->Windows path translation sometimes, and we need to perform odd things like spawning our own login shells to perform network operations. But in the MinGW case these don't occur. Git knows native Windows file paths, and login shells may not even exist. Now git-gui will avoid running cygpath unless it knows its on Cygwin. It also uses a different shortcut type when Cygwin is not present, and it avoids invoking /bin/sh to execute hooks if Cygwin is not present. This latter part probably needs more testing in the MinGW case. This change also improves how we start gitk. If the user is on any type of Windows system its known that gitk won't start right if ~/.gitk exists. So we delete it before starting if we are running on any type of Windows operating system. We always use the same wish executable which launched git-gui to start gitk; this way on Windows we don't have to jump back to /bin/sh just to go into the first wish found in the user's PATH. This should help on MinGW when we probably don't want to spawn a shell just to start gitk. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users may want to be able to read Git documentation, even if they are not command line users. There are many important concepts and terms covered within the standard Git documentation which would be useful to even non command line using people. We now try to offer an 'Online Documentation' menu option within the Help menu. First we try to guess to see what browser the user has setup. We default to instaweb.browser, if set, as this is probably accurate for the user's configuration. If not then we try to guess based on the operating system and the available browsers for each. We prefer documentation which is installed parallel to Git's own executables, e.g. `git --exec-path`/../Documentation/index.html, as that is how I typically install the HTML docs. If those are not found then we open the documentation published on kernel.org. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 27 1月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
OK, its official, I'm not reading documentation as well as I should be. Core Git's merge.summary configuration option is used to control the generation of the text appearing within the merge commit itself. It is not (and never has been) used to default the --no-summary command line option, which disables the diffstat at the end of the merge. I completely blame Git for naming two unrelated options almost the exact same thing. But its my own fault for allowing git-gui to confuse the two. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 26 1月, 2007 22 次提交
-
-
由 Shawn O. Pearce 提交于
Changed our private merge summary config option to be the same as the merge.summary option supported by core Git. This means setting the "Show Merge Summary" flag in git-gui will have the same effect on the command line. In the same vein I've also added merge.verbosity to the gui options, allowing the user to adjust the verbosity level of the recursive merge strategy. I happen to like level 1 and suggest that other users use that, but level 2 is the core Git default right now so we'll use the same default in git-gui. Unfortunately it appears as though core Git has broken support for the merge.summary option, even though its still in the documentation For the time being we should pass along --no-summary to git-merge if merge.summary is false. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Anytime we use a listbox to show branch names its possible for the listbox to exceed 10 entries (actually its probably very common). So we should always offer a scrollbar for the Y axis on these listboxes. I just forgot to add it when I defined them. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user is in the middle of a commit they have files which are modified. These may conflict with any merge that they may want to perform, which would cause problems if the user wants to abort a bad merge as we wouldn't have a checkpoint to roll back onto. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If an octopus merge goes horribly wrong git-merge will leave the working directory and index dirty, but will not leave behind a MERGE_HEAD file for a later commit. Consequently we won't know its a merge commit and instead would let the user resolve the conflicts and commit a single-parent commit, which is wrong. So now if an octopus merge fails we notify the user that the merge did not work, tell them we will reset the working directory, and suggest that they merge one branch at a time. This prevents the user from committing a bad octopus merge. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I got slightly confused when I did two merges in a row, as the status bar said "merge completed successfully" while the second merge was still running. Now we show what branches are actively being merged. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If you get into the middle of a merge that turns out to be horrible and just not something you want to do right now, odds are you need to run `git reset --hard` to recover your working directory to a pre-merge state. We now offer Merge->Abort Merge for exactly this purpose, however its also useful to thow away a non-merge, as its basically the same logic as `git reset --hard`. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
To allow users to merge local heads and tracking branches we now offer a dialog which lets the user select 1-15 branches and merge them using the stock `git merge` Grand Unified Merge Driver. Originally I had wanted to implement this merge internally within git-gui as I consider GUMD to be mostly Porcelain-ish, but the truth is it does its job exceedingly well and its a relatively complex chunk of code. I'll probably circle back later and try to remove the invocation of GUMD from git-gui, but right now it lets me get the job done faster. Users cannot start a merge if they are currently in the middle of one, or if they are amending a commit. Trying to do either is just stupid and should be stopped as early as possible. I've also made it simple for users to startup a gitk session prior to a merge by offering a Visualize button which runs `gitk $revs --not HEAD`, where $revs is the list of branches currently selected in the merge dialog. This makes it quite simple to find out what the damage will be to the current branch if you were to carry out the currently proposed merge. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Technically the new git-gc command is strictly Porcelain; its invoking multiple plumbing commands to do its work. Since git-gui tries to not rely on Porclain we shouldn't be invoking git-gc directly, instead we should perform its tasks on our own. To make this easy I've created console_chain, which takes a list of tasks to perform and runs them all in the same console window. If any individual task fails then the chain stops running and the window shows a failure bar. Only once all tasks have been completed will it invoke console_done with a successful status. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because I want to be able to run multiple output-producing commands in a single 'console' window within git-gui I'm refactoring the console handling routines to require the "after" argument of console_exec. This should specify a procedure to execute which will receive two args, the first is the console window handle and the second is the status of the last command (0 on failure, 1 on success). A new procedure console_done can be passed to the last console_exec command to forward perform all cleanup and enable the Close button. Its status argument is used to update the final status bar on the bottom of the console window. This isn't any real logic changing, and no new functionality is in this patch. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Right now `git-push -v` is actually not that verbose; it merely adds the URL it is pushing to. This can be informative if you are pushing to a configured remote, as you may not actually remember what URL that remote is connected to. That detail can be important if the push fails and you attempt to communicate the errors to a 3rd party to help you resolve the issue. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because we aren't going to support single click pulling of changes from an existing remote anytime in the near future, I'm moving the code which used to perform that action. Hopefully we'll be able to do something like it in the near-future, but also support local branches just as easily. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because its common for some users to push topic branches to a remote repository for review and merging by other parties, users need an easy way to push one or more branches to a remote repository without needing to edit their .git/config file anytime their set of active branches changes. We now provide a basic 'Push...' menu action in the Push menu which opens a dialog allowing the user to select from their set of local branches (refs/heads, minus tracking branches). The user can designate which repository to send the changes to by selecting from an already configured remote or by entering any valid Git URL. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Anytime we are using lsearch we are doing [lsearch -sorted] and we are applying it to file paths (or file path like things). Its valid for these to contain special glob characters, but when that happens we do not want globbing to occur. Instead we really need exact match semantics. Always supplying -exact to lsearch will ensure that is the case. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I just noticed that a file was always jumping to compare against HEAD and the index during a refresh, even if the diff viewer was comparing the index against the working directory prior to the refresh. The bug turned out to be caused by a foreach loop going through all file list names searching for the path. Since $ui_index was the first one searched and the file was contained in that file list the loop broke out, leaving $w set to $ui_index when it had been set by the caller to $ui_workdir. Silly bug caused by using a parameter as a loop index. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Its pointless to switch to the current branch, so don't do it. We are already on it and the current index and working directory should just be left alone. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The Pull menu as it stands right now is a really horrible idea. Most users will have too many branches show up in this menu, and what with the new globbing syntax for fetch entries we were offering up possible merging that just isn't really valid. So this menu is dead and will be rewritten to support better merge capabilities. The Branch menu shouldn't include a separator entry if there are no branches, it just looks too damn weird. This can happen in an initial repository before any branches have been created and before the first commit. The Fetch and Push menus should just be organized around their own menus rather than being given the menu to populate. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'm a fool and previously used a text widget configured with a height of 1 and special bindings to handle focus traversal rather than the already built (and properly behaved) entry widget. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The stat frame was right on the edge of the window on Mac OS X, making the frame's border blend in with the window border. Not exactly the effect I had in mind. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that recent versions of gitk (shipping with at least git 1.5.0-rc1 and later) actually accept command line revision specifiers without crashing on internal Tk errors we can offer the 'Visualize All Branches' menu item in the Repository menu on Mac OS X. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Apparently a "feature" of Tcl/Tk on Mac OS X is that a disabled text widget cannot receive focus or receive a selection within it. This makes the diff viewer almost useless on that platform as you cannot select individual parts of the buffer. Now we force focus into the diff viewer when its clicked on with button 1. This works around the feature and allows selection to work within the viewer just like it does on other less sane systems, like Microsoft Windows. 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 committing changes its useless to have trailing whitespace on the end of a line within the commit message itself; this serves no purpose beyond wasting space in the repository. But it happens a lot on my Mac OS X system if I copy text out of a Terminal.app window and paste it into git-gui. We now clip any trailing whitespace from the commit buffer when loading it from a file, when saving it out to our backup file, or when making the actual commit object. I also fixed a bug where we lost the commit message buffer if you quit without editing the text region. This can happen if you quit and restart git-gui frequently in the middle of an editing session. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 25 1月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
If we are displaying a diff for a DOS-style (CRLF) formatted file then the Tk text widget would normally show the CR at the end of every line; in most fonts this will come out as a square box. Rather than showing this character we'll tag it with a tag which forces the character to be elided away, so its not displayed. However since the character is still within the text buffer we can still obtain it and supply it over to `git apply` when staging or unstaging an individual hunk, ensuring that the file contents is always fully preserved as-is. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Just like `git-add --interactive` we can now stage and unstage individual hunks within a file, rather than the entire file at once. This works on the basic idea of scanning backwards from the mouse position to find the hunk header, then going forwards to find the end of the hunk. Everything in that is sent to `git apply --cached`, prefixed by the diff header lines. We ignore whitespace errors while applying a hunk, as we expect the user's pre-commit hook to catch any possible problems. This matches our existing behavior with regards to adding an entire file with no whitespace error checking. Applying hunks means that we now have to capture and save the diff header lines, rather than chucking them. Not really a big deal, we just needed a new global to hang onto that current header information. We probably could have recreated it on demand during apply_hunk but that would mean we need to implement all of the funny rules about how to encode weird path names (e.g. ones containing LF) into a diff header so that the `git apply` process would understand what we are asking it to do. Much simpler to just store this small amount of data in a global and replay it when needed. I'm making absolutely no attempt to correct the line numbers on the remaining hunk headers after one hunk has been applied. This may cause some hunks to fail, as the position information would not be correct. Users can always refresh the current diff before applying a failing hunk to work around the issue. Perhaps if we ever implement hunk splitting we could also fix the remaining hunk headers. Applying hunks directly means that we need to process the diff data in binary, rather than using the system encoding and an automatic linefeed translation. This ensures that CRLF formatted files will be able to be fed directly to `git apply` without failures. Unfortunately it also means we will see CRs show up in the GUI as ugly little boxes at the end of each line in a CRLF file. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-