tokkee.org

Merge branch 'master' of git://repo.or.cz/git-gui

* 'master' of git://repo.or.cz/git-gui:
  git-gui: Save geometry before the window layout is damaged
  git-gui: Give amend precedence to HEAD over MERGE_MSG
  git-gui: Include 'war on whitespace' fixes from git.git

Merge branch 'maint'

* maint:
  git-gui: Save geometry before the window layout is damaged
  git-gui: Give amend precedence to HEAD over MERGE_MSG

git-gui: Save geometry before the window layout is damaged

Because Tk does not assure us the order that it will process
children in before it destroys the main toplevel we cannot safely
save our geometry data during a "bind . <Destroy>" event binding.
The geometry may have already changed as a result of a one or
more children being removed from the layout.  This was pointed
out in gitk by Mark Levedahl, and patched over there by commit
b6047c5a8166a71e01c6b63ebbb67c6894d95114.

So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when
the window is closed by the user, and forward that close event to
our main do_quit routine.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Give amend precedence to HEAD over MERGE_MSG

Apparently git-commit.sh (the command line commit user interface in
core Git) always gives precedence to the prior commit's message if
`commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists.

We actually were doing the same here in git-gui, but the amended
message got lost if $GIT_DIR/MERGE_MSG already existed because
we started a rescan immediately after loading the prior commit's
body into the edit buffer.  When that happened the rescan found
MERGE_MSG existed and replaced the commit message buffer with the
contents of that file.  This meant the user never saw us pick up
the commit message of the prior commit we are about to replace.

Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by
running `git cherry-pick -n $someid` and then trying to amend the
prior commit in git-gui, thus combining the contents of $someid
with the contents of HEAD, and reusing the commit message of HEAD,
not $someid.  With the recent changes to make cherry-pick use the
$GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message
of $someid, not HEAD.  Now we always use HEAD if we are amending.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'maint'

* maint:
  git-gui: Include 'war on whitespace' fixes from git.git

git-gui: Include 'war on whitespace' fixes from git.git

Earlier git.git applied a large "war on whitespace" patch that was
created using 'apply --whitespace=strip'.  Unfortunately a few of
git-gui's own files got caught in the mix and were also cleaned up.
That was a6080a0a44d5ead84db3dabbbc80e82df838533d.

This patch is needed in git-gui.git to reapply those exact same
changes here, otherwise our version generator script is unable to
obtain our version number from git-describe when we are hosted in
the git.git repository.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'master' of git://repo.or.cz/git-gui

* 'master' of git://repo.or.cz/git-gui:
  git-gui: Internalize symbolic-ref HEAD reading logic
  git-gui: Expose the merge.diffstat configuration option
  git-gui: Allow users to delete remote branches
  git-gui: Allow users to rename branches through 'branch -m'
  git-gui: Disable tearoff menus on Windows, Mac OS X
  git-gui: Provide fatal error if library is unavailable
  git-gui: Enable verbose Tcl loading earlier
  git-gui: Show the git-gui library path in 'About git-gui'
  git-gui: GUI support for running 'git remote prune <name>'
  git gui 0.8.0

Merge branch 'maint'

* maint: (46 commits)
  git-gui: Changed blame header bar background to match main window
  git-gui: Favor the original annotations over the recent ones
  git-gui: Improve our labeling of blame annotation types
  git-gui: Use three colors for the blame viewer background
  git-gui: Jump to original line in blame viewer
  git-gui: Display both commits in our tooltips
  git-gui: Run blame twice on the same file and display both outputs
  git-gui: Display the "Loading annotation..." message in italic
  git-gui: Rename fields in blame viewer to better descriptions
  git-gui: Label the uncommitted blame history entry
  git-gui: Switch internal blame structure to Tcl lists
  git-gui: Cleanup redundant column management in blame viewer
  git-gui: Better document our blame variables
  git-gui: Remove unused commit_list from blame viewer
  git-gui: Automatically expand the line number column as needed
  git-gui: Make the line number column slightly wider in blame
  git-gui: Use lighter colors in blame view
  git-gui: Remove unnecessary space between columns in blame viewer
  git-gui: Remove the loaded column from the blame viewer
  git-gui: Clip the commit summaries in the blame history menu
  ...

Merge branch 'maint' of git://repo.or.cz/git-gui into maint

* 'maint' of git://repo.or.cz/git-gui: (46 commits)
  git-gui: Changed blame header bar background to match main window
  git-gui: Favor the original annotations over the recent ones
  git-gui: Improve our labeling of blame annotation types
  git-gui: Use three colors for the blame viewer background
  git-gui: Jump to original line in blame viewer
  git-gui: Display both commits in our tooltips
  git-gui: Run blame twice on the same file and display both outputs
  git-gui: Display the "Loading annotation..." message in italic
  git-gui: Rename fields in blame viewer to better descriptions
  git-gui: Label the uncommitted blame history entry
  git-gui: Switch internal blame structure to Tcl lists
  git-gui: Cleanup redundant column management in blame viewer
  git-gui: Better document our blame variables
  git-gui: Remove unused commit_list from blame viewer
  git-gui: Automatically expand the line number column as needed
  git-gui: Make the line number column slightly wider in blame
  git-gui: Use lighter colors in blame view
  git-gui: Remove unnecessary space between columns in blame viewer
  git-gui: Remove the loaded column from the blame viewer
  git-gui: Clip the commit summaries in the blame history menu
  ...

Merge branch 'maint'

* maint: (38 commits)
  git-gui: Changed blame header bar background to match main window
  git-gui: Favor the original annotations over the recent ones
  git-gui: Improve our labeling of blame annotation types
  git-gui: Use three colors for the blame viewer background
  git-gui: Jump to original line in blame viewer
  git-gui: Display both commits in our tooltips
  git-gui: Run blame twice on the same file and display both outputs
  git-gui: Display the "Loading annotation..." message in italic
  git-gui: Rename fields in blame viewer to better descriptions
  git-gui: Label the uncommitted blame history entry
  git-gui: Switch internal blame structure to Tcl lists
  git-gui: Cleanup redundant column management in blame viewer
  git-gui: Better document our blame variables
  git-gui: Remove unused commit_list from blame viewer
  git-gui: Automatically expand the line number column as needed
  git-gui: Make the line number column slightly wider in blame
  git-gui: Use lighter colors in blame view
  git-gui: Remove unnecessary space between columns in blame viewer
  git-gui: Remove the loaded column from the blame viewer
  git-gui: Clip the commit summaries in the blame history menu
  ...

gitweb: '--cc' for merges in 'commitdiff' view

Allow choosing between '-c' (combined diff) and '--cc' (compact
combined) diff format in 'commitdiff' view for merge (multiparent)
commits.  Default is now '--cc'.

In the bottom part of navigation bar there is link allowing to change
diff format: "combined" for '-c' (when using '--cc') and "compact" for
'--cc' (when using '-c'), just on the right of "raw" link to
'commitdiff_plain" view.

About patchset part of diff --cc output: the difftree (whatchanged
table) has "patch" links to anchors to individual patches (on the same
page). The --cc option further compresses the patch output by
omitting some hunks; when this optimization makes all hunks disappear,
the patch is not shown (like in any other "empty diff" case). But the
fact that patch has been simplified out is not reflected in the raw
(difftree) part of diff output; the raw part is the same for '-c' and
'--cc' options. As correcting difftree is rather out of the question,
as it would require scanning patchset part before writing out
difftree, we add "Simple merge" empty diffs as a place to have anchor
to in place of those simplified out and removed patches.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Add links to blobdiffs in from-file/to-file header for merges

Add links to diff to file ('blobdiff' view) for each of individual
versions of the file in a merge commit to the from-file/to-file header
in the patch part of combined 'commitdiff' view for merges.

The from-file/to-file header for combined diff now looks like:

  --- _1_/_git-gui/git-gui.sh_
  --- _2_/_git-gui.sh_
  +++ b/_git-gui/git-gui.sh_

where _<filename>_ link is link to appropriate version of a file
('blob' view), and _<n>_ is link to respective diff to mentioned
version of a file ('blobdiff' view). There is even hint provided in
the form of title attribute.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Create special from-file/to-file header for combined diff

Instead of using default, diff(1) like from-file/to-file header for
combined diff (for a merge commit), which looks like:

  --- a/git-gui/git-gui.sh
  +++ b/_git-gui/git-gui.sh_

(where _link_ denotes [hidden] hyperlink), create from-file(n)/to-file
header, using "--- <n>/_<filename>_" for each of parents, e.g.:

  --- 1/_git-gui/git-gui.sh_
  --- 2/_git-gui.sh_
  +++ b/_git-gui/git-gui.sh_

Test it on one of merge commits involving rename, e.g.
  95f97567c1887d77f3a46b42d8622c76414d964d (rename at top)
  5bac4a671907604b5fb4e24ff682d5b0e8431931 (file from one branch)

This is mainly meant to easier see renames in a merge commit.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Split git_patchset_body into separate subroutines

This commit makes git_patchset_body easier to read, and reduces level of
nesting and indent level. It adds more lines that it removes because of
extra parameter passing in subroutines, and subroutine calls in
git_patchset_body. Also because there are few added comments.

Below there are descriptions of all split-off subroutines:

Separate formatting "git diff" header into format_git_diff_header_line.
While at it fix it so it always escapes pathname. It would be even more
useful if we decide to use `--cc' for merges, and need to generate by
hand empty patches for anchors.

Separate formatting extended (git) diff header lines into
format_extended_diff_header_line. This one is copied without changes.

Separate formatting two-lines from-file/to-file diff header into
format_diff_from_to_header subroutine. While at it fix it so it always
escapes pathname. Beware calling convention: it takes _two_ lines.

Separate generating %from and %to hashes (with info used among others to
generate hyperlinks) into parse_from_to_diffinfo subroutine. This one is
copied without changes.

Separate checking if file was deleted (and among others therefore does
not have link to the result file) into is_deleted subroutine. This would
allow us to easily change the algotithm to find if file is_deleted in
the result.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Improve "next" link in commitdiff view

Check if 'hp' (hash_parent) parameter to 'commitdiff' view is one of
'h' (hash) commit parents, i.e. if commitdiff is of the form
"<commit>^<n> <commit>", and mark it as such in the bottom part of
navigation bar. The "next" link in commitdiff view was introduced
in commit 151602df00b8e5c5b4a8193f59a94b85f9b5aebc

If 'hb' is n-th parent of 'h', show the following at the bottom
of navigation bar:
  (from parent n: _commit_)

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Provide links to commitdiff to each parent in 'commitdiff' view

Since commit-fb1dde4a we show combined diff for merges in 'commitdiff'
view, and since commit-208ecb2e also in 'commit' view. Sometimes
though one would want to see diff to one of merge commit parents. It
is easy in 'commit' view: in the commit header part there are "diff"
links for each of parent header. This commit adds such links also for
'commitdiff' view.

Add to difftree / whatchanged table row with "1", "2", ... links to
'commitdiff' view for diff with n-th parent for merge commits, as a
table header.  This is visible only in 'comitdiff' view, and only for
a merge commit (comit with more than one parent).

To save space links are shown as "n", where "n" is number of a parent,
and not as for example shortened (to 7 characters) sha1 of a parent
commit.  To make it easier to discover what links is for, each link
has 'title' attribute explaining the link.

Note that one would need to remember that difftree table in 'commit'
view has one less column (it doesn't have "patch" link column), if one
would want to add such table header also in 'commit' view.

Example output:
                          1       2       3
  Makefile      patch | diff1 | diff2 | diff3 | blob | history
  cache.h       patch | diff1 | diff2 | diff3 | blob | history

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  tutorial: use "project history" instead of "changelog" in header
  Documentation: user-manual todo
  user-manual: add a missing section ID
  Fix typo in remote branch example in git user manual
  user-manual: quick-start updates

mktag: minimally update the description.

It lacked a description for the (historically) optional tagger header line.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: add an explicit rule for building assembly output

In the kernel we have a rule for *.c -> *.s files exactly because
it's nice to be able to easily say "ok, what does that generate".

Here's a patch to add such a rule to git too, in case anybody is
interested. It makes it much simpler to just do

make sha1_file.s

and look at the compiler-generated output that way, rather than having to
fire up gdb on the resulting binary.

(Add -fverbose-asm or something if you want to, it can make the result
even more readable)

[jc: add *.s to .gitignore]

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tutorial: use "project history" instead of "changelog" in header

The word "changelog" seems a little too much like jargon to me, and beginners
must understand section headers so they know where to look for help.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

Documentation: user-manual todo

Some more user-manual todo's: how to share objects between repositories, how to
recover.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: add a missing section ID

I forgot to give an ID for this section.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

Fix typo in remote branch example in git user manual

In Documentation/user-manual.txt the example
 $ git checkout --track -b origin/maint maint
under "Getting updates with git pull", should read
 $ git checkout --track -b maint origin/maint

This was noticed by Ron, and reported through
 http://bugs.debian.org/427502

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

user-manual: quick-start updates

Update text to reflect new position in appendix.

Update the name to reflect the fact that this is closer to reference
than tutorial documentation (as suggested by Jonas Fonseca).

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

git-mergetool: Make default selection of merge-tool more intelligent

Make git-mergetool prefer meld under GNOME, and kdiff3 under KDE.  When
considering emerge and vimdiff, check $VISUAL and $EDITOR to see which the
user might prefer.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Josh Triplett <josh@freedesktop.org>

[PATCH] git-mergetool: Allow gvimdiff to be used as a mergetool

Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Acked-by: "Theodore Ts'o" <tytso@mit.edu>

Merge branch 'maint'

* maint:
  Make command description imperative statement, not third-person present.

Remove unnecessary code and comments on non-existing 8kB tag object restriction

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Make command description imperative statement, not third-person present.

In several of the text messages, the tense of the verb is inconsistent.
For example, "Add" vs "Creates".  It is customary to use imperative for
command description.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5000: silence unzip availability check

unzip -v on (at least) Ubuntu prints a screenful of version info
to stdout.  Get rid of it since we only want to know if unzip is
installed or not.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>

Merge branch 'aj/pack'

* aj/pack:
  pack-check: Sort entries by pack offset before unpacking them.

Merge branch 'js/merge'

* js/merge:
  git-merge-file: refuse to merge binary files

cmd_log_init: remove parsing of --encoding command line parameter

This was moved to the setup_revisions parsing in 7cbcf4d5, so it was
never being triggered.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ar/wildcardpush'

* ar/wildcardpush:
  Test wildcard push/fetch
  Fix push with refspecs containing wildcards

Merge branch 'ar/clone'

* ar/clone:
  Fix clone to setup the origin if its name ends with .git

Merge branch 'maint'

* maint:
  checkout: do not get confused with ambiguous tag/branch names

Even more missing static

Signed-off-by: Junio C Hamano <gitster@pobox.com>

More missing static

Signed-off-by: Junio C Hamano <gitster@pobox.com>

More missing static

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Missing statics.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Active_nr is unsigned, hence can't be < 0

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cvsserver: Make req_Root more critical of its input data

The path submitted with the Root request has to be absolute
(cvs does it this way and it may save us some sanity checks
later)

If multiple roots are specified (e.g. because we use
pserver authentication which will already include the
root), ensure that they say all the same.

Probably neither is a security risk, and neither should ever
be triggered by a sane client, but when validating
input data, it's better to be save than sorry.

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitview: Define __slots__ for Commit

Define __slots__ for the Commit class. This reserves space in each Commit
object for only the defined variables. On my system this reduces heap usage
when viewing a kernel repo by 12% ~= 55868 KB.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitview: Use new-style classes

This changes the Commit class to use new-style class, which has
been available since Python 2.2 (Dec 2001).  This is a necessary
step in order to use __slots__[] declaration, so that we can
reduce the memory footprint in the next patch.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout: do not get confused with ambiguous tag/branch names

Although it is not advisable, we have always allowed a branch
and a tag to have the same basename (i.e. it is not illegal to
have refs/heads/frotz and refs/tags/frotz at the same time).
When talking about a specific commit, the interpretation of
'frotz' has always been "use tag and then check branch",
although we warn when ambiguities exist.

However "git checkout $name" is defined to (1) first see if it
matches the branch name, and if so switch to that branch; (2)
otherwise it is an instruction to detach HEAD to point at the
commit named by $name.  We did not follow this definition when
$name appeared under both refs/heads/ and refs/tags/ -- we
switched to the branch but read the tree from the tagged commit,
which was utterly bogus.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Test wildcard push/fetch

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix push with refspecs containing wildcards

Otherwise

    git push 'remote-name' 'refs/heads/*:refs/remotes/other/*'

will consider references in "refs/heads" of the remote repository
"remote-name", instead of the ones in "refs/remotes/other", which
the given refspec clearly means.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: Changed blame header bar background to match main window

The main window's diff header bar background switched from orange
to gold recently, and I liked the effect it had on readability of
the text.  Since I wanted the blame viewer to match, here it is.

Though this probably should be a user defined color, or at least
a constant somewhere that everyone can reference.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

War on whitespace

This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time.  There are a few files that need
to have trailing whitespaces (most notably, test vectors).  The results
still passes the test, and build result in Documentation/ area is unchanged.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix clone to setup the origin if its name ends with .git

The problem is visible when cloning a local repo. The cloned
repository will have the origin url setup incorrectly: the origin name
will be copied verbatim in origin url of the cloned repository.
Normally, the name is to be expanded into absolute path.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack-check: Sort entries by pack offset before unpacking them.

Because of the way objects are sorted in a pack, unpacking them in
disk order is much more efficient than random access. Tests on the
Wine repository show a gain in pack validation time of about 35%.

Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'sv/objfixes'

* sv/objfixes:
  Don't assume tree entries that are not dirs are blobs
  git-cvsimport: Make sure to use $git_dir always instead of .git sometimes
  fix documentation of unpack-objects -n
  Accept dates before 2000/01/01 when specified as seconds since the epoch

Don't assume tree entries that are not dirs are blobs

When scanning the trees in track_tree_refs() there is a "lazy" test
that assumes that entries are either directories or files.  Don't do
that.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-cvsimport: Make sure to use $git_dir always instead of .git sometimes

CVS import was failing on a couple repos I was trying to import.
I was setting GIT_DIR=newproj.git and using the -i flag, but this bug
was thwarting the effort...  evil CVS.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

fix documentation of unpack-objects -n

unpack-objects -n didn't print the object list as promised on the
manual page, so alter the documentation to reflect the behaviour

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Accept dates before 2000/01/01 when specified as seconds since the epoch

Tests with git-filter-branch on a repository that was converted from
CVS and that has commits reaching back to 1999 revealed that it is
necessary to parse dates before 2000/01/01 when they are specified
as seconds since 1970/01/01. There is now still a limit, 100000000,
which is 1973/03/03 09:46:40 UTC, in order to allow that dates are
represented as 8 digits.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: Remove git-merge-base from PROGRAMS.

git-merge-base is a builtin.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5000: skip ZIP tests if unzip was not found

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'mm/tag'

* mm/tag:
  Teach git-tag about showing tag annotations.

git-branch --track: fix tracking branch computation.

The original code did not take hierarchical branch names into account at all.

Tested-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix typo in git-mergetool

Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add the --numbered-files option to git-format-patch.

With this option, git-format-patch will generate simple
numbered files as output instead of the default using
with the first commit line appended.

This simplifies the ability to generate an MH-style
drafts folder with each message to be sent.

Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

$EMAIL is a last resort fallback, as it's system-wide.

$EMAIL is a system-wide setup that is used for many many many
applications. If the git user chose a specific user.email setup,
then _this_ should be honoured rather than $EMAIL.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

make clean should remove all the test programs too

Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add git-filter-branch to .gitignore

Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: Favor the original annotations over the recent ones

Usually when you are looking at blame annotations for a region of
a file you are more interested in why something was originally
done then why it is here now.  This is because most of the time
when we get original annotation data we are looking at a simple
refactoring performed to better organize code, not to change its
semantic meaning or function.  Reorganizations are sometimes of
interest, but not usually.

We now show the original commit data first in the tooltip.  This
actually looks quite nice as the original commit will usually have an
author date prior to the current (aka move/copy) annotation's commit,
so the two commits will now tend to appear in chronological order.

I also found myself to always be clicking on the line of interest
in the file column but I always wanted the original tracking data
and not the move/copy data.  So I changed our default commit from
$asim_data (the simple move/copy annotation) to the more complex
$amov_data (the -M -C -C original annotation).

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Improve our labeling of blame annotation types

It feels wrong to call the -M -C -C annotations "move/copy tracking"
as they are actually the original locations.  So I'm relabeling
the status bar to show "copy/move tracking annotations" for the
current file (no -M -C -C) as that set of annotations tells us who
put the hunk here (who moved/copied it).  I'm now calling the -M
-C -C pass "original location annotations" as that's what we're
really digging for.

I also tried to clarify some of the text in the hover tooltip.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use three colors for the blame viewer background

To prevent neighboring lines that are different commits from using
the same background color we now use 3 colors and assign them
by selecting the color that is not used before or after the line
in question.  We still color "on the fly" as we receive hunks from
git-blame, but we delay our color decisions until we are getting
the original location data (the slower -M -C -C pass) as that is
usually more fine-grained than the current location data.

Credit goes to Martin Waitz for the tri-coloring concept.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Jump to original line in blame viewer

When the user clicks on a commit link within one of the columns
in the blame viewer we now jump them not just to that commit/file
pair but also to the line of the original file.  This saves the
user a lot of time, as they don't need to search through the new
file data for the chunk they were previously looking at.

We also restore the prior view when the user clicks the back button
to return to a pior commit/file pair that they were looking at.

Turned out this was quite tricky to get working in Tk.  Every time
I tried to jump the text widgets to the correct locations by way
of the "yview moveto" or "see" subcommands Tk performed the change
until the current event finished dispatching, and then reset the
views back to 0, making the change never take place.  Forcing Tk
to run the pending events before we jump the UI resolves the issue.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display both commits in our tooltips

If we have commit data from both the simple blame and the
rename/move tracking blame and they differ than there is a
bigger story to tell.  We now include data from both commits
so that the user can see that this link as moved, who moved
it, and where it originated from.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Run blame twice on the same file and display both outputs

We now perform two passes over any input file given to the blame
viewer.  Our first pass is a quick "git-blame" with no options,
getting the details of how each line arrived into this file.  We
are specifically ignoring/omitting the rename detection logic as
this first pass is to determine why things got into the state they
are in.

Once the first pass is complete and is displayed in the UI we run
a second pass, using the much more CPU intensive "-M -C -C" options
to perform extensive rename/movement detection.  The output of this
second pass is shown in a different column, allowing the user to see
for any given line how it got to be, and if it came from somewhere
else, where that is.

This is actually very instructive when run on our own lib/branch.tcl
script.  That file grew recently out of a very large block of code
in git-gui.sh.  The first pass shows when I created that file, while
the second pass shows the original commit information.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display the "Loading annotation..." message in italic

If the user clicks on a line region that we haven't yet received
an annotation for from git-blame we show them "Loading annotation".
But I don't want the user to confuse this loading message with a
commit whose first line is "Loading annotation" and think we messed
up our display somehow.  Since we never use italics for anything
else, I'm going with the idea that italic slant can be used to show
data is missing/elided out at the time being.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Rename fields in blame viewer to better descriptions

Calling the commit message pane $w_cmit is a tad confusing when
we also have the $w_cgrp column that shows the abbreviated SHA-1s.

So w_cmit -> w_cviewer, as it is the "commit viewer"; and
w_cgrp -> w_amov as it is the "annotated commit + move tracking"
column.  Also changed line_data -> amov_data, as that list is
exactly the results shown in w_amov.

Why call the column "move tracking"?  Because this column holds
data from "git blame -M -C".  I'm considering adding an additional
column that holds the data from "git blame" without -M/-C, showing
who did the copy/move, and when they did it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Label the uncommitted blame history entry

If the user runs the blame viewer on a working directory file
instead of a specific commit-ish then we have no value for the
commit SHA1 or the summary line; this causes the history menu
to get an empty entry at the very bottom.  We now look for this
odd case and call the meny entry "Working Directory".

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Switch internal blame structure to Tcl lists

The Tcl list datatype is significantly faster to work with than
the array type, especially if our indexes are a consecutive set
of numbers, like say line numbers in a file.

This rather large change reorganizes the internal data structure
of the blame viewer to use a proper Tcl list for the annotation
information about a line.  Each line is given its own list within
the larger line_data list, where the indexes correspond to various
facts about that particular line.

The interface does seem to be more responsive this way, with less
time required by Tcl to process blame, and to switch to another
version of the same file.  It could just be a placebo effect, but
either way most Tcl experts perfer lists for this type of work over
arrays.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Cleanup redundant column management in blame viewer

The code to handle our three different text widgets is a bit
on the messy side as we issue the same command on all three
widgets one at a time.  Adding (or removing) columns from the
viewer is messy, as a lot of locations need to have the new
column added into the sequence, or removed from it.

We also now delete the tags we create for each commit when
we switch to display another "commit:path" pair.  This way the
text viewer doesn't get bogged down with a massive number of tags
as we traverse through history.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Better document our blame variables

The array variable "order" used to be used to tell us in what
order each commit was received in.  Recent changes have removed
that need for an ordering and the "order" array is now just a
boolean 'do we have that commit yet' flag.

The colors were moved to fields, so they appear inside of the
blame viewer instance.  This keeps two different concurrently
running blame viewers from stepping on each other's ordering
of the colors in group_colors.

Most of the other fields were moved around a little bit so
that they are organized by major category and value lifespan.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Remove unused commit_list from blame viewer

This list used to store the commits in the order we received
them in.  I originally was using it to update the colors of
the commit before and the commit after the current commit,
but since that interface concept turned out to be horribly
ugly and has been removed we no longer need this list.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Automatically expand the line number column as needed

After we finish reading a chunk of data from the file stream
we know how many digits we need in the line number column to
show the current maximum line number.  If our line number column
isn't wide enough, we should expand it out to the correct width.

Any file over our default allowance of 5 digits (99,999 lines)
is so large that the slight UI "glitch" when we widen the column
out is trivial compared to the time it will take Git to fully do
the annotations.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Make the line number column slightly wider in blame

Most source code files are under 9,999 lines of text, so using a
field width of 5 characters meant that we should have had one char
padding on the left edge (because we right-justify the line number).
Unfortunately when I added the right margin earlier (when I removed
the padding) I ate into the extra character's space, losing the left
margin.  This put the line numbers too close to the commit column in
any file with more than 999 lines in it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use lighter colors in blame view

The colors I originally picked out on a Mac OS X system look a
tad too dark on a Windows 2000 system; the greys are dark enough
to make it difficult to read some lines of text and the green used
to highlight the current commit was also difficult to read text on.

I also added a third grey to the mix, to try and help some files
that wind up with a number of neighboring chunks getting the same
colors.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Remove unnecessary space between columns in blame viewer

On Mac OS X the OS has "features" that like to draw thick black
borders around the text field that has focus.  This is nice if
you want to know where your text is going and are blind as a bat,
but it isn't the best thing to have in a table that is being
faked through the abuse of Tk text widgets.

By setting our takefocus, highlightthickness and padx/y we can
get rid of this border and get our text widgets packed right next
to each other, with no padding between them.  This makes the blame
background color smoothly run across the entire line of commit data,
line number and file content.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Remove the loaded column from the blame viewer

Originally I had placed this loaded column between the line number
and the file line data to help users know if a particular line has
received annotation data or not yet.  This way users would know if
the line(s) they were interested in were ready for viewing, or if
they still had to wait.  It also was an entertaining way for the
user to spend their time waiting for git-blame --incremental to
compute the complete set of annotations.

However it is completely useless now that we show the abbreviated
commit SHA-1 and author initials in the leftmost column.  That area
is empty until we get the annotation data, and as soon as we get it
in we display something there, indicating to the user that there is
now blame data ready.  Further with the tooltips the user is likely
to see the data as soon as it comes in, as they are probably not
keeping their mouse perfectly still.  So I'm removing the field to
save screen space for more useful things, like file content.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Clip the commit summaries in the blame history menu

Some commit lines can get really long when users enter a lot of
text without linewrapping (for example).  Rather than letting the
menu get out of control in terms of width we clip the summary to
the first 50+ characters.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use a label instead of a button for the back button

Apparently Tk on Mac OS X won't draw a button with an image using a
transparent background.  Instead it draws the button using some sort
of 3D effect, even though I asked for no relief and no border.  The
background is also not our orange that we expected it to be.

Earlier I had tried this same trick on Windows and it draws the same
way as the button did, so I'm going to switch to the label as that
seems to be more portable.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Show original filename in blame tooltip

If we have two commits right next to each other in the final
file and they were kept as different blocks in the leftmost
column then its probably because the original filename was
different.  To help the user know where they are digging into
when they click on that link we now show the original file in
the tooltip, but to save space we do so only if the original
file is not the same as the file we are currently viewing.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Combine blame groups only if commit and filename match

Consecutive chunks of a file could come from the same commit, but
have different original file names.  Previously we would have put
them into a single group, but then the hyperlink would jump to only
one of the files, and the other would not be accessible.  Now we can
get to the other file too.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow digging through history in blame viewer

gitweb has long had a feature where the user can click on any
commit the blame display and go visit that commit's information
page.  From the user could go get the blame display for the file
they are tracking, and try to digg through the history of any
part of the code they are interested in seeing.

We now offer somewhat similiar functionality in git-gui.  The 4
digit commit abreviation in the first column of our blame view is
now offered as a hyperlink if the commit isn't the one we are now
viewing the blame output for (as there is no point in linking back
to yourself).  Clicking on that link will stop the current blame
engine (if still running), push the new target commit onto the
history stack, and restart the blame viewer at that commit, using
the "original file name" as supplied by git-blame for that chunk
of the output.

Users can navigate back to a version they had been viewing before
by way of a back button, which offers the prior commits in a popup
menu displayed right below the back button.  I'm always showing the
menu here as the cost of switching between views is very high; you
don't want to jump to a commit you are not interested in looking at
again.

During switches we throw away all data except the cached commit data,
as that is relatively small compared to most source files and their
annotation marks.  Unfortunately throwing this per-file data away in
Tcl seems to take some time; I probably should move the line indexed
arrays to proper lists and use [lindex] rather than the array lookup
(usually lists are faster).

We now start the git-blame process using "nice", so that its priority
will drop hopefully below our own.  If I don't do this the blame engine
gets a lot of CPU under Windows 2000 and the git-gui user interface is
almost non-responsive, even though Tcl is just sitting there waiting
for events.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display a progress bar during blame annotation gathering

Computing the blame records for a large file with a long project
history can take git a while to run; traditionally we have shown
a little meter in the status area of our blame viewer that lets
the user know how many lines have been finished, and how far we
are through the process.

Usually such progress indicators are drawn with a little progress
bar in the window, where the bar shows how much has been completed
and hides itself when the process is complete.  I'm using a very
simple hack to do that: draw a canvas with a filled rectangle.

Of course the time remaining has absolutely no relationship to the
progress meter.  It could take very little time for git-blame to get
the first 90% of the file, and then it could take many times that to
get the remaining 10%.  So the progress meter doesn't really have any
sort of assurances that it relates to the true progress of the work.
But in practice on some ugly history it does seem to hold a reasonable
indicator to the completion status.  Besides, its amusing to watch and
that keeps the user from realizing git is being somewhat slow.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Allow the user to control the blame/commit split point

At one point I tried to present the blame viewer to an audience of
people on a 640 by 480 pixel LCD projector.  This did not work at
all as the top area (the file data) was taking up all of the screen
realestate and the split point was not adjustable by the user.  In
general locking the user into a specific ratio of display is just
not user friendly.

So we now place a split pane control into the middle of our blame
window, so the user can adjust it to their current needs.  If the
window increases (or decreases) in height we assign the difference
to the file data area, as that is generally the area of the window
that users are trying to see more of when they grow the window.

Unfortunately there appears to be a bug in the "pack" layout manager
in Tcl/Tk 8.4.1.  The status bar and the lower commit pane was being
squashed if the window decreased in height.  I think the pack manager
was just not decreasing the size of the panedwindow slave properly if
the main window shrank.  Switching to the "grid" layout manager fixes
the problem, but is slightly uglier setup code.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Show author initials in blame groups

Frequently when I'm looking at blocks of code in the blame
viewer I want to know who is the culprit, or who I should
be praising for a job well done.  The tooltips nicely show
this if I mouse over a block, but it doesn't work to get
this detail at a glance.

Since we don't use the leftmost commit column for anything
after the first line within a commit group I'm now tossing
the author's initials into that field, right justified.  It
is quite clearly not a SHA-1 number as we always show the
SHA-1 in lowercase, while we explicitly select only the
uppercase characters from an author's name field, and only
those that are following whitespace.

I'm using initials here over anything else as they are quite
commonly unique within small development teams.  The leading
part of the email address field was out for some of the teams
I work with, as there the email addresses are all of the form
"Givenname.Surname@initech.com".  That will never fit into the
4 characters available.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Space the commit group continuation out in blame view

The | in the continued lines of the same commit group as not
easily seen on the left edge; putting a single space in front
of the pipe makes it slightly more visually appealing to me as
I can follow the line down through the group to the next commit
marker.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Cleanup minor style nit

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Remove unnecessary reshow of blamed commit

Because we no longer redraw colors every time we select a particular
commit there is no need to redraw the screen after we get a new commit
in from blame --incremental.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Highlight the blame commit header from everything else

The selected commit's blame header is now drawn in green, using
the same background color that is shown in the main file content
viewer.  The result is a much better looking commit pane, as we
use bold for header "keys" and proportional width fonts for the
stuff that doesn't need to be fixed width to maintain its formatting.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Display tooltips in blame viewer

When the mouse is over a particular line and we have blame data
for that line, but its not the active commit, we should show the
user information about that commit like who the author was and
what the subject (first line) was.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Use arror cursor in blame viewer file data

Since we don't allow the user to select text from the file
viewer right now I'm disabling the normal text cursor and
putting in a plain arror instead.  This way users don't
think they can select and copy text, because they can't.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Simplify consecutive lines that come from the same commit

If two consecutive lines in the final file came from the same commit
then we store a "|" in the first column rather than the commit id,
for the second and subsequent lines in that block.  This cleans up
the interface so runs associated with the same commit can be more
easily seen visually.

We also now use the abbreviation "work" for the uncommitted stuff in
your working directory, rather than "0000".  This looks nicer to the
eyes and explains pretty quickly what is going on.

There was also a minor bug in the commit abbreviation column for the
last line of the file.  This is now also fixed.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Improve the coloring in blame viewer

The git-gui blame viewer has always been ugly as s**t.  Linus Torvalds
suggested the coloring scheme I'm using here, which is two different
shades of grey for the background colors, and black text on a pale green
background for the currently selected/focused commit.

The difference is a massive improvement.  The interface no longer will
cause seizures in people who are prone to that sort of thing.  It no
longer uses a very offensive hot pink.  The green being current actually
makes sense.  And not having the background of the other non-current
lines change when you change the current commit is really a big deal.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Remove empty blank line at end of blame

The blame viewer has this silly blank line at the bottom of it;
we really don't want to see it displayed as we will never get
any blame data for that line (it doesn't exist in the source).

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>