- 18 11月, 2006 15 次提交
-
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because we immediately start a rescan operation, but do so slightly delayed (by 1 ms, to let the UI show before we start forking off git processes), we can't let the user try to activate any of the restricted GUI commands before the 1 ms timer expires and we kick off the rescan. So now we lock the index before we enter the Tk event loop, ensuring that it is impossible for the user to inject a conflicting UI event before our rescan can begin. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When the user selects a number of files they would typically expect to be able to act on that selection, such as by including those files into the next commit. So we now have a menu option under the Commit menu that lets the user include only the selection, rather than everything. If there is no selection but there is a file in the diff viewer than we consider that to be the selection (a selection of 1). Unfortunately we don't disable this option yet when there's nothing selected to include, but this is probably not a big deal as there are very few situations where there are no selected files. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
It just felt wrong to me that I was using _ as part of the mode argument to display_file to mean "don't care/use existing" and * as part of the mode argument to mean "force to _". So instead use ? to mean "don't care/use existing" and _ to mean "force to _". The code is a lot clearer this way and hopefully it won't drive another developer insane, as it did me. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I noticed that we were reshowing the current diff during a commit; this occurs because we feed every added and modified file through update-index just before commit. During the update-index process we reshow the current diff if the current file in the diff pane was one of those added or modified files we reprocessed. This just slows down the UI more than is necessary. So refactoring update_index so that we don't call reshow_diff from within that code; instead we do it at a higher level. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Apparently I never really tested the logic for making or amending an initial commit, so although most of the code was here in git-gui it didn't quite work as it was intended to. So this is all just bug fixes to make initial commits correctly generate the list of files going into the initial commit, or to show a newly added file's diff, and to amend an initial commit. Because we really want to diff the index against a tree-ish and there is no such tree-ish on an initial commit we create an empty tree through git-mktree and diff against that. This unfortunately creates a dangling tree, which may confuse a new user who uses git-gui to make a new commit and then immediately afterwards runs git fsck-objects to see if their object database is corrupt or not. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we can't locate a .git directory for the given directory we need to show a message to the user to let them know the directory wasn't found. But since this is before we have shown our main application window we cannot use that as the parent for the error popup; on Mac OS X this causes an error and prevents the dialog from showing. Instead only add -parent . to the popup call if we have mapped (shown) the main window. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If a user works with a repository frequently they may want to just create an icon they can use to launch git-gui against that repository. Since we already support this concept on Windows we can do the same on Mac OS X by creating a .app file with a tiny shell script in it that sets up the necessary environment then invokes our script. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Don't offer to fetch from a remote unless we have at least one Pull: line in its .git/remotes/<name> file or at least one configuration value for remote.<name>.fetch. Ditto for push. Users shouldn't be fetching or pushing branch groups unless they have them configured; anything else is just crazy. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since we have some serious problems with the GIT_DIR environment variable on Windows we cannot let the user use a non-standard GIT_DIR with their working directory. So require that the GIT_DIR name is actually ".git", that it exists, and that its parent directory is our working directory. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we are running on Windows we now offer a 'Create Desktop Icon' menu item under the Project menu. This pops up a save dialog box letting the user create a .bat file on their desktop (or somewhere else). The .bat script will startup Cygwin with a login shell then launch git-gui in the current working directory. This is very useful for Windows users who have little to no desire to start a command window just to run a git-gui session. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Some users may want to start us by running "git --git-dir=... gui" rather than trying to cd into the directory first. This is especially true if they want to just make a shortcut to our executable on Windows and always have that associated with a certain repository. Since Tcl on Windows throws away our environment and doesn't pass it down to the child process correctly we cannot call git-rev-parse to get the GIT_DIR environment variable. So instead we ask for it specifically ourselves; if its not defined then we ask rev-parse. This should actually reduce startup by 1 fork/exec if we were started as "git gui" as GIT_DIR will be set for us. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since we want to be installed in gitexecdir so that "git gui" works we can guess where that directory is by asking the git wrapper executable and locating ourselves at the same location using the same install rules as core git. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 16 11月, 2006 2 次提交
-
-
由 Shawn O. Pearce 提交于
There is no reason why the user should be able to operate on the diff buffer if there is no currently selected diff; likewise the "File:" label text appears rather silly looking all by itself when no diff is being shown in the diff buffer. So now we only enable widgets (like menu items) if there is a diff currently showing, and we disable them when a diff isn't showing. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user has "Allow Partially Included Files" disabled (and most probably will as its the default setting) we should run update-index on every included file before commit to make sure that any changes made by the user since the last rescan will still be part of this commit. If we don't update-index every modified file the user will likely become confused when part of their changes were committed and other parts weren't; and those other parts won't show up until a later rescan occurs. Since we don't rescan immediately after a commit this may be a while. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 14 11月, 2006 6 次提交
-
-
由 Shawn O. Pearce 提交于
Like rescan we also have cases where we need to perform a script after we have finished updating a number of files in the index. By changing the parameter structure of update_index we can easily pass through any script we need to run afterwards, such as picking up in the middle of a commit, or finishing what is left of a rescan. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
There are some situations where we need to run rescan and have it do more than just updating the status in the UI when its complete. To help with that this changes the rescan procedure to take a script which it will run at the global level as soon as the rescan is done and the UI has finished updating with the results. This is useful for example if we performed a rescan as part of a commit operation; we can go back to the commit where we left off when the rescan got initiated. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since we refer to the act of updating our memory structures with index and working directory differences as a rescan in the UI its probably a good idea to make the related procedures have the same name. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because I want to let users apply actions to more than one file at a time we really needed a concept of "the current selection" from the two file lists. Since I'm abusing a Tk text widget for the file displays I can't really use the Tk selection to track which files are picked and which aren't. So instead we keep this in an array to tell us which paths are currently selected and we use an inverse fg/bg for the selected file display. This is common most operating systems as a selection indicator. The selection works like most users would expect; single click will clear the selection and pick only that file, M1-click (aka Ctrl-click or Cmd-click) will toggle the one file in/out of the selection, and Shift-click will select the range between the last clicked file and the currently clicked file. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
On Mac OS X the no differences informational message was linewrapped at the wrong points due to the limited width of the system dialog, yet the LFs embedded in the message (where I linewrapped it manually) were also being honored. This resulted in a very difficult to read paragraph of text. So this narrows the text down by another 10 columns or so, making it more readable. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'm not a huge fan of putting the left and right mouse actions into the same procedure. Originally this is how Paul had implemented the logic in gitool and I had carried some of that over into git-gui, but now that I'm getting ready to implement right mouse click features to act on files I really should split this apart. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 13 11月, 2006 17 次提交
-
-
由 Shawn O. Pearce 提交于
The concept of the Git index is confusing for many users, especially those who are newer to Git. Since git-gui is (at least partially) intended to be used by newer users who don't need the complexity of the index to be put in front of them early on, we should hide it by making any partially included file fully included as soon as we identify it. To do this we just run a quick update_index pass on any file which differs both in the index and the working directory, as these files have already been at least partially included by the user. A new option has been added in the options dialog (gui.partialinclude) which lets the user enable accessing the index from git-gui. This just disables the automatic update_index pass on partially included files. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
So although a text field with a flat relief looks like a label on Windows it doesn't on Mac OS X. The Aqua version of Tk is still drawing a border around the text field and that makes the diff pane header look pretty ugly. Earlier I had made the file name area into a text widget so the user could highlight parts of it and copy them onto the clipboard; but with the context menu being present this isn't quite as necessary as the user can copy the file name to the clipboard using that instead. So although this is a small loss in functionality for non-Mac OS X systems I think it is still reasonable. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Moved the Close button over to the lower right corner where our Cancel/Save buttons are in the options dialog. This should fit better with our own look and feel as well as that of most apps on Mac OS X and Windows. Also set the lower status bar in a console window to indicate the process is working and that the user should wait for it to finish. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because the Tk pack layout manager gives all space to the right/bottom most widget during expand/contract of the frame we were adding and removing all space from the status area of the bar and not from the file name, which is what we actually wanted. A simple enough fix is to just put the status of the given file on the left side of the diff viewer header rather than on the right. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When I changed from 'check in' to 'include' I missed the human friendly status displayed in the right side of the diff viewer heading. It was still reporting 'Checked in' for a fully included file, which is not what we wanted it to say. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
There's a lot of reasons why the user might need to obtain the complete (or just part of) path of a file which they are currently viewing in the diff viewer pane. So now we allow selection on this widget by using a text widget instead of a label. We also offer a context menu which has actions for copying the selection or the entire value onto the clipboard. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When we shove a large number of files at update-index and they have very short path names we are likely going to fit a large number of them into the pipe buffer very early; thereby seeing a huge progress update followed by lots of waiting between progress updates due to the latency of update-index. Using a smaller buffer should help smooth out the progress updates as we are better able to keep tabs on the update-index process' progress through our list of paths. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Its a little surprising to see the UI update the icons for files in random order, due to the fact that the files are updating in the order they appear within the array (which is based on a hash function and not order). So sort the list of files before we send any to update-index so the order of operation is means something to the user. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When displaying a diff the Git default of 3 line of context may not be enough for a user to see what has actually changed. Consequently we set our own program default to 5 lines of context and then allow the user to adjust this on a per-repository and global level through our options dialog. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'd like to allow the user to have more control over how we format the diff in the diff viewer; to that end we need to add additional options to the diff-index command line as we construct the command for execution. So cleanup the command handling code now to use lappend so we can come back and add in our additional options. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
We can't ask the diff viewer to recompute the diff until after our update-index child process terminates, as the diff programs need to be able to read the updated index in order to generate the correct diff. This is actually why we prevent diffs from being generated while there is an update lock on the index, which is why we ignored our own show_diff invocation in the middle of the write_update_index event handler. So now we mark a flag if we identify that the file currently in the diff viewer was also sent to update-index; then later when the update-index process has terminated we update the diff viewer if the flag is true. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This is one of those stupid Tcl mistakes that an experienced Tcl programmer just wouldn't make. We should always use eq and ne to compare string values (and never == or !=) as when we use ==/!= Tcl will attempt to convert either side to numeric if one of the two sides looks like a numeric. This could cause some trouble if a file named "1" exists and a different file named "1.0" also exists; their paths are equal according to == but not according to eq. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since git-commit.sh invokes hooks/post-commit after running git rerere we should do the same if its available and executable. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
We were originally trying to use $commit_active to tell us if there was a commit currently in progress, just so we didn't attempt to start a second (parallel) one by mistake. But really the index lock handles this for us as it won't let us lock the index if it is already locked for update. So this can't happen. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I started to notice on Windows that commits took a lot longer to get going than on my Mac OS X system. The real reason is the repositories that I'm testing with on Windows all enabled the standard pre-commit hook while my test repository on Mac OS X doesn't have it executable (so its not running). So the Windows repositories are spending this lag time running that hook. Now we run the pre-commit hook in the background, allowing the UI to update and tell the user we are busy doing things. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because the pull diffstat summary can take as long as the pull itself some users may just choose to disable the summary and save themselves an extra few seconds during each pull. This is especially true if the user really doesn't care about the other files being modified, as due to their project organizational structure they aren't really responsible for their content. This adds an option to the options panel which lets the user disable the diffstat summary (and thus we pass --no-summary to git-pull) but there does appear to be a bug in the config saving code where we did not set the local repo config differently from the global config. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since git-repo-config will supply us a union of both the global and the local repository configuration data when we invoke it during startup there is no reason to go get the global configuration with an extra call to repo-config unless the user is trying to view & edit all options in the options dialog. Since skipping this extra repo-config invocation save us a little bit of time its nice to be able to avoid it when we are invoked as git-citool and won't be running very long. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-