tokkee.org

reduce git-pack-objects memory usage a little more

The delta depth doesn't have to be stored in the global object array
structure since it is only used during the deltification pass.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add documentation for --window-memory, pack.windowMemory

Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add --window-memory option to git-repack

Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add pack-objects window memory usage limit

This adds an option (--window-memory=N) and configuration variable
(pack.windowMemory = N) to limit the memory size of the pack-objects
delta search window.  This works by removing the oldest unpacked objects
whenever the total size goes above the limit.  It will always leave
at least one object, though, so as not to completely eliminate the
possibility of computing deltas.

This is an extra limit on top of the normal window size (--window=N);
the window will not dynamically grow above the fixed number of entries
specified to fill the memory limit.

With this, repacking a repository with a mix of large and small objects
is possible even with a very large window.

Cleaner and correct circular buffer handling courtesy of Nicolas Pitre.

Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add functions for parsing integers with size suffixes

Split out the nnn{k,m,g} parsing code from git_config_int into
git_parse_long, so command-line parameters can enjoy the same
functionality.  Also add get_parse_ulong for unsigned values.

Make git_config_int use git_parse_long, and add get_config_ulong
as well.

Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Support fetching the memory usage of a delta index

Delta indices, at least on 64-bit platforms, tend to be larger than
the actual uncompressed data.  As such, keeping track of this storage
is important if you want to successfully limit the memory size of your
pack window.

Squirrel away the total allocation size inside the delta_index struct,
and add an accessor "sizeof_delta_index" to access it.

Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Don't try to delta if target is much smaller than source

Add a new try_delta heuristic.  Don't bother trying to make a delta if
the target object size is much smaller (currently 1/32) than the source,
as it's very likely not going to get a match.  Even if it does, you will
have to read at least 32x the size of the new file to reassemble it,
which isn't such a good deal.  This leads to a considerable performance
improvement when deltifying a mix of small and large files with a very
large window, because you don't have to wait for the large files to
percolate out of the window before things start going fast again.

Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Correct shebang line for contrib/stats/packinfo.pl

"/bin/perl"?  What was I thinking?

Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

script to display a distribution of longest common hash prefixes

This script was originally posted on the git mailing list by
Randal L. Schwartz <merlyn@stonehenge.com>.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

apply delta depth bias to already deltified objects

We already apply a bias on the initial delta attempt with max_size being
a function of the base object depth.  This has the effect of favoring
shallower deltas even if deeper deltas could be smaller, and therefore
creating a wider delta tree (see commits 4e8da195 and c3b06a69).

This principle should also be applied to all delta attempts for the same
object and not only the first attempt.  With this the criteria for the
best delta is not only its size but also its depth, so that a shallower
delta might be selected even if it is larger than a deeper one.  Even if
some deltas get larger, they allow for wider delta trees making the
depth limit less quickly reached and therefore better deltas can be
subsequently found, keeping the resulting pack size even smaller.
Runtime access to the pack should also benefit from shallower deltas.

Testing on different repositories showed slighter faster repacks,
smaller resulting packs, and a much nicer curve for delta depth
distribution with no more peak at the maximum depth level.
Improvements are even more significant with smaller depth limits.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update list of older git docs

Merge commit 'git-gui/master'

* commit 'git-gui/master': (36 commits)
  git-gui: Change prior tree SHA-1 verification to use git_read
  git-gui: Include a space in Cygwin shortcut command lines
  git-gui: Use sh.exe in Cygwin shortcuts
  git-gui: Paper bag fix for Cygwin shortcut creation
  git-gui: Improve the Windows and Mac OS X shortcut creators
  git-gui: Teach console widget to use git_read
  git-gui: Perform our own magic shbang detection on Windows
  git-gui: Treat `git version` as `git --version`
  git-gui: Assume unfound commands are known by git wrapper
  git-gui: Correct gitk installation location
  git-gui: Always use absolute path to all git executables
  git-gui: Show a progress meter for checking out files
  git-gui: Change the main window progress bar to use status_bar
  git-gui: Extract blame viewer status bar into mega-widget
  git-gui: Allow double-click in checkout dialog to start checkout
  git-gui: Default selection to first matching ref
  git-gui: Unabbreviate commit SHA-1s prior to display
  git-gui: Refactor branch switch to support detached head
  git-gui: Refactor our ui_status_value update technique
  git-gui: Better handling of detached HEAD
  ...

Merge branch 'maint'

* maint:
  GIT 1.5.2.4
  Teach read-tree 2-way merge to ignore intermediate symlinks
  git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}
  git-gui: Don't linewrap within console windows
  git-gui: Correct ls-tree buffering problem in browser
  git-gui: Skip nicknames when selecting author initials
  git-gui: Ensure windows shortcuts always have .bat extension
  git-gui: Include a Push action on the left toolbar
  git-gui: Bind M1-P to push action
  git-gui: Don't bind F5/M1-R in all windows
  git-gui: Unlock the index when cancelling merge dialog
  git-gui: properly popup error if gitk should be started but is not installed

GIT 1.5.2.4

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

Teach read-tree 2-way merge to ignore intermediate symlinks

Earlier in 16a4c61, we taught "read-tree -m -u" not to be
confused when switching from a branch that has a path frotz/filfre
to another branch that has a symlink frotz that points at xyzzy/
directory.  The fix was incomplete in that it was still confused
when coming back (i.e. switching from a branch with frotz -> xyzzy/
to another branch with frotz/filfre).

This fix is rather expensive in that for a path that is created
we would need to see if any of the leading component of that
path exists as a symbolic link in the filesystem (in which case,
we know that path itself does not exist, and the fact we already
decided to check it out tells us that in the index we already
know that symbolic link is going away as there is no D/F
conflict).

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

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

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}
  git-gui: Don't linewrap within console windows
  git-gui: Correct ls-tree buffering problem in browser
  git-gui: Skip nicknames when selecting author initials
  git-gui: Ensure windows shortcuts always have .bat extension
  git-gui: Include a Push action on the left toolbar
  git-gui: Bind M1-P to push action
  git-gui: Don't bind F5/M1-R in all windows
  git-gui: Unlock the index when cancelling merge dialog
  git-gui: properly popup error if gitk should be started but is not installed

git-gui: Change prior tree SHA-1 verification to use git_read

This cat-file was done on maint, where we did not have git_read
available to us.  But here on master we do, so we should make
use of it.

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

Merge branch 'maint'

* maint:
  git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}

git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}

From Johannes Sixt <J.Sixt@eudaptics.com>:
> It seems that MSYS's wish does some quoting for Bourne shells,
> in particular, escape the first '{' of the "^{tree}" suffix, but
> then it uses cmd.exe to run "git rev-parse". However, cmd.exe does
> not remove the backslash, so that the resulting rev expression
> ends up in git's guts as unrecognizable garbage: rev-parse fails,
> and git-gui hickups in a way that it must be restarted.

Johannes originally submitted a patch to this section of commit.tcl
to use `git rev-parse $PARENT:`, but not all versions of Git will
accept that format.  So I'm just taking the really simple approach
here of scanning the first line of the commit to grab its tree.
About the same cost, but works everywhere.

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

Re-code builtin-branch.c in UTF-8

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

Function stripspace now gets a buffer instead file descriptors.

An implementation easier to call from builtins. It is designed
to be used from the upcoming builtin-tag.c and builtin-commit.c,
because both need to remove unwanted spaces from messages.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Pack information tool

This tool will print vaguely pretty information about a pack.  It
expects the output of "git-verify-pack -v" as input on stdin.

$ git-verify-pack -v | packinfo.pl

See the documentation in the script (contrib/stats/packinfo.pl)
for more information.

Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch --track: code cleanup and saner handling of local branches

This patch cleans up some complicated code, and replaces it with a
cleaner version, using code from remote.[ch], which got extended a
little in the process.  This also enables us to fix two cases:

The earlier "fix" to setup tracking only when the original ref started
with "refs/remotes" is wrong.  You are absolutely allowed to use a
separate layout for your tracking branches.  The correct fix, of course,
is to set up tracking information only when there is a matching
remote.<nick>.fetch line containing a colon.

Another corner case was not handled properly.  If two remotes write to
the original ref, just warn the user and do not set up tracking.

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

Add for_each_remote() function, and extend remote_find_tracking()

The function for_each_remote() does exactly what the name
suggests.

The function remote_find_tracking() was extended to be able to
search remote refs for a given local ref.  The caller sets
either src or dst (but not both) in the refspec parameter, and
remote_find_tracking() will fill in the other and return 0.

Both changes are required for the next step: simplification of
git-branch's --track functionality.

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

t7004: Add tests for the git tag -n option.

These tests check the syntax for the git tag -n option
and its output when one, none or many lines of the
message are requested.

Also this commit adds a missing && in the test
that checks the sorted output of git tag -l.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0030: Add tests with consecutive text lines and others with spaces added.

Previous tests only had paragraphs of one line. This commit adds some
tests to check when many consecutive text lines are given.

Also, it adds tests for checking that many lines between paragraphs are
correctly reduced to one when there are tabs and spaces in those lines.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0030: Remove repeated instructions and add missing &&

Moved some tests to another test_expect_success block.

Many tests now reuse the same "expect" file. Also replacing
many printf "" >expect with one >expect instruction.

Added missing && which concatenated tests in some
test_expect_success blocks.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix --cherry-pick with given paths

If you say --cherry-pick, you do not want to see patches which are
in the upstream.  If you specify paths with that, what you usually
expect is that only those parts of the patches are looked at which
actually touch the given paths.

With this patch, that expectation is met.

Noticed by Sam Vilain.

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

Fix core.sharedRepository = 2

For compatibility reasons, "git init --shared=all" does not write
"all" into the config, but a number.  In the shared setup, you
really have to support even older clients on the _same_ repository.

But git_config_perm() did not pick up on it.

Also, "git update-server-info" failed to pick up on the shared
permissions.

This patch fixes both issues, and adds a test to prove it.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: martin f krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: configurable width for the projects list Description column

This allows gitweb users to set $projects_list_description_width
in their gitweb.conf to determine how many characters of a project
description are displayed before being truncated with an ellipsis.

Signed-off-by: Michael Hendricks <michael@ndrix.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'bd/delta'

* bd/delta:
  pack-objects: Prefer shallower deltas if the size is equal

Some cosmetic changes to remote library

Functions for managing ref lists were named based on their use in
match_refs (for push). For fetch, they will be used for other purposes, so
rename them as a separate patch to make the future code readable.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add allocation and freeing functions for struct refs

Instead of open-coding allocation wherever it happens, have a function.
Also, add a function to free a list of refs, which we currently never
actually do.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: rebuild git.o on version change, clean up git$X flags

Commit 334d28ae factored out git.o as an intermediate stage between
git.c and git$X.  However:

- It left some no-longer-relevant flags in the rule for git$X.

- It failed to replace git$X with git.o in the list of files that
  record GIT_VERSION.  This broke incorporation of a changed
  GIT_VERSION into git$X because, when GIT_VERSION changes, git.o isn't
  remade and git$X is relinked from the git.o that still contains the
  old GIT_VERSION.

This patch removes the irrelevant flags and fixes incorporation of a
changed GIT_VERSION into git$X.

Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rerere: record resolution even if file is not in merge base

Two-file merges were rare enough that they were dropped outside of the
radar.  This fix is a trivial change to builtin-rerere.c::find_conflict().
It is still sane to insist that we do not do rerere for symlinks, and
require to have stages #2 and #3, but we can drop the requirement to have
stage #1. rerere does not use information from there anyway.

This fix is from Junio, together with two tests to verify that it works
as expected.

Acked-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Support wholesale directory renames in fast-import

Some source material (e.g. Subversion dump files) perform directory
renames without telling us exactly which files in that subdirectory
were moved.  This makes it hard for a frontend to convert such data
formats to a fast-import stream, as all the frontend has on hand
is "Rename a/ to b/" with no details about what files are in a/,
unless the frontend also kept track of all files.

The new 'R' subcommand within a commit allows the frontend to
rename either a file or an entire subdirectory, without needing to
know the object's SHA-1 or the specific files contained within it.
The rename is performed as efficiently as possible internally,
making it cheaper than a 'D'/'M' pair for a file rename.

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

Merge branch 'maint'

* maint:
  Clarify documentation of fast-import's D subcommand

Clarify documentation of fast-import's D subcommand

The 'D' subcommand within a commit can also delete a directory
recursively.  This wasn't clear in the prior version of the
documentation, leading to a question on the mailing list.

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

git-gui: Include a space in Cygwin shortcut command lines

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

git-gui: Use sh.exe in Cygwin shortcuts

Because we are trying to execute /bin/sh we know it must be a real
Windows executable and thus ends with the standard .exe suffix.

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

git-gui: Paper bag fix for Cygwin shortcut creation

We cannot execute the git directory, it is not a valid Tcl command
name.  Instead we just want to pass it as an argument to our sq
proc.

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

Merge branch 'maint'

* maint:
  git-gui: Don't linewrap within console windows
  git-gui: Correct ls-tree buffering problem in browser

git-gui: Don't linewrap within console windows

If we get more than 80 characters of text in a single line odds
are it is output from git-fetch or git-push and its showing a
lot of detail off to the right edge that is not so important to
the average user.  We still want to make sure we show everything
we need, but we can get away with that information being off to
the side with a horizontal scrollbar.

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

git-gui: Correct ls-tree buffering problem in browser

Our file browser was showing bad output as it did not properly buffer
a partial record when read from `ls-tree -z`.  This did not show up on
my Mac OS X system as most trees are small, the pipe buffers generally
big and `ls-tree -z` was generally fast enough that all data was ready
before Tcl started to read.  However on my Cygwin system one of my
production repositories had a large enough tree and packfile that it
took a couple of pipe buffers for `ls-tree -z` to complete its dump.

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

git-gui: Improve the Windows and Mac OS X shortcut creators

We now embed any GIT_* and SSH_* environment variables as well as
the path to the git wrapper executable into the Mac OS X .app file.
This should allow us to restore the environment properly when
we restart.

We also try to use proper Bourne shell single quoting when we can,
as this avoids any sort of problems that might occur due to a path
containing shell metacharacters.

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

git-gui: Teach console widget to use git_read

Now that we are pretty strict about setting up own absolute paths to
any git helper (saving a marginal runtime cost to resolve the tool)
we can do the same in our console widget by making sure all console
execs go through git_read if they are a git subcommand, and if not
make sure they at least try to use the Tcl 2>@1 IO redirection if
possible, as it should be faster than |& cat.

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

pack-objects: Prefer shallower deltas if the size is equal

Change "try_delta" so that if it finds a delta that has the same size
but shallower depth than the existing delta, it will prefer the
shallower one.  This makes certain delta trees vastly less deep.

Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: Perform our own magic shbang detection on Windows

If we cannot locate a .exe for a git tool that we want to run than
it may just be a Bourne shell script as these are popular in Git.
In such a case the first line of the file will say "#!/bin/sh" so
a UNIX kernel knows what program to start to parse and run that.
But Windows doesn't support shbang lines, and neither does the Tcl
that comes with Cygwin.

We can pass control off to the git wrapper as that is a real Cygwin
program and can therefore start the Bourne shell script, but that is
at least two fork+exec calls to get the program running.  One to do
the fork+exec of the git wrapper and another to start the Bourne shell
script.  If the program is run multiple times it is rather expensive
as the magic shbang detection won't be cached across executions.

On MinGW/MSYS we don't have the luxury of such magic detection.  The
MSYS team has taught some of this magic to the git wrapper, but again
its slower than it needs to be as the git wrapper must still go and
run the Bourne shell after it is called.

We now attempt to guess the shbang line on Windows by reading the
first line of the file and building our own command line path from
it.  Currently we support Bourne shell (sh), Perl and Python.  That
is the entire set of shbang lines that appear in git.git today.

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

git-gui: Treat `git version` as `git --version`

We know that the version subcommand of git is special.  It does not
currently have an executable link installed into $gitexecdir and we
therefore would never match it with one of our file exists tests.
So we forward any invocations to it directly to the git wrapper, as
it is a builtin within that executable.

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

Revert 88494423 (removal of duplicate parents in the output codepath)

Now this is not needed, as we rewrite the parent list in the commit
object itself.

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

revision.c: remove duplicated parents after history simplification

When we simplify history due to path limits, the parents list
for a rewritten commit can end up having duplicates.  Instead of
filtering them out in the output codepath like earlier commit
88494423 did, remove them much earlier, when the parent
information actually gets rewritten.

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

git-gui: Assume unfound commands are known by git wrapper

If we cannot locate a command in $gitexecdir on our own then it may
just be because we are supposed to run it by `git $name` rather than
by `git-$name`.  Many commands are now builtins, more are likely to
go in that direction, and we may see the hardlinks in $gitexecdir go
away in future versions of git.

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

git-gui: Correct gitk installation location

The master Makefile in git.git installs gitk into bindir, not
gitexecdir, which means gitk is located as a sibling of the git
wrapper and not as though it were a git helper tool.

We can also avoid some Tcl concat operations by letting eval do
all of the heavy lifting; we have two proper Tcl lists ($cmd and
$revs) that we are joining together and $revs is currently never
an empty list.

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

git-gui: Always use absolute path to all git executables

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>

git-gui: Show a progress meter for checking out files

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>

git-gui: Change the main window progress bar to use status_bar

Now that we have a fancy status bar mega-widget we can reuse that
within our main window.  This opens the door for implementating
future improvements like a progress bar.

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

git-gui: Extract blame viewer status bar into mega-widget

Our blame viewer has had a very fancy progress bar at the bottom of
the window that shows the current status of the blame engine, which
includes the number of lines completed as both a text and a graphical
meter.  I want to reuse this meter system in other places, such as
during a branch switch where read-tree -v can give us a progress
meter for any long-running operation.

This change extracts the code and refactors it as a widget that we
can take advantage of in locations other than in the blame viewer.

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

git-gui: Allow double-click in checkout dialog to start checkout

If the user double clicks a branch in the checkout dialog then they
probably want to start the checkout process on that branch.  I found
myself doing this without realizing it, and of course it did nothing
as there was no action bound to the listbox's Double-Button-1 event
handler.  Since I did it without thinking, others will probably also
try, and expect the same behavior.

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

git-gui: Default selection to first matching ref

If we have specifications listed in our revision picker mega-widget
then we should default the selection within that widget to the first
ref available.  This way the user does not need to use the spacebar
to activate the selection of a ref within the box; instead they can
navigate up/down with the arrow keys and be done with it.

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

git-gui: Unabbreviate commit SHA-1s prior to display

If the end-user feeds us an abbreviated SHA-1 on the command line for
`git gui browser` or `git gui blame` we now unabbreviate the value
through `git rev-parse` so that the title section of the blame or
browser window shows the user the complete SHA-1 as Git determined
it to be.

If the abbreviated value was ambiguous we now complain with the
standard error message(s) as reported by git-rev-parse --verify,
so that the user can understand what might be wrong and correct
their command line.

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

git-gui: Refactor branch switch to support detached head

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>

Document custom hunk header selection

Since the external interface seems to have stabilized for this
new feature, let's document it properly.

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

Merge branch 'maint'

* maint:
  user-manual: fix directory name in git-archive example
  user-manual: more explanation of push and pull usage
  tutorial: Fix typo
  user-manual: grammar and style fixes

rebase -i: put a nice warning into the todo list

It seems that not everybody expects a difference between keeping a "pick"
line, and deleting it.  So be a bit more explicit about that, with all
capitals to get the attention.

Noticed by vmiklos on IRC.

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

rebase -i: remember the settings of -v, -s and -p when interrupted

After interruption, be that an edit, or a conflicting commit, reset
the variables VERBOSE, STRATEGY and PRESERVE_MERGES, so that the
user does not have to respecify them with "rebase --continue".

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

rebase -i: actually show the diffstat when being verbose

The "while" loop in the function do_rest is not supposed to ever be
exited.  Instead, the function do_one checks if there is nothing left,
and cleans up and exits if that is the case.  So the diffstat code
belongs there.

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

rebase -i: handle --continue more like non-interactive rebase

Non-interactive rebase requires the working tree to be clean, but
applies what is in the index without requiring the user to do it
herself.  Imitate that, but (since we are interactive, after all)
fire up an editor with the commit message.

It also fixes a subtle bug: a forgotten "continue" was removed, which
led to an infinite loop when continuing without remaining patches.

Both issues noticed by Frank Lichtenheld.

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

t7004: Skip tests for signed tags in an old version of gpg.

As said here: http://www.gnupg.org/documentation/faqs.html#q6.19
the gpg version 1.0.6 didn't parse trust packets correctly, so for
that version, creation of signed tags using the generated key fails.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Acked-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix merge-one-file for our-side-added/our-side-removed cases

When commit ed93b449 changed the script so that it does not
touch untracked working tree file, we forgot that we still
needed to resolve the index entry (otherwise they are left
unmerged).

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

git-commit: don't add multiple Signed-off-by: from the same identity

If requested to signoff a commit, don't add another Signed-off-by: line
to the commit message if the exact same line is already there.

This was noticed and requested by Josh Triplett through
 http://bugs.debian.org/430851

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

branch.autosetupmerge: allow boolean values, or "all"

Junio noticed that switching on autosetupmerge unilaterally started
cluttering the config for local branches.  That is not the original
intention of branch.autosetupmerge, which was meant purely for
convenience when branching off of remote branches, but that semantics
got lost somewhere.

If you still want that "new" behavior, you can switch
branch.autosetupmerge to the value "all".  Otherwise, it is interpreted
as a boolean, which triggers setting up defaults _only_ when branching
off of a remote branch, i.e. the originally intended behavior.

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

git-stash: try reusing cached stat info as much as possible

Earlier when we read a tree into a temporary index, we read it
from scratch.  Start from the current index and use read-tree -m
to preserve cached stat information as much as possible, in
order to speed up "git add -u".  This makes "git stash" usable
in a source tree of nontrivial size.

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

git-gui: Refactor our ui_status_value update technique

I'm really starting to dislike global variables.  The ui_status_value
global varible is just one of those that seems to appear in a lot of
code and in many cases we didn't even declare it "global" within the
proc that updates it so we haven't always been getting all of the
updates we expected to see.

This change introduces two new global procs:

  ui_status $msg;   # Sets the status bar to show $msg.
  ui_ready;         # Changes the status bar to show "Ready."

The second (special) form is used because we often update the area
with this message once we are done processing a block of work and
want the user to know we have completed it.

I'm not fixing the cases that appear in lib/branch.tcl right now
as I'm actually in the middle of a huge refactoring of that code
to support making a detached HEAD checkout.

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

git-gui: Better handling of detached HEAD

If the current branch is not a symbolic-ref that points to a
name in the refs/heads/ namespace we now just assume that the
head is a detached head.  In this case we return the special
branch name of HEAD rather than empty string, as HEAD is a
valid revision specification and the empty string is not.

I have also slightly improved the current-branch function by
using string functions to parse the symbolic-ref data.  This
should be slightly faster than using a regsub.  I think the
code is clearer too.

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

git-gui: Automatically refresh tracking branches when needed

If the user is creating a new local branch and has selected to use
a tracking branch as the starting revision they probably want to
make sure they are using the absolute latest version available of
that branch.

We now offer a checkbox "Fetch Tracking Branch" (on by default)
that instructs git-gui to run git-fetch on just that one branch
before resolving the branch name into a commit SHA-1 and making
(or updating) the local branch.

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

git-gui: Option to default new branches to match tracking branches

In some workflows users will want to almost always just create a new
local branch that matches a remote branch.  In this type of workflow
it is handy to have the new branch dialog default to "Match Tracking
Branch" and "Starting Revision"-Tracking Branch", with the focus in
the branch filter field.  This can save users working on this type
of workflow at least two mouse clicks every time they create a new
local branch or switch to one with a fast-forward.

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

git-gui: Sort tags descending by tagger date

When trying to create a branch from a tag most people are looking
for a recent tag, not one that is ancient history.  Rather than
sorting tags by their string we now sort them by taggerdate, as
this places the recent tags at the top of the list and the very
old ones at the end.  Tag date works nicely as an approximation
of the actual history order of commits.

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

git-gui: Enhance choose_rev to handle hundreds of branches

One of my production repositories has hundreds of remote tracking
branches.  Trying to navigate these through a popup menu is just
not possible.  The list is far larger than the screen and it does
not scroll fast enough to efficiently select a branch name when
trying to create a branch or delete a branch.

This is major rewrite of the revision chooser mega-widget.  We
now use a single listbox for all three major types of named refs
(heads, tracking branches, tags) and a radio button group to pick
which of those namespaces should be shown in the listbox.  A filter
field is shown to the right allowing the end-user to key in a glob
specification to filter the list they are viewing.  The filter is
always taken as substring, so we assume * both starts and ends the
pattern the user wanted but otherwise treat it as a glob pattern.

This new picker works out really nicely.  What used to take me at
least a minute to find and select a branch now takes mere seconds.

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

git-gui: Fast-forward existing branch in branch create dialog

If the user elects to create a local branch that has the same name
as an existing branch and we can fast-forward the local branch to
the selected revision we might as well do the fast-forward for the
user, rather than making them first switch to the branch then merge
the selected revision into it.  After all, its really just a fast
forward.  No history is lost.  The resulting branch checkout may
also be faster if the branch we are switching from is closer to
the new revision.

Likewise we also now allow the user to reset the local branch if
it already exists but would not fast-forward.  However before we
do the actual reset we tell the user what commits they are going to
lose by showing the oneline subject and abbreviated sha1, and we also
let them inspect the range of commits in gitk.

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

git-gui: Allow users to match remote branch names locally

Some workflows have users create a local branch that matches a remote
branch they have fetched from another repository.  If the user wants
to push their changes back to that remote repository then they probably
want to use the same branch name locally so that git-gui's push dialog
can setup the push refspec automatically.

To prevent typos with the local branch name we now offer an option to
use the remote tracking branch name as the new local branch name.

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

git-gui: Maintain remote and source ref for tracking branches

In the next change I want to let the user create their local branch
name to match the remote branch name, so that the existing push
dialog can push the branch back up to the remote repository without
needing to do any sort of remapping.  To do that we need to know
exactly what branch name the remote system is using.

So all_tracking_branches returns a list of specifications, where
each specification is itself a list of:

  - local ref name (destination we fetch into)
  - remote name (repository we fetch from)
  - remote ref name (source ref we fetch from)

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

git-gui: Optimize for newstyle refs/remotes layout

Most people using Git 1.5.x and later are using the newer style
of remotes layout where all of their tracking branches are in
refs/remotes and refs/heads contains only the user's own local
branches.

In such a situation we can avoid calling is_tracking_branch
for each head we are considering because we know that all of
the heads must be local branches if no fetch option or Pull:
line maps a branch into that namespace.

If however any remote maps a remote branch into a local
tracking branch that resides in refs/heads we do exactly
what we did before, which requires scanning through all
fetch lines in case any patterns are matched.

I also switched some regexp/regsub calls to string match
as this can be a faster operation for prefix matching.

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

git-gui: Refactor the delete branch dialog to use class system

A simple refactoring of the delete branch dialog to allow use of
the class construct to better organize the code and to reuse the
revision selection code of our new choose_rev mega-widget.

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

git-gui: Abstract the revision picker into a mega widget

This rather large change pulls the "Starting Revision" part of the
new branch dialog into a mega widget that we can use anytime we
need to select a commit SHA-1.  To make use of the mega widget I
have also refactored the branch dialog to use the class system,
much like the delete remote branch dialog already does.

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

git-gui: Teach class system to support [$this cmd] syntax

Its handy to be able to ask an object to do something for you by
handing it a subcommand.  For example if we want to get the value
of an object's private field the object could expose a method that
would return that value.  Application level code can then invoke
"$inst get" to perform the method call.

Tk uses this pattern for all of its widgets, so we'd certainly
like to use it for our own mega-widgets that we might develop.
Up until now we haven't needed such functionality, but I'm working
on a new revision picker mega-widget that would benefit from it.

To make this work we have to change the definition of $this to
actually be a procedure within the namespace.  By making $this a
procedure any caller that has $this can call subcommands by passing
them as the first argument to $this.  That subcommand then needs
to call the proper subroutine.

Placing the dispatch procedure into the object's variable namespace
ensures that it will always be deleted when the object is deleted.

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

Merge branch 'maint'

* maint:
  git-gui: Skip nicknames when selecting author initials

git-gui: Skip nicknames when selecting author initials

Our blame viewer only grabbed the first initial of the git.git
author string "Simon 'corecode' Schubert".  Here the problem was we
looked at Simon, pulled the S into the author initials, then saw
the single quote as the start of the next name and did not like
this character as it was not an uppercase letter.

We now skip over single quoted nicknames placed within the author
name field and grab the initials following it.  So the above name
will get the initials SS, rather than just S.

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

git-gui: use "blame -w -C -C" for "where did it come from, originally?"

The blame window shows "who wrote the piece originally" and "who
moved it there" in two columns.  In order to identify the former
more correctly, it helps to use the new -w option.

[sp: Minor change to only enable -w if underlying git >= 1.5.3]

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: New Git version check support routine

Some newer features of git-gui want to rely on features that are
new to Git 1.5.3.  Since they were added as part of the 1.5.3
development series we cannot use those features with versions of
Git that are older than 1.5.3, such as from the stable 1.5.2 series.

We introduce [git-version >= 1.5.3] to allow the caller to get a
response of 0 if the current version of git is < 1.5.3 and 1 if
the current version of git is >= 1.5.3.  This makes it easy to
setup conditional code based upon the version of Git available to
us at runtime.

Instead of parsing the version text by hand we now use the Tcl
[package vcompare] subcommand to compare the two version strings.
This works nicely, as Tcl as already done all of the hard work
of doing version comparsions.  But we do have to remove the Git
specific components such as the Git commit SHA-1, commit count and
release candidate suffix (rc) as we want only the final release
version number.

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

user-manual: fix directory name in git-archive example

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

user-manual: more explanation of push and pull usage

Recently a user on the mailing list complained that they'd read the
manual but couldn't figure out how to keep a couple private repositories
in sync.  They'd tried using push, and were surprised by the effect.

Add a little text in an attempt to make it clear that:
- Pushing to a branch that is checked out will have odd results.
- It's OK to synchronize just using pull if that's simpler.

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

tutorial: Fix typo

"You" should be "Alice" here.

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

user-manual: grammar and style fixes

 - "method of" is vulgar, "method for" is nicer
 - "recovery" becomes "recovering" from Steve Hoelzer's original version
   of this patch
 - "if you want" is nicer as "if you wish"
 - "you may" should be "you can"; "you may" is "you have permission to"
   rather than "you can"'s "it is possible to"

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

git-gui: Honor rerere.enabled configuration option

Recently in git.git change b4372ef136 Johannes Schindelin taught
git-commit.sh to invoke (or skip) calling git-rerere based upon
the rerere.enabled configuration setting:

  So, check the config variable "rerere.enabled". If it is set
  to "false" explicitely, do not activate rerere, even if
  .git/rr-cache exists. This should help when you want to disable
  rerere temporarily.

  If "rerere.enabled" is not set at all, fall back to detection
  of the directory .git/rr-cache.

We now do the same logic in git-gui's own commit implementation.

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

diff.c: make built-in hunk header pattern a separate table

This would hopefully make it easier to maintain.  Initially we
would have "java" and "tex" defined, as they are the only ones
we already have.

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

gitweb: make "No commits" in project list gray, not bold green

A missing return statement in git_get_last_activity made gitweb think
a project with no commits was in age class "age0", so the "No commits"
appeared in bold green, which was ridiculous.  I added the return so
those projects get "noage" and added a block to gitweb.css to format
the "No commits" text gray.

Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: make search form generate pathinfo-style URLs

The search form generated traditional-style URLs with a "p=" parameter
even when the pathinfo feature was on.  This patch makes it generate
pathinfo-style URLs when appropriate.

Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: prefer git_get_project_owner() over get_file_owner()

This way if $projects_list exists, it'll be used, otherwise get_file_owner()
will be used as before.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Acked-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: make repeated calls to git_get_project_owner() bearable

If repeated calls to git_get_project_owner() are made, we would have read the
same file over and over again.

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

Merge branch 'js/stash'

* js/stash:
  Teach git-stash to "apply --index"