summaryrefslogtreecommitdiff
path: root/lib/index.tcl
AgeCommit message (Collapse)AuthorFilesLines
2008-02-03git-gui: (i18n) Fix a bunch of still untranslated strings.Libravatar Christian Stimming1-1/+1
Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-01-16git-gui: Fix broken revert confirmation.Libravatar Christian Stimming1-1/+3
I broke this extremely cool feature in 1ac17950, but it is rather easy to fix this. Sorry for that. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-23Merge branch 'maint'Libravatar Shawn O. Pearce1-12/+53
* maint: git-gui: Make sure we get errors from git-update-index Conflicts: lib/index.tcl
2007-10-23git-gui: Make sure we get errors from git-update-indexLibravatar Shawn O. Pearce1-9/+52
I'm seeing a lot of silent failures from git-update-index on Windows and this is leaving the index.lock file intact, which means users are later unable to perform additional operations. When the index is locked behind our back and we are unable to use it we may need to allow the user to delete the index lock and try again. However our UI state is probably not currect as we have assumed that some changes were applied but none of them actually did. A rescan is the easiest (in code anyway) solution to correct our UI to show what the index really has (or doesn't have). Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-10git-gui: Use progress meter in the status bar during index updatesLibravatar Shawn O. Pearce1-42/+12
If we are updating the index to stage or unstage changes or reverting files in the working directory we can use the progress handling parts of our status bar to perform this display work, reducing the amount of code duplication we have in the index handling module. Unfortunately the status bar is still a strict approximation as it is unable to know when git-update-index has processed the data we fed to it. The progress bar is actually a progress of the pipe buffer filling up in the OS, not of the actual work done. Still, it tells the user we are working and that has some value. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-13git-gui: add some strings to translationLibravatar Michele Ballabio1-2/+2
Most of these changes were suggested by Shawn Pearce in an answer to Johannes Schindelin. Some strings for the blame module were added too. [sp: Minor edits in blame module formatting] Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-13Merge branch 'maint'Libravatar Shawn O. Pearce1-1/+1
* maint: git-gui: Paper bag fix "Commit->Revert" format arguments git-gui: Provide 'uninstall' Makefile target to undo an installation git-gui: Font chooser to handle a large number of font families
2007-09-13git-gui: Paper bag fix "Commit->Revert" format argumentsLibravatar Shawn O. Pearce1-1/+1
The recent bug fix to correctly handle filenames with %s (or any other valid Tcl format specifier) missed a \ on this line and caused the remaining format arguments to not be supplied when we updated the status bar. This caused a Tcl error anytime the user was trying to perform a file revert. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-09Merge branch 'maint'Libravatar Shawn O. Pearce1-6/+12
* maint: git-gui: Avoid use of libdir in Makefile git-gui: Disable Tk send in all git-gui sessions git-gui: lib/index.tcl: handle files with % in the filename properly
2007-09-08git-gui: lib/index.tcl: handle files with % in the filename properlyLibravatar Gerrit Pape1-6/+12
Steps to reproduce the bug: $ mkdir repo && cd repo && git init Initialized empty Git repository in .git/ $ touch 'foo%3Fsuite' $ git-gui Then click on the 'foo%3Fsuite' icon to include it in a changeset, a popup comes with: 'Error: bad field specifier "F"' Vincent Danjean noticed the problem and also suggested the fix, reported through http://bugs.debian.org/441167 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-02Mark strings for translation.Libravatar Christian Stimming1-7/+16
The procedure [mc ...] will translate the strings through msgcat. Strings must be enclosed in quotes, not in braces, because otherwise xgettext cannot extract them properly, although on the Tcl side both delimiters would work fine. [jes: I merged the later patches to that end.] Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2007-07-29git-gui: Unify wording to say "to stage" instead of "to add"Libravatar Christian Stimming1-1/+1
Also, the warning message when clicking "Reset" is adapted to the wording "Reset" rather than a confusion "Cancel commit?". Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-07-09git-gui: Always use absolute path to all git executablesLibravatar Shawn O. Pearce1-9/+9
Rather than making the C library search for git every time we want to execute it we now search for the main git wrapper at startup, do symlink resolution, and then always use the absolute path that we found to execute the binary later on. This should save us some cycles, especially on stat challenged systems like Cygwin/Win32. While I was working on this change I also converted all of our existing pipes ([open "| git ..."]) to use two new pipe wrapper functions. These functions take additional options like --nice and --stderr which instructs Tcl to take special action, like running the underlying git program through `nice` (if available) or redirect stderr to stdout for capture in Tcl. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-07-08git-gui: Refactor our ui_status_value update techniqueLibravatar Shawn O. Pearce1-15/+15
I'm really starting to dislike global variables. The ui_status_value global varible is just one of those that seems to appear in a lot of code and in many cases we didn't even declare it "global" within the proc that updates it so we haven't always been getting all of the updates we expected to see. This change introduces two new global procs: ui_status $msg; # Sets the status bar to show $msg. ui_ready; # Changes the status bar to show "Ready." The second (special) form is used because we often update the area with this message once we are done processing a block of work and want the user to know we have completed it. I'm not fixing the cases that appear in lib/branch.tcl right now as I'm actually in the middle of a huge refactoring of that code to support making a detached HEAD checkout. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-07git-gui: Refactor into multiple files to save my sanityLibravatar Shawn O. Pearce1-0/+409
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: Shawn O. Pearce <spearce@spearce.org>