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>
We used to use lock_any_ref_for_update() because the command
needs to also update HEAD (which is not under refs/, so
lock_ref_sha1() cannot be used). The function however did not
check for refs with illegal characters in them.
Use check_ref_format() to catch malformed refs. For this check,
we specifically do not want to say having less than two levels
in the name is illegal to allow HEAD (and perhaps other special
refs in the future).
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
Document Junio's show-branch trick for finding out which tags are
descendents of a given comit.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I still really want a section on interoperability with CVS, subversion,
etc., but I'm not getting around to it very fast, so just add this to
the TODO section for now. And a few other minor todo updates.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Add a brief discussion of reflogs. Also recovery of dangling commits
seems to fit in here, so move some of the discussion out of Linus's
email to here.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
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>
Direct editing of config files may be more natural for users than using
the git-config commandline; but we should still reference the
git-config man page when we describe such editing, so people know where
to go for details on the config file syntax and meanings of the
variables.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Looks like we're going to allow git-config as the preferred alias to
git-repo-config, so let's document that instead.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Initial import of fsck and dangling objects discussion, mostly lifted from
an email from Linus.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I know it's only an example, but having this might save someone else the
trouble of writing an enhanced version for themselves.
It basically does the same job as the old update hook, but with these
differences:
* The recipients list is read from the repository config file from
hooks.mailinglist
* Updating unannotated tags can be allowed by setting
hooks.allowunannotated
* Announcement emails (via annotated tag creation) can be sent to a
different mailing list by setting hooks.announcelist
* Output email is more verbose and generates specific content depending
on whether the ref is a tag, an annotated tag, a branch, or a
tracking branch
* The email is easier to filter; the subject line is prefixed with
[SCM] and a project description pulled from the "description" file
* It catches (and displays differently) branch updates that are
performed with a --force
Obviously, it's nothing that clever - it's the update hook I use on my
repositories but I've tried to keep it general, and tried to make the
output always relevant to the type of update.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I got bitten because in the UK (where one would expect 1970-01-01 00:00
to be UTC 0) some politicians decided to mess around with daylight
savings time from 1968 to 1971; it was permanently BST (+0100). That
means that on my computer the following is true:
$ date --date="1970-01-01 00:00" +"%F %T %z (%Z)"
1970-01-01 00:00:00 +0100 (BST)
This of course means that the --date argument to date is specified in
local time, not UTC. So when the hooks--update script does this:
date=$(date --date="1970-01-01 00:00:00 $ts seconds")
It's actually saying (in my timezone) "1970-01-01 01:00:00 UTC" + $ts.
Clearly this is wrong. The UNIX epoch started at midnight UTC not 1am
UTC.
This leads to the tagged time in hooks--update being shown as one hour
earlier than the true tagged time (in my timezone). The problem would
be worse for other timezones. For a +1300 timezone on 1970-01-01, the
tagged time would be 13 hours earlier. Oops.
The solution is to force the reference time to UTC, which is what this
patch does. In my timezone:
$ date --date="1970-01-01 00:00 +0000" +"%F %T %z (%Z)"
1970-01-01 01:00:00 +0100 (BST)
Much better.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Love it or hate it, some people actually still program in Tcl. Some
of those programs are meant for interfacing with Git. Programs such as
gitk and git-gui. It may be useful to have Tcl-safe output available
from for-each-ref, just like shell, Perl and Python already enjoy.
Thanks to Sergey Vlasov for pointing out the horrible flaws in the
first and second version of this patch, and steering me in the right
direction for Tcl value quoting.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows pushing over the git:// protocol, and while it's not
authenticated, it could make sense from within a firewalled
setup where nobody but trusted internal people can reach the git
port. git-daemon is possibly easier and faster to set up in the
kind of situation where you set up git instead of CVS inside a
company.
"git-receive-pack" is disabled by default, so you need to enable it
explicitly by starting git-daemon with the "--enable=receive-pack"
command line argument, or by having your config enable it automatically.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* The description of valid colour specifications was rather
incomplete, so fix it so that it actually describes colour specs as
accepted by color_parse().
* The list of colour items allowed in color.diff.BLAH was missing the
`commit' and `whitespace' entries.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Starting a pager defeats the purpose of the incremental output
mode. This changes git-blame to only paginate if --incremental
was not given.
git -p blame --incremental still starts the pager, though.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Being lazy to rely on the cycling N buffers mkpath() and friends
return is nice in general, but it makes it too easy to introduce
new bugs that are "mysterious".
Introduction of read_ref() in create_symref() after calling
git_path() to get the git_HEAD value (i.e. the path to create a
new symref at) consumed more than the available buffers and
broke a later call to mkpath() that derives lockpath from it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This doesn't change the code at all. It is done to make the next patch
more obvious.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If HEAD is tied to a branch then both logs/HEAD and logs/heads/<branch> are
updated. This is also true for any symbolic refs in general, but only HEAD
will see its reflog created automatically.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A ref might be pointing to another ref but only the name of the last ref
is remembered. Let's remember about the first name as well.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows for ref_log_write() to be used in a more flexible way,
and is needed for future changes.
This is only code reorg with no behavior change.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
My prior change to git-describe attempts to print the distance
between the input commit and the best matching tag, but this distance
was usually only an estimate as we always aborted revision walking
as soon as we overflowed the configured limit on the number of
possible tags (as set by --candidates).
Displaying an estimated distance is not very useful and can just be
downright confusing. Most users (heck, most Git developers) don't
immediately understand why this distance differs from the output
of common tools such as `git rev-list | wc -l`. Even worse, the
estimated distance could change in the future (including decreasing
despite no rebase occuring) if we find more possible tags earlier
on during traversal. (This could happen if more tags are merged
into the branch between queries.) These factors basically make an
estimated distance useless.
Fortunately we are usually most of the way through an accurate
distance computation by the time we abort (due to reaching the
current --candidates limit). This means we can simply finish
counting out the revisions still in our commit queue to present
the accurate distance at the end. The number of commits remaining
in the commit queue is probably less than the number of commits
already traversed, so finishing out the count is not likely to take
very long. This final distance will then always match the output of
`git rev-list | wc -l`.
We can easily reduce the total number of commits that need to be
walked at the end by stopping as soon as all of the commits in the
commit queue are flagged as being merged into the already selected
best possible tag. If that's true then there are no remaining
unseen commits which can contribute to our best possible tag's
depth counter, so further traversal is useless.
Basic testing on my Mac OS X system shows there is no noticable
performance difference between this accurate distance counting
version of git-describe and the prior version of git-describe,
at least when run on git.git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you get two different describes at different
times from a non-rewinding branch and they both come up with the same
tag name, you can tell which is the 'newer' one by distance. This is
rather common in practice, so its incredibly useful.
[jc: still needs documentation and fixups when traversal gives up
early.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise a pathname that has funny characters such as LF would
screw up the parsing programs of the output.
Strictly speaking, this is not backward compatible, but the
current output for pathnames that have embedded LF and such
cannot be sanely parsed anyway, and pathnames that only use
characters from the portable pathname character set won't be
affected.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds --incremental option to help GUI porcelains to show
the result from git-blame incrementally. The output gives the
origin information in the same format as the porcelain format.
The first line has commit object name, the line number of the
first line in the group in the original file, the line number of
that file in the final image, and number of lines in the group.
Then subsequent lines show the metainformation for the commit
when the commit is shown for the first time, except the filename
information is always shown (we cannot even make it conditional
to -C option as blame always follows the renaming of the file
wholesale).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
