- 08 5月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
Like the console procs I have moved the code related to merge support into their own namespace, so that they are isolated from the rest of the world. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users who are used to vi and recent versions of gitk may want to scroll the diff region using vi style keybindings. Since these aren't bound to anything else and that widget does not accept focus for data input, we can easily support that too. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'm finding it difficult to work with a 6,000+ line Tcl script and not go insane while looking for a particular block of code. Since most of the program is organized into different units of functionality and not all users will need all units immediately on startup we can improve things by splitting procs out into multiple files and let auto_load handle things for us. This should help not only to better organize the source, but it may also improve startup times for some users as the Tcl parser does not need to read as much script before it can show the UI. In many cases the user can avoid reading at least half of git-gui now. Unfortunately we now need a library directory in our runtime location. This is currently assumed to be $(sharedir)/git-gui/lib and its expected that the Makefile invoker will setup some sort of reasonable sharedir value for us, or let us assume its going to be $(gitexecdir)/../share. We now also require a tclsh (in TCL_PATH) to just run the Makefile, as we use tclsh to generate the tclIndex for our lib directory. I'm hoping this is not an unncessary burden on end-users who are building from source. I haven't really made any functionality changes here, this is just a huge migration of code from one file to many smaller files. All of the new changes are to setup the library path and install the library files. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 03 5月, 2007 7 次提交
-
-
由 Shawn O. Pearce 提交于
Whenever we want to execute a git subcommand from the plumbing layer (and on rare occasion, the more porcelain-ish layer) we tend to use our proc wrapper, just to make the code slightly cleaner at the call sites. I wasn't doing that in a couple of places, so this is a simple cleanup to correct that. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Rather than passing "-font font_ui" to every widget that we create we can instead reconfigure the option database for all widget classes to use our font_ui as the default widget font. This way Tk will automatically setup their defaults for us, and we can reduce the size of the application. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
An earlier change tossed these optionMenu font configurations all over the code, when really we can just rename the proc to a hidden internal name and provide our own wrapper to install the font configuration we really want. We also don't need to set these option database entries in all of the procedures that open dialogs; instead we should just set one time, them after we have the font configuration ready for use. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since Tk automatically wraps lines for us in tk_messageBox widgets we don't need to try to wrap them ourselves. Its actually worse that we linewrapped this here in the script, as not all fonts will render this dialog nicely. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
A coworker who was new to git-gui recently tried to make an octopus merge when he did not quite mean to. Unfortunately in his case the branches had file level conflicts and failed to merge with the octopus strategy, and he didn't quite know why this happened. Since most users really don't want to perform an octopus merge this additional safety valve in front of the merge process is a good thing. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that the command line git-commit has made displaying the subject (first line) of the newly created commit popular we can easily do the same thing here in git-gui, without the ugly part of forking off a child process to obtain that first line. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the path of our wish executable that are running under contains spaces we need to make sure they are escaped in a proper Tcl list, otherwise we are unable to start gitk. Reported by Randal L. Schwartz on #git. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 24 4月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Uwe Kleine-König discovered git-gui mangled his surname and did not send the proper UTF-8 byte sequence to git-commit-tree when his name appeared in the commit message (e.g. Signed-Off-By line). Turns out this was related to other trouble that I had in the past with trying to use "fconfigure $fd -encoding $enc" to select the stream encoding and let Tcl's IO engine do all of the encoding work for us. Other parts of git-gui were just always setting the file channels to "-encoding binary" and then performing the encoding work themselves using "encoding convertfrom" and "convertto", as that was the only way I could make UTF-8 filenames work properly. I found this same bug in the amend code path, and in the blame display. So its fixed in all three locations (commit creation, reloading message for amend, viewing message in blame). Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 15 4月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
By showing the basename of the directory very early in the title bar I can more easily locate a particular git-gui session when I have 8 open at once and my Windows taskbar is overflowing with items. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 05 4月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
If we generate a blame status string before we have obtained any annotation data at all from the input file, or if the input file is empty, our total_lines will be 0. This causes a division by 0 error when we blindly divide by the 0 to compute the total percentage of lines loaded. Instead we should report 0% done. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 04 4月, 2007 4 次提交
-
-
由 Shawn O. Pearce 提交于
If a dialog/window has a default button registered not every platform associates the return key with that button, but all users do. We have to register the binding of the return key ourselves to make sure the user's expectations of pressing return will activate the default button are met. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Eygene Ryabinkin 提交于
Many git-gui messages were broken into a multiple lines to make good paragraph width. Unfortunately in reality it breaks the paragraph width completely, because the dialog window width does not coincide with the paragraph width created by the current font. Tcl/Tk's standard dialog boxes are breaking the long lines automatically, so it is better to make long lines and let the interpreter do the job. Signed-off-by: NEygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Eygene Ryabinkin 提交于
Made the default buttons on the dialog active and focused upon the dialog appearence. Bound 'Escape' and 'Return' keys to the dialog dismissal where it was appropriate: mainly for dialogs with only one button and no editable fields, but on console output dialogs as well. Signed-off-by: NEygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Eygene Ryabinkin 提交于
Some parts of git-gui were not respecting the default GUI font. Most of them were catched and fixed. Signed-off-by: NEygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 13 3月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
I got a little surprise one day when I tried to run 'git gui version' outside of a Git repository to determine what version of git-gui was installed on that system. Turns out we were doing the repository check long before we got around to command line argument handling. We now look to see if the only argument we have been given is 'version' or '--version', and if so, print out the version and exit immediately; long before we consider looking at the Git version or working directory. This way users can still get to the git-gui version number even if Git's version cannot be read. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This reverts commit 871f4c97. Too many users have complained about the credits generator in git-gui, so I'm backing the entire thing out. This revert will finish that series. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Johannes Sixt noticed that git-gui would not let the user commit a merge created by `git merge -s ours` as the ours strategy does not alter the tree (that is HEAD^1^{tree} = HEAD^{tree} after the merge). The same issue arises from amending such a merge commit. We now permit an empty commit (no changed files) if we are doing a merge commit. Core Git does this with its command line based git-commit tool, so it makes sense for the GUI to do the same. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 02 3月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Git 1.5.0 and later no longer output useless messages to standard error when making the initial (or what looks to be) commit of a repository. Since /dev/null does not exist on Windows in the MinGW environment we can't redirect there anyway. Since Git does not output anymore, I'm removing the redirection. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 27 2月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
Mark Levedahl noticed that git-gui will let you create an empty normal (non-merge) commit if the file state in the index is out of whack. The case Mark was looking at was with the new autoCRLF feature in git enabled and is actually somewhat difficult to create. I found a different way to create an empty commit: turn on the Trust File Modifications flag, touch a file, rescan, then move the file into the "Changes To Be Committed" list without looking at the file's diff. This makes git-gui think there are files staged for commit, yet the update-index call did nothing other than refresh the stat information for the affected file. In this case git-gui allowed the user to make a commit that did not actually change anything in the repository. Creating empty commits is usually a pointless operation; rarely does it record useful information. More often than not an empty commit is actually an indication that the user did not properly update their index prior to commit. We should help the user out by detecting this possible mistake and guiding them through it, rather than blindly recording it. After we get the new tree name back from write-tree we compare it to the parent commit's tree; if they are the same string and this is a normal (non-merge, non-amend) commit then something fishy is going on. The user is making an empty commit, but they most likely don't want to do that. We now pop an informational dialog and start a rescan, aborting the commit. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
cehteh on #git noticed that there was no way to perform a reset --hard from within git-gui. When I pointed out this was Merge->Abort Merge cehteh said this is not very understandable, and that most users would never guess to try that option unless they were actually in a merge. So Branch->Reset is now also a way to cause a reset --hard from within the UI. Right now the confirmation dialog is the same as the one used in Merge->Abort Merge. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This code doesn't belong down in the main window UI creation, its really part of the menu system and probably should be located with it. I'm moving it because I could not find the code when I was looking for it earlier today, as it was not where I expected it to be found. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 21 2月, 2007 5 次提交
-
-
由 Shawn O. Pearce 提交于
Attempting to use `git citool` to create an initial commit caused git-gui to crash with a Tcl error as it tried to add the newly born branch to the non-existant branch menu. Moving this code to after the normal commit cleanup logic resolves the issue, as we only have a branch menu if we are not in singlecommit mode. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that the 'browser' subcommand can be used to startup the tree browser, it should be listed as a possible subcommand option in our usage message. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since git-gui does more than create commits, it is unfair to call it "a commit creation tool". Instead lets just call it a graphical user interface. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that git-gui has been released to the public as part of Git 1.5.0 I am starting to see some work from other people beyond myself and Paul. Consequently the copyright for git-gui is not strictly the two of us anymore, and these others deserve to have some credit given to them. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The Firefox browser requires that a URL use / to delimit directories. This is instead of \, as \ gets escaped by the browser into its hex escape code and then relative URLs are incorrectly resolved, Firefox no longer sees the directories for what they are. Since we are handing the browser a true URL, we better use the standard / for directories. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 18 2月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Martin Waitz noticed that git-gui crashed while saving the user's options out if the application was started in blame mode. This was caused by the do_save_config procedure invoking reshow_diff incase the number of context lines was modified by the user. Because we bypassed main window UI setup to enter blame mode we did not set many of the globals which were accessed by reshow_diff, and reading unset variables is an error in Tcl. Aside from moving the globals to be set earlier, I also modified reshow_diff to not invoke clear_diff if there is no path currently in the diff viewer. This way reshow_diff does not crash when in blame mode due to the $ui_diff command not being defined. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 16 2月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Some users may find being able to browse around an arbitrary branch to be handy, so we now expose our graphical browser through `git gui browse <committish>`. Yes, I'm being somewhat lazy and making the user give us the name of the branch to browse. They can always enter HEAD. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 15 2月, 2007 1 次提交
-
-
由 Martin Koegler 提交于
I'm missing the possibility to base a new branch on a tag. The following adds a tag drop down to the new branch dialog. Signed-off-by: NMartin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 14 2月, 2007 5 次提交
-
-
由 Shawn O. Pearce 提交于
Like `git version`, `git gui version` (or `git gui --version`) shows the version of git-gui, in case the user needs to know this, without looking at it in the GUI about dialog. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I started to find it confusing that git-gui would refer to itself as git-citool when it was started through the citool hardlink, or with the citool subcommand. What was especially confusing was the options dialog and the about dialog, as both seemed to imply they were somehow different from the git-gui versions. In actuality there is no difference at all. Now we just call our options menu item 'Options...' (skipping the application name) and our About dialog now always shows git-gui within the short description (above the copyleft notice) and in the version field. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
It was pointed out on the git mailing list by Martin Koegler that we did not show tags as possible things to merge into the current branch. They actually are, and core Git's Grand Unified Merge Driver will accept them just like any other commit. So our merge dialog now requests all refs/heads, refs/remotes and refs/tags named refs and attempts to match them against the commits not in HEAD. One complicating factor here is that we must use the %(*objectname) field when talking about an annotated tag, as they will not appear in the output of rev-list. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This is a very crude (but hopefully effective) check against the `git` executable found in our PATH. Some of the subcommands and options that git-gui requires to be present to operate were created during the 1.5.0 development cycle, so 1.5 is the minimum version of git that we can expect to support. There actually are early releases of 1.5 (e.g. 1.5.0-rc0) that don't have everything we expect (like `blame --incremental`) but these are purely academic at this point. 1.5.0 final was tagged and released just a few hours ago. The release candidates will (hopefully) fade into the dark quickly. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
As we frequently need to execute a Git subcommand and obtain its returned output we are making heavy use of [exec git foo] to run foo. As I'm concerned about possibly needing to carry environment data through a shell on Cygwin for at least some subcommands, I'm migrating all current calls to a new git proc. This actually makes the code look cleaner too, as we aren't saying 'exec git' everywhere. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 13 2月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Now that the decision has been made to treat git-gui as a subproject, rather than merging it directly into git, we should use a different substitution for our version value to avoid any possible confusion. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 12 2月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Now that git 1.5.0 and later contains a version of gitk that uses correct geometry on Windows platforms, even if ~/.gitk exists, we should not delete the user's ~/.gitk to work around the bug. It is downright mean to remove a user's preferences for another app. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 09 2月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-