| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
|
|
|
|
|
| |
Similar to commit eb8381c8, we need to use for_each_reflog() to make
sure we do not miss objects reachable from HEAD reflog.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the git-svn tests can fail on fast machines due to a race in
Subversion: if a file is modified in the same second it was checked out
(or in for that matter), Subversion will not consider it modified. This
works around the problem by increasing the timestamp by one second
before each commit.
[jc: with "touch -r -d" replacement from Eric]
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
|
|
|
|
|
|
| |
The old text suggested that git-update-server-info only needs to be run
if new tags or branches are created, but not for new commits.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
|
|
|
|
|
| |
Also spawn the the new blameview in the background
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
|
|
|
|
|
| |
Changed -m=<msg> to -m <msg> too.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subtle bugs remained on both Cygwin and Linux that caused the various
window panes to be restored in positions different than where the user
last placed them. Sergey Vlasov posed a pair of suggested fixes to this,
what is done here is slightly different. The basic fix here involves
a) explicitly remembering and restoring the sash positions for the upper
window, and b) using paneconfigure to redundantly set height and width of
other elements. This redundancy is needed as Cygwin Tcl has a nasty habit
of setting pane sizes to zero if their slaves are not configured with a
specific size, but Linux Tcl does not honor the specific size given.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
|
|
| |
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |
|
|
|
|
|
|
|
|
| |
I'm exporting gitexecdir because git-gui wants to know where
it should install git-gui and git-citool. These belong under
gitexecdir, just like git-diff, as the git wrapper is able to
invoke these commands for the end-user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 'master' of git://repo.or.cz/git-gui:
git-gui: Change base version to 0.6.
git-gui: Guess our version accurately as a subproject.
git-gui: Handle gitgui tags in version gen.
git-gui: Generate a version file on demand.
git-gui: Rename GIT_VERSION to GITGUI_VERSION.
git-gui: Allow gitexecdir, INSTALL to be set by the caller.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
There is a bug with this $git_mode variable which should be 0644
or 0755, but nothing else I think.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It was suggested on the mailing list that being able to use `from`
in any commit to reset the current branch is useful in some types of
importers, such as a darcs importer.
We originally did not permit resetting an existing branch with a
new `from` command during a `commit` command, but this restriction
was only to help debug the hacked up cvs2svn that Jon Smirl was
developing in parallel with git-fast-import. It is probably more
of a problem to disallow it than to allow it. So now we permit a
`from` during any `commit`.
While making the changes required to permit multiple `from`
commands on the same branch, I discovered we no longer needed the
last_commit field to be set to 0 during a reset, so that was removed.
(Reset was originally setting the field to 0 to signal cmd_from()
that it was OK to execute on the branch.)
While poking around in this section of fast-import I also realized
the `reset` command was not working as intended if the corresponding
`from` command was omitted (as allowed by the BNF grammar and the
code). If `from` was omitted we cleared out the tree but we left
the tree SHA-1 and parent commit SHA-1 intact. This is not what
the user intended in this case. Instead they would be trying to
reset the branch to have no parent and to have no tree, making the
branch look new-born during the next commit. We now clear these
SHA-1 values during `reset`, ensuring the branch looks new-born if
`from` does not get supplied.
New test cases for these were also added.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
This merges git-gui project of Shawn as a subproject of git.git
at git-gui/ subdirectory.
This merge only melds two histories together. The toplevel Makefile
does not even know about git-gui yet.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| | |
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| | |
These are now controlled by the transport and branch options, rather
than the multicommit option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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: Shawn O. Pearce <spearce@spearce.org>
|
