In both the ff and reset merge_types supported by checkout_op the
result is the same if the merge base of our target commit and the
existing commit is the existing commit: its a fast-forward as the
existing commit is fully contained in the target commit.
This minor cleanup in logic will make it easier to implement a
new kind of merge_type that actually merges the two trees with a
real merge strategy, such as git-merge-recursive.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I've decided to teach checkout_op how to perform more than just a
fast-forward and reset type of merge. This way we can also do a full
recursive merge even when we are recreating an existing branch from
a remote. To help with that process I'm saving the merge-base we
computed during the ff/reset/fail decision process, in case we need
it later on when we actually start a true merge operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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: Shawn O. Pearce <spearce@spearce.org>
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: Shawn O. Pearce <spearce@spearce.org>
