kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Johannes Schindelin	f049e0944d	git-gui: MERGE_RR lives in .git/ directly with newer Git versions Now that MERGE_RR was moved out of .git/rr-cache/, we have to delete it somewhere else. Just in case somebody wants to use a newer git-gui with an older Git, the file .git/rr-cache/MERGE_RR is removed, too (if it exists). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Christian Stimming	5e6d7768e1	git-gui: (i18n) Fix a bunch of still untranslated strings. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Christian Stimming	1ac17950e9	Mark strings for translation. 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>	17 years ago
Shawn O. Pearce	18a01a0da4	git-gui: Allow git-merge to use branch names in conflict markers Earlier when I rewrote the merge implementation for git-gui I broke it such that the conflict markers for the "theirs" side of the hunk was using a full SHA-1 ID in hex, rather than the name of the branch the user had merged. This was because I got paranoid and passed off the full SHA-1 to git-merge, instead of giving it the reference name the user saw in the merge dialog. I'd still like to resolve the SHA-1 upfront in git-gui and always use that value throughout the merge, but I can't do that until we have a full implementation of git-merge written in Tcl. Until then its more important that the conflict markers be useful to the end-user, so we need to pass off the ref name and not the SHA-1 ID. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Shawn O. Pearce	84f67537b1	git-gui: Minor refactoring of merge command line in merge support This is just a small code movement to cleanup how we generate the command line for a merge. I'm only doing it to make the next series of changes slightly more readable. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	0fe055cd24	git-gui: Use progress bar while resetting/aborting files Resetting a large number of files on a slow filesystem can take considerable time, just as switching branches in such a case can take more than two seconds. We now take advantage of the progress meter output by read-tree and show it in the main window status bar, just like we do during checkout (branch switch). Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Christian Stimming	360cc106e7	git-gui: Unify wording to say "to stage" instead of "to add" 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>	18 years ago
Shawn O. Pearce	bc318ea86d	git-gui: Remove usernames from absolute SSH urls during merging If we are being asked to merge a tracking branch that comes from a remote repository accessed by the very common SSH URL format of "user@host:/path/to/repo" then we really don't need the username as part of the merge message, it only clutters up the history and makes things more confusing. So we instead clip the username part off if the local filesystem path is absolute, as its probably not going to be an ambiguous URL even when it is missing the username. On the other hand we cannot clip the username off if the URL is not absolute, because in such cases (e.g. "user@host:myrepo") the directory that the repository path is resolved in is relative to the user's home directory, and the username becomes important. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	ead49f5a4f	git-gui: Format tracking branch merges as though they were pulls If we are merging a tracking branch we know exactly what remote URL that branch is fetched from, and what its name is on that remote repository. In this case we can setup a merge message that looks just like a standard `git-pull $remote $branch` operation by filling out FETCH_HEAD before we start git-merge, and then run git-merge just like git-pull does. I think the result of this behavior is that merges look a lot nicer when the came off of local tracking branches, because they no longer say "commit 'origin/...'" to describe the commit being merged but instead now mention the specific repository we fetched those commits from. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	9feefbd2d2	git-gui: Cleanup bindings within merge dialog Misc. code cleanups in the merge dialog's binding setup and action button creation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	350a35f0a1	git-gui: Replace merge dialog with our revision picker widget Now that we only support merging one branch we can offer the user a better user interface experience by allowing them to select the revision they want to merge through our revision picking widget. This change neatly solves the problem of locating a branch out of a sea of 200 tracking branches, and of dealing with very long branch names that all have a common prefix. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	5dc2cae6f4	git-gui: Completely remove support for creating octopus merges I'm working on refactoring the UI of the merge dialog, because as it currently stands the dialog is absolutely horrible, especially when you have 200+ branches available from a single remote system. In that refactoring I plan on using the choose_rev widget to allow the user to select exactly which branch/commit they want to merge. However since that only selects a single commit I'm first removing the code that supports octopus merges. A brief consultation on #git tonight seemed to indicate that the octopus merge strategy is not as useful as originally thought when it was invented, and that most people don't commonly use them. So making users fall back to the command line to create an octopus is actually maybe a good idea here, as they might think twice before they use it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	ff749c114a	git-gui: Convert merge dialog to use class system I've found that the class code makes it a whole lot easier to create more complex GUI code, especially the dialogs. So before I make any major improvements to the merge dialog's interface I'm going to first switch it to use the class system, so the code is slightly cleaner. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	0b81261622	git-gui: Always use absolute path to all git executables 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>	18 years ago
Shawn O. Pearce	699d5601f5	git-gui: Refactor our ui_status_value update technique 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>	18 years ago
Shawn O. Pearce	c8e23aaf18	git-gui: Unlock the index when cancelling merge dialog Pressing the escape key while in the merge dialog cancels the merge and correctly unlocks the index. Unfortunately this is not true of the Cancel button, using it closes the dialog but does not release the index lock, rendering git-gui frozen until you restart it. We now properly release the index lock when the Cancel button is used. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	39fa2a983d	git-gui: Save geometry before the window layout is damaged Because Tk does not assure us the order that it will process children in before it destroys the main toplevel we cannot safely save our geometry data during a "bind . <Destroy>" event binding. The geometry may have already changed as a result of a one or more children being removed from the layout. This was pointed out in gitk by Mark Levedahl, and patched over there by commit `b6047c5a81`. So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when the window is closed by the user, and forward that close event to our main do_quit routine. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
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

25 Commits (57cae87b77c93e8bdfd11293f11f140ff827269a)