kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Shawn O. Pearce	c74b6c66f0	git-gui: Convert browser, console to "class" format Now that we have a slightly easier method of working with per-widget data we should make use of that technique in our browser and console meta-widgets, as both have a decent amount of information that they store on a per-widget basis and our current approach of handling it is difficult to follow. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	cc1f83fbdf	git-gui: Allow shift-{k,j} to select a range of branches to merge I found it useful to be able to use j/k (vi-like keys) to move up and down the list of branches to merge and shift-j/k to do the selection, much as shift-up/down (arrow keys) would alter the selection. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	ebcaadabcb	git-gui: Use vi-like keys in merge dialog Since we support vi-like keys for scrolling in other UI contexts we can easily do so here too. Tk's handy little `event generate' makes this a lot easier than I thought it would be. We may want to go back and fix some of the other vi-like bindings to redirect to the arrow and pageup/pagedown keys, rather than running the view changes directly. I've bound 'v' to visualize, as this is a somewhat common thing to want to do in the merge dialog. Control (or Command) Return is also bound to start the merge, much as it is bound in the main window to activate the commit. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	1fc4ba86f8	git-gui: Include commit id/subject in merge choices When merging branches using our local merge feature it can be handy to know the first few digits of the commit the ref points at as well as the short description of the branch name. Unfortunately I'm unable to use three listboxes in a row, as Tcl freaks out and refuses to let me have a selection in more than one of them at any given point in time. So instead we use a fixed width font in the existing listbox and organize the data into three columns. Not nearly as nice looking, but users can continue to use the listbox's features. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	349f92e3a2	git-gui: Show all possible branches for merge Johannes Sixt pointed out that git-gui was randomly selecting which branch (or tag!) it will show in the merge dialog when more than one ref points at the same commit. This can be a problem for the user if they want to merge a branch, but the ref that git-gui selected to display was actually a tag that points at the commit at the tip of that branch. Since the user is looking for the branch, and not the tag, its confusing to not find it, and worse, merging the tag causes git-merge to generate a different message than if the branch was selected. While I am in here and am messing around I have changed the for-each-ref usage to take advantage of its --tcl formatting, and to fetch the subject line of the commit (or tag) we are looking at. This way we could present the subject line in the UI to the user, given them an even better chance to select the correct branch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	a6c9b081b6	git-gui: Move merge support into a namespace 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: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	a35d65d9c8	git-gui: Move console procs into their own namespace To help modularize git-gui better I'm isolating the code and variables required to handle our little console windows into their own namespace. This way we can say console::new rather than new_console, and the hidden internal procs to create the window and read data from our filehandle are off in their own private little land, where most users don't see them. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	f522c9b5ed	git-gui: Refactor into multiple files to save my sanity 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>	18 years ago