summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2007-04-04git-gui: Brown paper bag fix division by 0 in blameShawn 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: Shawn O. Pearce <spearce@spearce.org>
2007-03-12Merge branch 'maint'gitgui-0.6.5Shawn O. Pearce
* maint: git-gui: Allow 'git gui version' outside of a repository git-gui: Revert "git-gui: Display all authors of git-gui." git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed." git-gui: Allow committing empty merges
2007-03-12git-gui: Allow 'git gui version' outside of a repositorygitgui-0.6.4Shawn 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: Shawn O. Pearce <spearce@spearce.org>
2007-03-12git-gui: Revert "git-gui: Display all authors of git-gui."Shawn O. Pearce
This reverts commit 871f4c97ad7e021d1a0a98c80c5da77fcf70e4af. 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: Shawn O. Pearce <spearce@spearce.org>
2007-03-12git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed."Shawn O. Pearce
This reverts commit 92446aba47b0e0db28f7b858ea387efcca30ab44. Too many users have complained about the credits generator in git-gui, so I'm backing the entire thing out. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-03-12git-gui: Allow committing empty mergesShawn 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: Shawn O. Pearce <spearce@spearce.org>
2007-03-07git-gui: Support of "make -s" in: do not output anything of the build itselfAlex Riesen
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-03-06git-gui: Make 'make' quieter by defaultgitgui-0.6.3Shawn O. Pearce
To fit nicely into the output of the git.git project's own quieter Makefile, we want to make the git-gui Makefile nice and quiet too. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-03-01git-gui: Remove unnecessary /dev/null redirection.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-26git-gui: Don't create empty (same tree as parent) commits.gitgui-0.6.2Shawn 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: Shawn O. Pearce <spearce@spearce.org>
2007-02-26git-gui: Add Reset to the Branch menu.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-26git-gui: Relocate the menu/transport menu code.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-25Don't modify CREDITS-FILE if it hasn't changed.Junio C Hamano
We should always avoid rewriting a built file during `make install` if nothing has changed since `make all`. This is to help support the typical installation process of compiling a package as yourself, then installing it as root. Forcing CREDITS-FILE to be always be rebuilt in the Makefile means that CREDITS-GEN needs to check for a change and only update CREDITS-FILE if the file content actually differs. After all, content is king in Git. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-21git-gui: Don't crash in citool mode on initial commit.gitgui-0.6.1Shawn 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: Shawn O. Pearce <spearce@spearce.org>
2007-02-21git-gui: Remove TODO list.Shawn O. Pearce
I'm apparently not very good at keeping my own TODO file current. I its also somewhat strange to keep the TODO list as part of the software branch, as its meta-information that is not directly related to the code. I'm pulling the TODO list from git-gui and moving it into a seperate branch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-21git-gui: Include browser in our usage message.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-21git-gui: Change summary of git-gui.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-21git-gui: Display all authors of git-gui.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-21git-gui: Use mixed path for docs on Cygwin.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-18git-gui: Correct crash when saving options in blame mode.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-16git-gui: Expose the browser as a subcommand.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-15git-gui: Create new branches from a tag.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: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-14git-gui: Prefer version file over git-describe.Shawn O. Pearce
Some distributions are using Git for part of their package management system, but unpack Git's own source code for delivery from the .tar.gz. This means that when we walk up the directory tree with git-describe to locate a Git repository, the repository we find is for the distribution and *not* for git-gui. Consequently any tag we might find there is bogus and does not apply to us. In this case the version file should always exist and be readable, as the packager is working from the released .tar.gz sources. So we should always favor the version file over anything git-describe guess for us. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-14git-gui: Print version on the console.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-14git-gui: More consistently display the application name.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-14git-gui: Permit merging tags into the current branch.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-14git-gui: Basic version check to ensure git 1.5.0 or later is used.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-14git-gui: Refactor 'exec git subcmd' idiom.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-13git-gui: fix typo in GIT-VERSION-GEN, "/dev/null" not "/devnull"Andy Parkins
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-12git-gui: Change base version to 0.6.gitgui-0.6.0Shawn O. Pearce
This is the start of the 0.6 series of git-gui. I'm calling it 0.6 (rather than any other value) as I already had a private tag on one system based on 0.5, and that tag is quite a bit behind this version. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-12git-gui: Guess our version accurately as a subproject.Shawn O. Pearce
When we are included as a subproject, such as how git.git carries us, we want to retain our own version number and not the version number assigned by git.git's own tags. Consequently we need to locate the correct tag which applies to our tree content and its commit lineage. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-12git-gui: Handle gitgui tags in version gen.Shawn O. Pearce
I've decided to use gitgui-0.5 as the format for tags in the git-gui repository. The prefix of gitgui was chosen here to make its namespace different from the namespace used by git itself, allowing developers to pull both tag namespaces into the same repository. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-12git-gui: Generate a version file on demand.Shawn O. Pearce
Because git-gui is being shipped as a subproject of the main Git project and will often have a different lifecycle than the main Git project, we should ship our own version number in the release tarball rather than relying on the main Git version file. Git's master Makefile will invoke our own with the target dist-version, asking us to save off our GITGUI_VERSION value into our own version file, so that our GIT-VERSION-GEN script can recover it at build time. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-12git-gui: Rename GIT_VERSION to GITGUI_VERSION.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-12git-gui: Allow gitexecdir, INSTALL to be set by the caller.Shawn O. Pearce
When used as a subproject within git.git our Makefile must honor the gitexecdir which git.git's Makefile is passing down to us, ensuring that we install our executables into the libexec chosen by the end-user or packager. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-11git-gui: Stop deleting gitk preferences.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-09git-gui: Focus into blame panels on Mac OS.Shawn O. Pearce
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-09git-gui: Improve annotated file display.Shawn O. Pearce
Rather than trying to mark the background color of the line numbers to show which lines have annotated data loaded, we now show a ruler between the line numbers and the file data. This ruler is just 1 character wide and its background color is set to grey to denote which lines have annotation ready. I had to make this change as I kept loosing the annotation marker when a line was no longer colored as part of the current selection. We now color the lines blamed on the current commit in yellow, the lines in the commit which came after (descendant) in red (hotter, less tested) and the lines in the commit before (ancestor) in blue (cooler, better tested). Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-09git-gui: Jump to the first annotation block as soon as its available.Shawn O. Pearce
To help clue users into the fact that annotation data arrives incrementally, and that they should try to locate the region they want while the tool is running, we jump to the first line of the first annotation if the user has not already clicked on a line they are interested in and if the window is still looking at the very top of the file. Since it takes a second (at least on my PowerBook) to even generate the first annotation for git-gui.sh, the user should have plenty of time to adjust the scrollbar or click on a line even before we get that first annotation record in, which allows the user to bypass our automatic jumping. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-09git-gui: Redesign the display of annotated files.Shawn O. Pearce
Using 180 columns worth of screen space to display just 20 columns of file data and 160 columns worth of annotation information is not practically useful. Users need/want to see the file data, and have the anotation associated with it displayed in a detail pane only when they have focused on a particular region of the file. Now our file viewer has a small 10-line high pane below the file which shows the commit message for the commit this line was blamed on. The columns have all been removed, except the current line number column as that has some real value when trying to locate an interesting block. To keep the user entertained we have a progress meter in the status bar of the viewer which lets them know how many lines have been annotated, and how much has been completed. We use a grey background on the line numbers for lines which we have obtained annotation from, and we color all lines in the current commit with a yellow background, so they stand out when scanning through the file. All other lines are kept with a white background, making the yellow really pop. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-09git-gui: Use git-config now over git-repo-config.Shawn O. Pearce
Now that core Git has "renamed" git-repo-config to git-config, we should do the same. I don't know how long core Git will keep the repo-config command, and since git-gui's userbase is so small and almost entirely on some flavor of 1.5.0-rc2 or later, where the rename has already taken place, it should be OK to rename now. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-09git-gui: Relabel the Add All action.Shawn O. Pearce
One user that I spoke with recently was confused why the 'Add All' button did not add all of his 'Changed But Not Updated' files. The particular files in question were new, and thus not known to Git. Since the 'Add All' routine only updates files which are already tracked, they were not added automatically. I suspect that calling this action 'Add Existing' would be less confusing, so I'm renaming it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-09git-gui: Select subcommands like git does.Shawn O. Pearce
If we are invoked as `git-foo`, then we should run the `foo` subcommand, as the user has made some sort of link from `git-foo` to our actual program code. So we should honor their request. If we are invoked as `git-gui foo`, the user has not made a link (or did, but is not using it right now) so we should execute the `foo` subcommand. We now can start the single commit UI mode via `git-citool` and also through `git gui citool`. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-09git-gui: View blame from the command line.Shawn O. Pearce
Viewing annotated files is one of those tasks that is relatively difficult to do in a simple vt100 terminal emulator. The user really wants to be able to browse through a lot of information, and to interact with it by navigating through revisions. Now users can start our file viewer with annotations by running 'git gui blame commit path', thereby seeing the contents of the given file at the given commit. Right now I am being lazy by not allowing the user to omit the commit name (and have us thus assume HEAD). Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-08git-gui: Optionally save commit buffer on exit.Shawn O. Pearce
If the commit area does not exist, don't save the commit message to a file, or the window geometry. The reason I'm doing this is I want to make the main window entirely optional, such as if the user has asked us to show a blame from the command line. In such cases the commit area won't exist and trying to get its text would cause an error. If we are running without the commit message area, we cannot save our window geometry either, as the root window '.' won't be a normal commit window. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-08git-gui: Separate transport/branch menus from multicommit.Shawn O. Pearce
These are now controlled by the transport and branch options, rather than the multicommit option. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-08git-gui: Refactor single_commit to a proc.Shawn O. Pearce
This is a minor code cleanup to make working with what used to be the $single_commit flag easier. Its also to better handle various UI configurations, depending on command line parameters given by the user, or perhaps user preferences. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-08git-gui: Replace \ with \\ when showing paths.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-08git-gui: Support keyboard traversal in browser.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: Shawn O. Pearce <spearce@spearce.org>
2007-02-08git-gui: Update known branches during rescan.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: Shawn O. Pearce <spearce@spearce.org>