- 14 2月, 2007 2 次提交
-
-
由 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 7 次提交
-
-
由 Andy Parkins 提交于
Signed-off-by: NAndy Parkins <andyparkins@gmail.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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>
-
由 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: 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 14 次提交
-
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
These are now controlled by the transport and branch options, rather than the multicommit option. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
由 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: NShawn O. Pearce <spearce@spearce.org>
-
- 29 1月, 2007 12 次提交
-
-
由 Shawn O. Pearce 提交于
To help the user visually see which lines are associated with each other in the file we attempt to sign a unique background color to each commit and then render all text associated with that commit using that color. This works out OK for a file which has very few commits in it; but most files don't have that property. What we really need to do is look at what colors are used by our neighboring commits (if known yet) and pick a color which does not conflict with our neighbor. If we have run out of colors then we should force our neighbor to recolor too. Yes, its the graph coloring problem. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Using a panedwindow to display the blame viewer's individual columns just doesn't make sense. Most of the important data fits within the columns we have allocated, and those that don't the leading part fits and that's good enough. There are just too many columns within this viewer to let the user sanely control individual column widths. This change shouldn't really be an issue for most git-gui users as their displays should be large enough to accept this massive dump of data. We now also have a properly working horizontal scrollbar for the current file data area. This makes it easier to get away with a narrow window when screen space is limited, as you can still scroll around within the file content. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I started to get confused about what each column meant in the blame viewer, and I'm the guy who wrote the code! So now git-gui hints to the user about what each column is by drawing headers at the top. Unfortunately this meant I had to use those dreaded frame objects which seem to cause so much pain on Windows. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we annotate a file and show its line data, we're already asking for copy and movement detection (-M -C). This costs extra time, but gives extra data. Since we are asking for the extra data we really should show it to the user. Now the blame UI has two additional columns, one for the original filename (in the case of a move/copy between files) and one for the original line number of the current line of code. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Anytime are about to open a pipe on what may be user data we need to make sure the value is escaped correctly into a Tcl list, so that the executed subprocess will receive the right arguments. For the most part we were already doing this correctly, but a handful of locations did not. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since we run blame incrementally in the background we might as well get as much data as we can from the file. Adding -M and -C definately makes it take longer to compute the revision annotations, but since they are streamed in and updated as they are discovered we'll get recent data almost immediately anyway. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users may need to be able to alter their user.name or user.email configuration settings. If they are mostly a git-gui user they should be able to view/set these important values from within the git-gui environment, rather than needing to edit a raw text file on their local filesystem. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Rather than using HEAD for the current branch, use the actual name of the current branch in the browser. This way the user knows what a browser is browsing if they open up different browsers while on different branches. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Real icons which seem to indicate going up to the parent (an up arrow) and a subdirectory (an open folder). Files are now drawn with the file_mod icon, like a modified file is. This just looks better as it is more consistent with the rest of our UI. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This rather huge change provides a browser for the current branch. The browser simply shows the contents of tree HEAD, and lets the user drill down through the tree. The icons used really stink, as I just copied in icon which we already had. I really need to replace the file_dir and file_uplevel icons with something more useful. If the user double clicks on a file within the browser we open it in a blame viewer. This makes use of the new incremental blame feature that Linus just added yesterday to core Git. Fortunately the feature will be in 1.5.0 final so we can rely on having it available here. Since the blame engine is incremental the user will get blame data for groups which can be determined early. Git will slowly fill in the remaining lines as it goes. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Running on Cygwin is different than if we were running through MinGW. In the Cygwin case we have cygpath available to us, we need to perform UNIX<->Windows path translation sometimes, and we need to perform odd things like spawning our own login shells to perform network operations. But in the MinGW case these don't occur. Git knows native Windows file paths, and login shells may not even exist. Now git-gui will avoid running cygpath unless it knows its on Cygwin. It also uses a different shortcut type when Cygwin is not present, and it avoids invoking /bin/sh to execute hooks if Cygwin is not present. This latter part probably needs more testing in the MinGW case. This change also improves how we start gitk. If the user is on any type of Windows system its known that gitk won't start right if ~/.gitk exists. So we delete it before starting if we are running on any type of Windows operating system. We always use the same wish executable which launched git-gui to start gitk; this way on Windows we don't have to jump back to /bin/sh just to go into the first wish found in the user's PATH. This should help on MinGW when we probably don't want to spawn a shell just to start gitk. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users may want to be able to read Git documentation, even if they are not command line users. There are many important concepts and terms covered within the standard Git documentation which would be useful to even non command line using people. We now try to offer an 'Online Documentation' menu option within the Help menu. First we try to guess to see what browser the user has setup. We default to instaweb.browser, if set, as this is probably accurate for the user's configuration. If not then we try to guess based on the operating system and the available browsers for each. We prefer documentation which is installed parallel to Git's own executables, e.g. `git --exec-path`/../Documentation/index.html, as that is how I typically install the HTML docs. If those are not found then we open the documentation published on kernel.org. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 27 1月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
OK, its official, I'm not reading documentation as well as I should be. Core Git's merge.summary configuration option is used to control the generation of the text appearing within the merge commit itself. It is not (and never has been) used to default the --no-summary command line option, which disables the diffstat at the end of the merge. I completely blame Git for naming two unrelated options almost the exact same thing. But its my own fault for allowing git-gui to confuse the two. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 26 1月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
Changed our private merge summary config option to be the same as the merge.summary option supported by core Git. This means setting the "Show Merge Summary" flag in git-gui will have the same effect on the command line. In the same vein I've also added merge.verbosity to the gui options, allowing the user to adjust the verbosity level of the recursive merge strategy. I happen to like level 1 and suggest that other users use that, but level 2 is the core Git default right now so we'll use the same default in git-gui. Unfortunately it appears as though core Git has broken support for the merge.summary option, even though its still in the documentation For the time being we should pass along --no-summary to git-merge if merge.summary is false. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Anytime we use a listbox to show branch names its possible for the listbox to exceed 10 entries (actually its probably very common). So we should always offer a scrollbar for the Y axis on these listboxes. I just forgot to add it when I defined them. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user is in the middle of a commit they have files which are modified. These may conflict with any merge that they may want to perform, which would cause problems if the user wants to abort a bad merge as we wouldn't have a checkpoint to roll back onto. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-