- 25 11月, 2006 6 次提交
-
-
由 Shawn O. Pearce 提交于
Since the user should not work on a tracking branch we automatically hide any branch which is used as a tracking branch by either a remote.<name>.fetch config entry or by a Pull: line in a remotes file. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'm not currently ready to implement branch switching, so I'm just going to punt on it for now. :-) Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Even though the user shouldn't have a remote branch checked out, if they do we should still show as short of the branch name as possible. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This is an early start at branch management from within git-gui. The branch menu has create/delete command entries to create and delete branches as well as a list of radiobutton entries for each branch found in the repository through for-each-ref. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Apparently I missed the file state MD, which is a file modified and updated in the index but then removed from the working directory. This should be treated just like AD, an added file which has been deleted from the working directory. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Users want to know what branch they are sitting on before making a commit, as they may need to switch to a different branch first. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 24 11月, 2006 1 次提交
-
-
由 Shawn O. Pearce 提交于
Users sometimes need to be able to throw away locally modified files in order to go back to the last committed version of that file. To perform a revert the user must first uninclude each file from the new commit as the working file must at least partially match the index, and we use git-checkout-index to update the working directory. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 23 11月, 2006 1 次提交
-
-
由 Shawn O. Pearce 提交于
Just like prior to a commit its only an informational message that we refuse to perform a pull on a dirty working directory. Therefore we should not use an error icon. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 22 11月, 2006 7 次提交
-
-
由 Shawn O. Pearce 提交于
Since gitk is currently broken on Mac OS X and is unable to start itself when given command line parameters just don't offer the "Visual All Branches" menu option on Mac OS X. Once this feature of gitk is fixed we should change this section of code to make sure a working version of gitk will be executed before we offer the option up to the user. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Sometimes its useful to start gitk with the --all option, to view all of the known branches and tags within this repository. Rather than making the user startup gitk and then edit the view we can pass the option along for them. This also makes it slightly more explicit, that when gitk starts up by default its showing the current branch and not everything. Yes gitk isn't showing that to the user, but the fact that the user had to make a decision between seeing this current branch or all branches will hopefully make them study gitk's display before jumping to a conclusion. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because the Tcl binary distributed with Cygwin tends to not pass along its own environment (the env array) to its children, its unlikely that any Git commands spawned by git-gui will receive the same environment variables that git-gui itself received from the shell which started it. If the user is counting on environment variables to pass down, like say GIT_INDEX_FILE, they may not, so we warn them during git-gui startup that things may not work out as the user intended. Perhaps one day when git-gui and git are running on native Windows (rather than through the Cygwin emulation layers) things will work better. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Darwn based UNIX systems are not necessarily Mac OS X. However the only windowing system used by Tk that is Mac OS X is 'aqua', and only 'aqua' exists on Mac OS X. Therefore this is a more reliable test for the Macintosh platform. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Like the is_MacOSX proc we shouldn't keep repeating the platform test for Windows. Instead abstract the code out into a procedure and use the procedure whenever we need to do something special. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 21 11月, 2006 10 次提交
-
-
由 Shawn O. Pearce 提交于
Users may need to know what version of Tcl they are running git-gui under, in case there is an interesting interface quirk or other compatability problem we don't know about right now that we may need to explore (and maybe fix). Since its simple enough to show a line with this version data we should do so. We also try to reduce the amount of text shown as often the Tcl and Tk version numbers will be identical; when this happens we should only show the one version number. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The copyright notice we display in the about dialog should be the same as the one at the top of our source code. By putting the copyright notice that appears at the top of our source code into a global variable rather than a comment we can trivially make them the same at all times. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
It is tradition for applications to store their about and preferences menu options within the application menu. This is the first menu in the menu bar, just after the apple menu. Apparently the way to access this menu from Tk on Mac OS X systems is to create a special menu whose name ends in ".apple" and place it into the menu bar. So now if we are on Mac OS X we move our about menu and our options menu into the application menu, like other Mac OS X applications. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Created a help menu with an about dialog box. This about dialog shows the copyright notice for the application, the fact that it is covered by the GPL v2.0 or later, the authors, and the current version of Git it is invoking when users perform actions within it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since all of the actions in our Project menu actually apply to the Git concept of a repository, it is a disservice to our users to call it "project". This is especially true if Git ever gets any sort of subproject support, as the term would then most definately conflict. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The project menu is just too cluttered without using separator entries to split out the database operations (such as repack and verify) from the other options in the same menu. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
It would be something of a disservice to our users if we refer to fsck-objects as "verify". So instead we call it fsck-objects in the console title, and indicate that's how we are verifying the object database. We probably should call our menu option "fsck-objects" or similar but I really do think that "Verify Database" more accurately describes the action then "fsck-objects" does, especially to users who aren't file system developers. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because we don't automatically restart in amend mode when we quit while in amend mode the commit message buffer shouldn't be saved to GITGUI_MSG as it would be misleading when the user restarts the application. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I recently found a need to run fsck-objects in a number of repositories that I also use git-gui against. Tossing in a menu option to invoke fsck-objects and have its output show up in a console window is simple enough to do. We probably need to enhance the console window used by fsck-objects, like to open up the Git fsck-objects manual page and let the user see what each message means (such as "dangling commit") and to also let the user invoke prune, to cleanup any such dangling objects. But right now I'm going to ignore that problem in favor of getting other more important features implemented. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Its useful to be able to amend the last commit even if it was a merge commit, so we really should support that in the gui. We now do so by making PARENT a list. We always diff against the first parent but we create a commit consisting of the parent(s) listed in this list, in order. We also should recheck the repository state during an amend. Earlier I was bitten by this exact bug when I switched branches through a command prompt and then did not do a rescan in git-gui. When I hit "Amend Last Commit" I was surprised to see information from the prior branch appear. This was due to git-gui caching the data from the last rescan and using that data form the amend data load request, rather than the data of the current branch. Improved error text in the dialogs used to tell the user why an amend is being refused by git-gui. In general this is only during an initial commit (nothing prior to amend) and during a merge commit (it is simply too confusing to amend the last commit while also trying to complete a merge). Fixed a couple of minor bugs in the pull logic. Since this code isn't really useful nobody has recently tested it and noticed the breakage. It really needs to be rewritten anyway. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 19 11月, 2006 15 次提交
-
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
In order to allow the user to toggle include/exclude from next commit for files which were partially included in the last commit we need the current index mode+sha1 data stored in our file_states array. For any partially included file we have this information from diff-files, so we just have to copy it over to the diff-index portion of our state array. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Accidentally removed by an unnoticed fat finger accident in vi during commit 1461c5f3. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The tags used for diff formatting (which I inherited from gitool) just didn't make a whole lot of sense, especially if you wanted to try to match them to the diff output you were seeing on screen. It did not help that the diff-index -c output's first two columns are also munged to make the diff output more user friendly. So this is a large refactoring of the tags used for diff display. Now our tag names match what we put in the left column of each line, which makes it easier to correlate presentation and implementation. I removed bold font usage from everything except the hunk headers as I really did not like the way bold font caused column alignments to become out of whack within the diff viewer. It also drew attention to the parts of the file which were identically changed in both the index and in the working directory, yet these are usually the parts I find myself caring the least about. So its very counter-intuitive. Lines which are changed differently by both the index and the working directory are now shown with background colors which span the entire line, making these lines easier to pick out of the diff. In general these are the lines that appear to be more interesting to me when looking at the 3-way diff as they are the ones which contain recent and quite different changes. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
New files also lack index data from diff-files therefore we cannot use their diff-files index data when we update-index. Instead we can use the fact that Git has them hardcoded as "0 0{40}" and do the same thing ourselves. This way you can toggle an untracked file into added status and back out to untracked. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Currently core-git's diff utilities report a deleted symlink as a deleted file with a mode of 120000. This is not nearly as user friendly as one might like, as the user must remember that 120000 is the UNIX mode bits for a symlink. So instead we transform the not-so-friendly message from core-git into a slightly more user friendly "deleted symlink" message. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Tcl let me assign two different types of values to the variable $n. Prior to 1461c5f3 $n was the total number of bytes in the string; but in that commit it also became the current info list for the current file. This caused $c < $n to fail as $n was now treated as 0 and we only loaded the first file in each buffer. So use a different variable, like $i, instead. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
There was a bug with the way we handled deleted file status. A file really shouldn't be in D_ state when it has been deleted, instead it is really DD. Therefore we should have toggled _D to DD, not D_, thereby letting us toggle back to _D. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user clicks on the icon associated with a file we now flip to the inverse status. Partially included files first fully include, then fully uninclude, as we don't keep track of intermediate partial inclusions. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Sometimes the user may want to keep their working directory file to be the same content but they don't want it to be part of the current commit anymore. In this case we need to undo any changes made to the index for that file (by reloading the info from HEAD or removing the file from the index) but leave the working directory alone. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Turns out that we really don't need the Contents/PkgInfo file on Mac OS 10.4. The Finder will still launch the application properly without one. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The previous implementation of do_include_selection did not actually add files in state _O (untracked, not added) into the repository when they were in the selection and Commit->Include Selected Files was used. This was due to the file state filtering logic being the same as that of Commit->Include All Files, which only considers existing files. Also fixed a minor issue with rejected attempts to amend an initial commit. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Its not an error that a rescan is required before commit; its just something we do as a safety feature to try and ensure the user knows what is going into this commit. So the dialog should use the info icon (if one is used by the host OS) rather than the error icon. Its also not "highly likely" that another Git program modified the repository, its completely the case. There is no reason why the repository would not match our last scanned state unless another Git program modified the repository (or someone else did so by hand). So don't be vague about it, own up to the issue and go on with our business. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Since git-commit also checks that the user has a GIT_COMMITTER_IDENT value before it lets the user make a commit we should do the same check here in git-gui. We cache the result and assume that the user won't do something which would change the status of GIT_COMMITTER_IDENT while we are running. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-