- 18 7月, 2007 7 次提交
-
-
由 Shawn O. Pearce 提交于
By moving our feature option determination up before we look for GIT_DIR we can make a decision about whether or not we need a working tree up front, before we look for GIT_DIR. A future change could then allow us to start in a bare Git repository if we only need access to the ODB. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
I'm moving the code related to looking to see if we should GC now into a procedure closer to where it belongs, the database module. This reduces our script by a few lines for the single commit case (aka citool). But really it just is to help organize the code. We now perform the check after we have been running for at least 1 second. This way the main window has time to open up and our dialog (if we open it) will attach to the main window, instead of floating out in no-mans-land like it did before on Mac OS X. I had to use a wait of a full second here as a wait of 1 millisecond made our console install itself into the main window. Apparently we had a race condition with the console code where both the console and the main window thought they were the main window. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Some users may do odd things, like tag their own private version of Git with an annotated tag such as 'testver', then compile that git and try to use it with git-gui. In such a case `git --version` will give us 'git version testver', which is not a numeric argument that we can pass off to our version comparsion routine. We now check that the cleaned up git version is a going to pass the version comparsion routine without failure. If it has a non-numeric component, or lacks at least a minor revision then we ask the user to confirm they really want to use this version of git within git-gui. If they do we shall assume it is git 1.5.0 and run with only the code that will support. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Instead of running a full git-count-objects to count all of the loose objects we can get a reasonably close approximation by counting the number of files in the .git/objects/42 subdirectory. This works out reasonably well because the SHA-1 hash has a fairly even distribution, so every .git/objects/?? subdirectory should get a relatively equal number of files. If we have at least 8 files in .git/objects/42 than it is very likely there is about 8 files in every other directory, leaving us with around 2048 loose objects. This check is much faster, as we need to only perform a readdir of a single directory, and we can do it directly from Tcl and avoid the costly fork+exec. All of the credit on how clever this is goes to Linus Torvalds; he suggested using this trick in a post commit hook to repack every so often. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we have more than our desired number of objects and we try to open the "Do you want to repack now?" dialog we cannot include a -parent . argument if the main window has not been mapped yet. On Mac OS X it appears this window isn't mapped right away, so we had better hang avoid including it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Not every caller of 'git' or 'git_pipe' wants to use nice to lower the priority of the process its executing. In many cases we may never use the nice process to launch git. So we can avoid searching our $PATH to locate a suitable nice if we'll never actually use it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Julian Phillips 提交于
The git-gui version check doesn't handle versions of the form n.n.n.GIT which you can get by installing from an tarball produced by git-archive. Without this change you get an error of the form: 'Error in startup script: expected version number but got "1.5.3.GIT"' Signed-off-by: NJulian Phillips <julian@quantumfyre.co.uk> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 17 7月, 2007 2 次提交
-
-
由 Shawn O. Pearce 提交于
On Windows (which includes Cygwin) Tcl defaults to leaving the EOF character of input file streams set to the ASCII EOF character, but if that character were to appear in the data stream then Tcl will close the channel early. So we have to disable eofchar on Windows. Since the default is disabled on all platforms except Windows, we can just disable it everywhere to prevent any sort of read problem. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
My prior change to allow git-gui to run with a version of Git that was built from a working directory that had uncommitted changes didn't account for the pattern starting with -, and that confused Tcl. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 16 7月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
If the user is running a 'dirty' version of git (one compiled in a working directory with modified files) we want to just assume it was a committed version, as we really only look at the part that came from a real annotated tag anyway. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 12 7月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
This cat-file was done on maint, where we did not have git_read available to us. But here on master we do, so we should make use of it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
* maint: git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}
-
由 Shawn O. Pearce 提交于
From Johannes Sixt <J.Sixt@eudaptics.com>: > It seems that MSYS's wish does some quoting for Bourne shells, > in particular, escape the first '{' of the "^{tree}" suffix, but > then it uses cmd.exe to run "git rev-parse". However, cmd.exe does > not remove the backslash, so that the resulting rev expression > ends up in git's guts as unrecognizable garbage: rev-parse fails, > and git-gui hickups in a way that it must be restarted. Johannes originally submitted a patch to this section of commit.tcl to use `git rev-parse $PARENT:`, but not all versions of Git will accept that format. So I'm just taking the really simple approach here of scanning the first line of the commit to grab its tree. About the same cost, but works everywhere. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 10 7月, 2007 6 次提交
-
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Because we are trying to execute /bin/sh we know it must be a real Windows executable and thus ends with the standard .exe suffix. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
We cannot execute the git directory, it is not a valid Tcl command name. Instead we just want to pass it as an argument to our sq proc. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
* maint: git-gui: Don't linewrap within console windows git-gui: Correct ls-tree buffering problem in browser
-
由 Shawn O. Pearce 提交于
If we get more than 80 characters of text in a single line odds are it is output from git-fetch or git-push and its showing a lot of detail off to the right edge that is not so important to the average user. We still want to make sure we show everything we need, but we can get away with that information being off to the side with a horizontal scrollbar. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Our file browser was showing bad output as it did not properly buffer a partial record when read from `ls-tree -z`. This did not show up on my Mac OS X system as most trees are small, the pipe buffers generally big and `ls-tree -z` was generally fast enough that all data was ready before Tcl started to read. However on my Cygwin system one of my production repositories had a large enough tree and packfile that it took a couple of pipe buffers for `ls-tree -z` to complete its dump. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 09 7月, 2007 21 次提交
-
-
由 Shawn O. Pearce 提交于
We now embed any GIT_* and SSH_* environment variables as well as the path to the git wrapper executable into the Mac OS X .app file. This should allow us to restore the environment properly when we restart. We also try to use proper Bourne shell single quoting when we can, as this avoids any sort of problems that might occur due to a path containing shell metacharacters. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that we are pretty strict about setting up own absolute paths to any git helper (saving a marginal runtime cost to resolve the tool) we can do the same in our console widget by making sure all console execs go through git_read if they are a git subcommand, and if not make sure they at least try to use the Tcl 2>@1 IO redirection if possible, as it should be faster than |& cat. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we cannot locate a .exe for a git tool that we want to run than it may just be a Bourne shell script as these are popular in Git. In such a case the first line of the file will say "#!/bin/sh" so a UNIX kernel knows what program to start to parse and run that. But Windows doesn't support shbang lines, and neither does the Tcl that comes with Cygwin. We can pass control off to the git wrapper as that is a real Cygwin program and can therefore start the Bourne shell script, but that is at least two fork+exec calls to get the program running. One to do the fork+exec of the git wrapper and another to start the Bourne shell script. If the program is run multiple times it is rather expensive as the magic shbang detection won't be cached across executions. On MinGW/MSYS we don't have the luxury of such magic detection. The MSYS team has taught some of this magic to the git wrapper, but again its slower than it needs to be as the git wrapper must still go and run the Bourne shell after it is called. We now attempt to guess the shbang line on Windows by reading the first line of the file and building our own command line path from it. Currently we support Bourne shell (sh), Perl and Python. That is the entire set of shbang lines that appear in git.git today. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
We know that the version subcommand of git is special. It does not currently have an executable link installed into $gitexecdir and we therefore would never match it with one of our file exists tests. So we forward any invocations to it directly to the git wrapper, as it is a builtin within that executable. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we cannot locate a command in $gitexecdir on our own then it may just be because we are supposed to run it by `git $name` rather than by `git-$name`. Many commands are now builtins, more are likely to go in that direction, and we may see the hardlinks in $gitexecdir go away in future versions of git. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
The master Makefile in git.git installs gitk into bindir, not gitexecdir, which means gitk is located as a sibling of the git wrapper and not as though it were a git helper tool. We can also avoid some Tcl concat operations by letting eval do all of the heavy lifting; we have two proper Tcl lists ($cmd and $revs) that we are joining together and $revs is currently never an empty list. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Sometimes switching between branches can take more than a second or two, in which case `git checkout` would normally have shown a small progress meter to the user on the terminal to let them know that we are in fact working, and give them a reasonable idea of when we may finish. We now do obtain that progress meter from read-tree -v and include it in our main window's status bar. This allows users to see how many files we have checked out, how many remain, and what percentage of the operation is completed. It should help to keep users from getting bored during a large checkout operation. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Now that we have a fancy status bar mega-widget we can reuse that within our main window. This opens the door for implementating future improvements like a progress bar. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Our blame viewer has had a very fancy progress bar at the bottom of the window that shows the current status of the blame engine, which includes the number of lines completed as both a text and a graphical meter. I want to reuse this meter system in other places, such as during a branch switch where read-tree -v can give us a progress meter for any long-running operation. This change extracts the code and refactors it as a widget that we can take advantage of in locations other than in the blame viewer. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user double clicks a branch in the checkout dialog then they probably want to start the checkout process on that branch. I found myself doing this without realizing it, and of course it did nothing as there was no action bound to the listbox's Double-Button-1 event handler. Since I did it without thinking, others will probably also try, and expect the same behavior. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If we have specifications listed in our revision picker mega-widget then we should default the selection within that widget to the first ref available. This way the user does not need to use the spacebar to activate the selection of a ref within the box; instead they can navigate up/down with the arrow keys and be done with it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the end-user feeds us an abbreviated SHA-1 on the command line for `git gui browser` or `git gui blame` we now unabbreviate the value through `git rev-parse` so that the title section of the blame or browser window shows the user the complete SHA-1 as Git determined it to be. If the abbreviated value was ambiguous we now complain with the standard error message(s) as reported by git-rev-parse --verify, so that the user can understand what might be wrong and correct their command line. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
This is a major rewrite of the way we perform switching between branches and the subsequent update of the working directory. Like core Git we now use a single code path to perform all changes: our new checkout_op class. We also use it for branch creation/update as it integrates the tracking branch fetch process along with a very basic merge (fast-forward and reset only currently). Because some users have literally hundreds of local branches we use the standard revision picker (with its branch filtering tool) to select the local branch, rather than keeping all of the local branches in the Branch menu. The branch menu listing out all of the available branches is simply not sane for those types of huge repositories. Users can now checkout a detached head by ticking off the option in the checkout dialog. This option is off by default for the obvious reason, but it can be easily enabled for any local branch by simply checking it. We also detach the head if any non local branch was selected, or if a revision expression was entered. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the current branch is not a symbolic-ref that points to a name in the refs/heads/ namespace we now just assume that the head is a detached head. In this case we return the special branch name of HEAD rather than empty string, as HEAD is a valid revision specification and the empty string is not. I have also slightly improved the current-branch function by using string functions to parse the symbolic-ref data. This should be slightly faster than using a regsub. I think the code is clearer too. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user is creating a new local branch and has selected to use a tracking branch as the starting revision they probably want to make sure they are using the absolute latest version available of that branch. We now offer a checkbox "Fetch Tracking Branch" (on by default) that instructs git-gui to run git-fetch on just that one branch before resolving the branch name into a commit SHA-1 and making (or updating) the local branch. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
In some workflows users will want to almost always just create a new local branch that matches a remote branch. In this type of workflow it is handy to have the new branch dialog default to "Match Tracking Branch" and "Starting Revision"-Tracking Branch", with the focus in the branch filter field. This can save users working on this type of workflow at least two mouse clicks every time they create a new local branch or switch to one with a fast-forward. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
When trying to create a branch from a tag most people are looking for a recent tag, not one that is ancient history. Rather than sorting tags by their string we now sort them by taggerdate, as this places the recent tags at the top of the list and the very old ones at the end. Tag date works nicely as an approximation of the actual history order of commits. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
One of my production repositories has hundreds of remote tracking branches. Trying to navigate these through a popup menu is just not possible. The list is far larger than the screen and it does not scroll fast enough to efficiently select a branch name when trying to create a branch or delete a branch. This is major rewrite of the revision chooser mega-widget. We now use a single listbox for all three major types of named refs (heads, tracking branches, tags) and a radio button group to pick which of those namespaces should be shown in the listbox. A filter field is shown to the right allowing the end-user to key in a glob specification to filter the list they are viewing. The filter is always taken as substring, so we assume * both starts and ends the pattern the user wanted but otherwise treat it as a glob pattern. This new picker works out really nicely. What used to take me at least a minute to find and select a branch now takes mere seconds. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
If the user elects to create a local branch that has the same name as an existing branch and we can fast-forward the local branch to the selected revision we might as well do the fast-forward for the user, rather than making them first switch to the branch then merge the selected revision into it. After all, its really just a fast forward. No history is lost. The resulting branch checkout may also be faster if the branch we are switching from is closer to the new revision. Likewise we also now allow the user to reset the local branch if it already exists but would not fast-forward. However before we do the actual reset we tell the user what commits they are going to lose by showing the oneline subject and abbreviated sha1, and we also let them inspect the range of commits in gitk. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-