tokkee.org

diffcore_count_changes: pass diffcore_filespec

We may want to use richer information on the data we are dealing
with in this function, so instead of passing a buffer address
and length, just pass the diffcore_filespec structure.  Existing
callers always call this function with parameters taken from a
filespec anyway, so there is no functionality changes.

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

Don't fflush(stdout) when it's not helpful

This patch arose from a discussion started by Jim Meyering's patch
whose intention was to provide better diagnostics for failed writes.
Linus proposed a better way to do things, which also had the added
benefit that adding a fflush() to git-log-* operations and incremental
git-blame operations could improve interactive respose time feel, at
the cost of making things a bit slower when we aren't piping the
output to a downstream program.

This patch skips the fflush() calls when stdout is a regular file, or
if the environment variable GIT_FLUSH is set to "0".  This latter can
speed up a command such as:

GIT_FLUSH=0 strace -c -f -e write time git-rev-list HEAD | wc -l

a tiny amount.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'cr/tag'

* cr/tag:
  Add test-script for git-tag
  Add test script for git-stripspace.
  Fix git-stripspace to process correctly long lines and spaces.

git: Try a bit harder not to lose errno in stdio

This switches the checks around upon the exit codepath of the
git wrapper, so that we may recover at least non-transient errors.

It's still not perfect. As I've been harping on, stdio simply isn't very
good for error reporting. For example, if an IO error happened, you'd want
to see EIO, wouldn't you? And yes, that's what the kernel would return.
However, with buffered stdio (and flushing outside of our control), what
would likely happen is that some intermediate error return _does_ return
EIO, but then the kernel might decide to re-mount the filesystem read-only
due to the error, and the actual *report* for us might be

"write failure on standard output: read-only filesystem"

which lost the EIO.

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

Merge branch 'lt/run'

* lt/run:
  Check for IO errors after running a command
  Clean up internal command handling

Merge branch 'maint'

* maint:
  Correct the name of NO_R_TO_GCC_LINKER in the comment describing it.
  git-remote: document -n
  repack: improve documentation on -a option

Correct the name of NO_R_TO_GCC_LINKER in the comment describing it.

Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote: document -n

The 'show' and 'prune' commands accept an option '-n'; document what
it does.

Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

repack: improve documentation on -a option

Some minor enhancements to the git-repack manual page.

Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-tag: Fix "can't shift that many".

This stop git-tag from emitting a "shift: can't shift that many"
error, when listing tags.

[jc: with further fixups from Sam Vilain merged in; it passes
 the tests under dash now]

Signed-off-by: Alexandre Vassalotti <alexandre@peadrop.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Correct usages of sed in git-tag for Mac OS X

Both `git-tag -l` and `git tag -v` fail on Mac OS X due to their
non-standard uses of sed.  Actually `git tag -v` fails because the
underlying git-tag-verify uses a non-standard sed command.

We now stick to only standard sed, which does make our sed scripts
slightly more complicated, but we can actually list tags with more
than 0 lines of additional context and we can verify signed tags
with gpg.  These major Git functions are much more important than
saving two or three lines of a simple sed script.

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

Update draft Release Notes for 1.5.3

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

Merge branch 'maint'

* maint:

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

* 'master' of git://repo.or.cz/git-gui:
  git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
  git-gui: Don't nice git blame on MSYS as nice is not supported
  git-gui: Don't require $DISPLAY just to get --version
  git-gui: Quiet our installation process
  git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
  git-gui: Correctly install to /usr/bin on Cygwin

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

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
  git-gui: Don't nice git blame on MSYS as nice is not supported
  git-gui: Don't require $DISPLAY just to get --version
  git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
  git-gui: Correctly install to /usr/bin on Cygwin

Avoid perl in t1300-repo-config

It fixes the test on system where ActiveState Perl is used.

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

git-cvsimport: force checkout of working tree after initial import

When creating a brand new git repository through git-cvsimport (not
incremental import), force a checkout of HEAD of master as working tree
after successful import using the -f switch to git checkout.  Otherwise
the working tree is empty, and all files are reported as 'deleted' by
git status.

This was noticed and reported by Cameron Dale through
 http://bugs.debian.org/430903

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

Add test-script for git-tag

These tests are useful to develop the C version for git-tag.sh,
ensuring that the future builtin-tag.c will not break previous
behaviour.

The tests are focused on listing, verifying, deleting and creating
tags, checking always that the correct status value is returned
and everything remains as expected.

In order to verify and create signed tags, a PGP key was also
added, being created this way: gpg --homedir t/t7004 --gen-key
Type DSA and Elgamal, size 2048 bits, no expiration date.
Name and email: C O Mitter <committer@example.com>
No password given, to enable non-interactive operation.

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

git-log: detect dup and fdopen failure

This defines xdup() and xfdopen() in git-compat-util.h to give
us error-catching variants of them without cluttering the code
too much.

Signed-off-by: Jim Meyering <jim@meyering.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-send-email: make options easier to configure.

This change makes git-send-email's behavior easier to modify by adding config
equivalents for two more of git-send-email's flags.

The mapping of flag to config setting is:
  --[no-]supress-from => sendemail.suppressfrom
  --[no-]signed-off-cc => sendemail.signedoffcc

It renames the --threaded option to --thread/--no-thread; the
config variable is also called sendemail.thread.

Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of git://git./gitk/gitk

* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Update selection background colorbar in prefs dialog
  gitk: Use a spinbox for setting tabstop settings

gitk: Update selection background colorbar in prefs dialog

The callback function was incorrectly set to update the background
colorbar when updated the selection background. This did not affect the
colors chosen or their use, just their presentation in the preferences
dialog box.

Signed-off-by: Mark Levedahl <mdl123@verizon.net>

gitk: Use a spinbox for setting tabstop settings

The tabstop must be a smallish positive integer, and a spinbox is the
accepted UI control to accomplish this limiting rather than the text
entry box previously used.

Signed-off-by: Mark Levedahl <mdl123@verizon.net>

Add test script for git-stripspace.

These tests check some features that git-stripspace already has
and those that it should manage well: Removing trailing spaces
from lines, removing blank lines at the beginning and end,
unifying multiple lines between paragraphs, doing the correct
when there is no newline at the last line, etc.

It seems that the implementation needs to save the whole line
in memory to be able to manage correctly long lines with
text and spaces conveniently distribuited on them.

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

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

* 'master' of git://repo.or.cz/git/fastimport:
  Teach bash how to complete +refspec on git-push

git-send-email: Add --threaded option

The --threaded option controls whether the In-Reply-To header will be set on
any emails sent. The current behavior is to always set this header, so this
option is most useful in its negated form, --no-threaded. This behavior can
also be controlled through the 'sendemail.threaded' config setting.

Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix git-stripspace to process correctly long lines and spaces.

Now the implementation gets more memory to store completely
each line before removing trailing spaces, and does it right
when the last line of the file ends with spaces and no newline
at the end.

Function stripspace needs again to be non-static in order to call
it from "builtin-tag.c" and the upcoming "builtin-commit.c".
A new parameter skip_comments was also added to the stripspace
function to optionally strips every shell #comment from the input,
needed for doing this task on those programs.

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

Don't ignore a pack-refs write failure

Without this, if the size of refs_file at that point is ever an exact
multiple of BUFSIZ, then an EIO or ENOSPC error on the final write would
not be diagnosed.

It's not worth worrying about EPIPE here.
Although theoretically possible that someone kill this process
with a manual SIGPIPE, it's not at all likely.

Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

detect close failure on just-written file handles

I audited git for potential undetected write failures.
In the cases fixed below, the diagnostics I add mimic the diagnostics
used in surrounding code, even when that means not reporting
the precise strerror(errno) cause of the error.

Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
  git-gui: Don't nice git blame on MSYS as nice is not supported
  git-gui: Don't require $DISPLAY just to get --version

git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack

The Tools/Migrate menu option is a hack just for me.  Yes, that's
right, git-gui has a hidden feature that really only works for me,
and the users that I support within my day-job's great firewall.
The menu option is not supported outside of that environment.

In the past we only enabled Tools/Migrate if our special local
script 'gui-miga' existed in the proper location, and if there
was a special '.pvcsrc' in the top level of the working directory.
This latter test for the '.pvcsrc' file is now failing, as the file
was removed from all Git repositories due to changes made to other
tooling within the great firewall's realm.

I have changed the test to only work on Cygwin, and only if the
special 'gui-miga' is present.  This works around the configuration
changes made recently within the great firewall's realm, but really
this entire Tools/Migrate thing should be abstracted out into some
sort of plugin system so other users can extend git-gui as they need.

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

git-gui: Don't nice git blame on MSYS as nice is not supported

Johannes Sixt reported that MinGW/MSYS does not have a nice.exe to
drop the priority of a child process when it gets spawned.  So we
have to avoid trying to start `git blame` through nice when we are
on Windows and do not have Cygwin available to us.

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

config: Add --null/-z option for null-delimted output

Use \n as delimiter between key and value and \0 as
delimiter after each key/value pair. This should be
easily parsable output.

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

Merge branch 'maint'

* maint:
  config: Change output of --get-regexp for valueless keys
  config: Complete documentation of --get-regexp
  cleanup merge-base test script
  Fix zero-object version-2 packs
  Ignore submodule commits when fetching over dumb protocols

config: Change output of --get-regexp for valueless keys

Print no space after the name of a key without value.
Otherwise keys without values are printed exactly the
same as keys with empty values.

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

config: Complete documentation of --get-regexp

The asciidoc documentation of the --get-regexp option was
incomplete. Add some missing pieces:
 - List the option in SYNOPSIS
 - Mention that key names are printed

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

git-new-workdir: Fix shell warning about operator == used with test.

Use = instead of == with test to test for equality.

Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cleanup merge-base test script

Add a picture, and keep the setup and the tests together.

Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.spec: RPM failed, looking for wrong files.

RPM build broke with "File not found" error on git-gui.1 and git-citool.1
They actually are git-gui.1.gz and git-citool.1.gz

Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix zero-object version-2 packs

A pack-file can get created without any objects in it (to transfer "no
data" - which can happen if you use a reference git repo, for example,
or just otherwise just end up transferring only branch head information
and already have all the objects themselves).

And while we probably should never create an index for such a pack, if we
do (and we do), the index file size sanity checking was incorrect.

This fixes it.

Reported-and-tested-by: Jocke Tjernlund <tjernlund@tjernlund.se>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Ignore submodule commits when fetching over dumb protocols

Without this patch, the code would look for the submodule
commits in the superproject and (needlessly) fail when it
couldn't find them.

Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of git://git./gitk/gitk into pm/gitk

* 'master' of git://git.kernel.org/pub/scm/gitk/gitk: (21 commits)
  gitk: Add a progress bar to show progress while resetting
  gitk: Improve handling of whitespace and special chars in filenames
  gitk: Fix bug causing nearby tags/heads to sometimes not be displayed
  gitk: Limit how often we change the canvas scrolling region
  gitk: Add a "reset branch to here" row context-menu operation
  gitk: Get rid of the childlist variable
  gitk: Speed up the reading of references
  gitk: Show local uncommitted changes as a fake commit
  gitk: New algorithm for drawing the graph lines
  gitk: Store ids in rowrangelist and idrowranges rather than row numbers
  gitk: Disable the head context menu entries for the checked-out branch
  gitk: Cope with commit messages with carriage-returns and initial blank lines
  gitk: Implement a simple scheduler for the compute-intensive stuff
  gitk: Improve the behaviour of the initial selection
  gitk: Add some more comments to the optimize_rows procedure
  gitk: Don't try to list large numbers of tags or heads in the details pane
  gitk: New infrastructure for working out branches & previous/next tags
  [PATCH] gitk: Allow specifying tabstop as other than default 8 characters.
  [PATCH] gitk: Update fontsize in patch / tree list
  [PATCH] gitk: Make selection highlight color configurable
  ...

Conflicts:

gitk

gitk: Add a progress bar to show progress while resetting

Since git reset now gets chatty while resetting, we were getting errors
reported when a reset was done using the "reset branch to here" menu
item.  With this we now read the progress messages from git reset and
update a progress bar.  Because git reset outputs the progress messages
to standard error, and Tcl treats messages to standard error as error
messages, we have to invoke git reset via a shell and redirect standard
error into standard output.

This also fixes a bug in computing descendent heads when head ids
are changed via a reset.

Signed-off-by: Paul Mackerras <paulus@samba.org>

Check for IO errors after running a command

This is trying to implement the strict IO error checks that Jim Meyering
suggested, but explicitly limits it to just regular files. If a pipe gets
closed on us, we shouldn't complain about it.

If the subcommand already returned an error, that takes precedence (and we
assume that the subcommand already printed out any relevant messages
relating to it)

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

Clean up internal command handling

This should change no code at all, it just moves the definition of "struct
cmd_struct" out, and then splits out the running of the right command into
the "run_command()" function.

It also removes the long-unused 'envp' pointer passing.

This is just preparation for adding some more error checking.

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

Teach bash how to complete +refspec on git-push

Using `git push origin +foo` to forcefully overwrite the remote
branch named foo is a common idiom, especially since + is shorter
than the long option --force and can be specified on a per-branch
basis.

We now complete `git push origin +foo` just like we do the standard
`git push origin foo`.  The leading + on a branch refspec does not
alter the completion.

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

git-send-email: Do not make @-less message ID

When the original $from address fails to yield a valid-looking
e-mail address, we created a bogus looking message ID, formatted
like this:

Message-Id: <11823357623688-git-send-email->

This commit fixes it by moving call to make_message_id() to
where it matters, namely, before the $message_id is needed to be
placed in the generated e-mail header; this has an important
side effect of making it clear that $from is already available.

Also throw in Sys::Hostname::hostname() just for fun, although I
suspect that the code would never trigger due to the modified
call sequence that makes sure $from is always available.  This
is based on a suggestion by Michael Hendricks.

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

git-svn: trailing slash in prefix is mandatory with --branches/-b

Make clear in the documentation that when using --branches/-b and
--prefix with 'init', the prefix must include a trailing slash.
This matches the actual behavior of git-svn, e.g.:

 $ git svn init -Ttrunk -treleases -bbranches --prefix xxx \
     http://svn.sacredchao.net/svn/quodlibet/
 --prefix='xxx' must have a trailing slash '/'
 $

This was noticed by R. Vanicat and reported through
 http://bugs.debian.org/429443

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

new-workdir: handle rev-parse --git-dir not always giving full path

rev-parse --git-dir outputs a full path - except for the single case
of when the path would be $(pwd)/.git, in which case it outputs simply
.git.  Check for this special case and handle it.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

make dist: include configure script in tarball

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

Merge branch 'lt/follow'

* lt/follow:
  Fix up "git log --follow" a bit..
  Finally implement "git log --follow"

t9500: skip gitweb tests if perl version is too old

gitweb calls Encode::decode_utf8 with two arguments,
but old versions of perl only allow this function to be called
with one argument.  Even older versions of perl do not even
have an Encode module.

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

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

* 'master' of git://repo.or.cz/git/fastimport: (260 commits)
  Avoid src:dst syntax as default bash completion for git push
  Make it possible to specify the HEAD for the internal findUpstreamBranchPoint function.
  Added git-p4 branches command that shows the mapping of perforce depot paths to imported git branches.
  Warn about conflicting p4 branch mappings and use the first one found.
  Fix the branch mapping detection to be independent from the order of the "p4 branches" output.
  git-p4 fails when cloning a p4 depo.
  Fix initial multi-branch import.
  Only use double quotes on Windows
  Fix git-p4 rebase to detect the correct upstream branch instead of unconditionally
  Moved the code from git-p4 submit to figure out the upstream branch point
  git-p4 submit: Fix missing quotes around p4 commands to make them work with spaces in filenames
  Mention remotes/p4/master also in the documentation.
  Provide some information for single branch imports where the commits go
  git-p4: check for existence of repo dir before trying to create
  Write out the options tag in the log message of imports only if we actually have
  Fix support for explicit disabling of syncing with the origin
  Fix depot-paths encoding for multi-path imports (don't split up //depot/path/foo)
  Fix project name guessing
  Fix updating/creating remotes/p4/* heads from origin/p4/*
  Fixed the check to make sure to exclude the HEAD symbolic refs when updating
  ...

gitk: Improve handling of whitespace and special chars in filenames

The main thing here is better parsing of the diff --git lines in the
output of git diff-tree -p.  We now cope with filenames in quotes with
special chars escaped.  If the filenames contain spaces they aren't
quoted, however, which can create difficulties in parsing.  We get
around the difficulties by detecting the case when the filename hasn't
changed (chop the part after "diff --git " in two and see if the halves
match apart from a/ in one and b/ in the other), and if it hasn't
changed, we just use one half.  If the filename has changed we wait
for the "rename from" and "rename to" lines, which give the old and
new filenames unambiguously.

This also improves the parsing of the output of git diff-tree.
Instead of using lindex to extract the filename, we take the part from
the first tab on, and if it starts with a quote, we use [lindex $str 0]
to remove the quotes and convert the escapes.

This also gets rid of some unused tagging of the diff text, uses
[string compare] instead of [regexp] in some places, and fixes the
regexp for detecting the @@ hunk-separator lines (the regexp wasn't
accepting a single number, as in "-0,0 +1" for example).

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Fix bug causing nearby tags/heads to sometimes not be displayed

When we compute descendent heads and descendent/ancestor tags, we
cache the results.  We need to be careful to invalidate the cache
when we add stuff to the graph.  Also make sure that when we cache
descendent heads for a node we only cache the heads that are actually
descendents of that node.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Limit how often we change the canvas scrolling region

For some unknown reason, changing the scrolling region on the canvases
provokes multiple milliseconds worth of computation in the X server,
and this can end up slowing gitk down significantly.  This works around
the problem by limiting the rate at which we update the scrolling region
after the first 100 rows to at most 2 per second.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Add a "reset branch to here" row context-menu operation

This adds an entry to the menu that comes up when the user does a
right-click on a row.  The new entry allows the user to reset the
currently checked-out head to the commit for the row that they did
the right-click on.  The user has to select what type of reset to
do, and confirm the reset, via a dialog box that pops up.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Get rid of the childlist variable

The information in childlist is a duplicate of what's in the children
array, and it wasn't being accessed often enough to be really worth
keeping the list around as well.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Speed up the reading of references

We were doing two execs for each tag - one to map the tag ID to a
commit ID and one to read the contents of the tag for later display.
This speeds up the process by not reading the contents of the tag
(instead it is read later if needed), and by using the -d flag to
git show-ref, which gives us refs/tags/foo^{} lines which give us
the commit ID.  Also this uses string operations instead of regexps.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Show local uncommitted changes as a fake commit

If there are local changes in the repository, i.e., git-diff-index HEAD
produces some output, then this optionally displays an extra row in
the graph as a child of the HEAD commit (but with a red circle to
indicate that it's not a real commit).  There is a checkbox in the
preferences window to control whether gitk does this or not.

Clicking on the extra row shows the diffs between the working directory
and the HEAD (using git diff-index -p).  The right-click menu on the
extra row allows the user to generate a patch containing the local diffs,
or to display the diffs between the working directory and any commit.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: New algorithm for drawing the graph lines

This only draws as much of the graph lines as is visible.  This can
happen by adding coordinates on to an existing graph line or by
creating a new line.  This means that we only need to have laid out
and optimized as much of the graph as is actually visible in order to
draw it, including the lines (previously we didn't draw a graph
line until we had laid out and optimized to the end of a segment of
the line, i.e. down to a down-arrow or to the row where the line's
commit is displayed).  This also lets us get rid of the linesegends
list, and gives us an easy workaround for the X server bug that
causes long lines to be misdrawn.  This also gets rid of the use
of rowoffsets in drawlineseg et al.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Store ids in rowrangelist and idrowranges rather than row numbers

This removes the need for insertrow to go through rowrangelist and
idrowranges and adjust a lot of entries.  The first entry for a given
id is now the row number of the first child, not that row number + 1,
and rowranges compensates for that so its callers didn't have to
change.  This adds a ranges argument to drawlineseg so that we can
avoid calling rowranges a second time inside drawlineseg (all its
callers already called rowranges).

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Disable the head context menu entries for the checked-out branch

Neither the "check out this branch" nor the "remove this branch"
menu item can be used on the currently-checked out branch, so disable
them.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Cope with commit messages with carriage-returns and initial blank lines

In some repositories imported from other systems we can get carriage
return characters in the commit message, which leads to a multi-line
headline being displayed in the summary window, which looks bad.
Also some commit messages start with one or more blank lines, which
leads to an empty headline.  This fixes these problems.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Implement a simple scheduler for the compute-intensive stuff

This allows us to do compute-intensive processing, such as laying out
the graph, relatively efficiently while also having the GUI be
reasonably responsive.  The problem previously was that file events
were serviced before X events, so reading from another process which
supplies data quickly (hi git rev-list :) could mean that X events
didn't get processed for a long time.

With this, gitk finishes laying out the graph slightly sooner and
still responds to the GUI while doing so.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Improve the behaviour of the initial selection

It used to be that if you clicked on a line while gitk was still drawing
stuff, it would immediately re-select the first line of the display.
This fixes that.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Add some more comments to the optimize_rows procedure

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Don't try to list large numbers of tags or heads in the details pane

With some large repositories, a commit can end up on thousands of
branches, which results in an extremely long "Branches:" line in the
details window, and that results in the window being extremely slow
to scroll.

This fixes it by just showing "many (N)" after "Branches:", "Follows:"
or "Precedes:", where N is the number of heads or tags.  The limit
is currently set at 20 but could be made configurable (and the "many"
could be a link to pop up a window listing them all in case anyone
really wants to know).

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: New infrastructure for working out branches & previous/next tags

Instead of working out descendent heads and descendent & ancestor
branches in a two-pass algorithm, this reads and stores a simplified
version of the graph topology, and works out descendent/ancestor
tags and descendent heads on demand (with a bit of caching).

The advantages of this are, first, that we now don't have to use
--topo-order on the git rev-list process.  Secondly, we don't have
to re-read the whole graph when tags or heads change or even when
the graph changes.  Since we can cope with parents coming before
children, we can update the graph by running a git rev-list with
arguments that just give us the new commits, and merge the new
commits into the simplified graph.

The graph is simplified in the sense that commits with exactly one
parent and one child (which is >90% of them in most cases) are grouped
together into arcs joining nodes or 'branch/merge points', which are
the commits that don't have exactly 1 parent and 1 child.  This reduces
the size of the graph substantially and decreases the time to traverse
it correspondingly.

Signed-off-by: Paul Mackerras <paulus@samba.org>

Fix up "git log --follow" a bit..

This fixes "git log --follow" to hopefully not leak memory any more, and
also cleans it up a bit to look more like some of the other functions that
use "diff_queued_diff" (by *not* using it directly as a global in the
code, but by instead just taking a pointer to the diff queue and using
that).

As to "diff_queued_diff", I think it would be better off not as a global
at all, but as being just an entry in the "struct diff_options" structure,
but that's a separate issue, and there may be some subtle reason for why
it's currently a global.

Anyway, no real changes. Instead of having a magical first entry in the
diff-queue, we now end up just keeping the diff-queue clean, and keeping
our "preferred" file pairing in an internal "choice" variable. That makes
it easy to switch the choice around when we find a better one.

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

Finally implement "git log --follow"

Ok, I've really held off doing this too damn long, because I'm lazy, and I
was always hoping that somebody else would do it.

But no, people keep asking for it, but nobody actually did anything, so I
decided I might as well bite the bullet, and instead of telling people
they could add a "--follow" flag to "git log" to do what they want to do,
I decided that it looks like I just have to do it for them..

The code wasn't actually that complicated, in that the diffstat for this
patch literally says "70 insertions(+), 1 deletions(-)", but I will have
to admit that in order to get to this fairly simple patch, you did have to
know and understand the internal git diff generation machinery pretty
well, and had to really be able to follow how commit generation interacts
with generating patches and generating the log.

So I suspect that while I was right that it wasn't that hard, I might have
been expecting too much of random people - this patch does seem to be
firmly in the core "Linus or Junio" territory.

To make a long story short: I'm sorry for it taking so long until I just
did it.

I'm not going to guarantee that this works for everybody, but you really
can just look at the patch, and after the appropriate appreciative noises
("Ooh, aah") over how clever I am, you can then just notice that the code
itself isn't really that complicated.

All the real new code is in the new "try_to_follow_renames()" function. It
really isn't rocket science: we notice that the pathname we were looking
at went away, so we start a full tree diff and try to see if we can
instead make that pathname be a rename or a copy from some other previous
pathname. And if we can, we just continue, except we show *that*
particular diff, and ever after we use the _previous_ pathname.

One thing to look out for: the "rename detection" is considered to be a
singular event in the _linear_ "git log" output! That's what people want
to do, but I just wanted to point out that this patch is *not* carrying
around a "commit,pathname" kind of pair and it's *not* going to be able to
notice the file coming from multiple *different* files in earlier history.

IOW, if you use "git log --follow", then you get the stupid CVS/SVN kind
of "files have single identities" kind of semantics, and git log will just
pick the identity based on the normal move/copy heuristics _as_if_ the
history could be linearized.

Put another way: I think the model is broken, but given the broken model,
I think this patch does just about as well as you can do. If you have
merges with the same "file" having different filenames over the two
branches, git will just end up picking _one_ of the pathnames at the point
where the newer one goes away. It never looks at multiple pathnames in
parallel.

And if you understood all that, you probably didn't need it explained, and
if you didn't understand the above blathering, it doesn't really mtter to
you. What matters to you is that you can now do

git log -p --follow builtin-rev-list.c

and it will find the point where the old "rev-list.c" got renamed to
"builtin-rev-list.c" and show it as such.

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

Merge branch 'jc/oneline'

* jc/oneline:
  pp_header(): work around possible memory corruption

Merge branch 'ei/oneline+add-empty'

* ei/oneline+add-empty:
  Fix ALLOC_GROW calls with obsolete semantics
  Fix ALLOC_GROW off-by-one
  builtin-add: simplify (and increase accuracy of) exclude handling
  dir_struct: add collect_ignored option
  Extend --pretty=oneline to cover the first paragraph,
  Lift 16kB limit of log message output

filter-branch: add example to move everything into a subdirectory

This is based on Jeff King's example in

20070621130137.GB4487@coredump.intra.peff.net

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

Merge branch 'js/filter'

* js/filter:
  filter-branch: subdirectory filter needs --full-history
  filter-branch: Simplify parent computation.
  Teach filter-branch about subdirectory filtering
  filter-branch: also don't fail in map() if a commit cannot be mapped
  filter-branch: Use rev-list arguments to specify revision ranges.
  filter-branch: fix behaviour of '-k'
  filter-branch: use $(($i+1)) instead of $((i+1))
  chmod +x git-filter-branch.sh
  filter-branch: prevent filters from reading from stdin
  t7003: make test repeatable
  Add git-filter-branch

Two trivial -Wcast-qual fixes

Luiz Fernando N. Capitulino noticed the one in tree-walk.h where
we cast away constness while computing the legnth of a tree
entry.

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

diffcore-rename: favour identical basenames

When there are several candidates for a rename source, and one of them
has an identical basename to the rename target, take that one.

Noticed by Govind Salinas, posted by Shawn O. Pearce, partial patch
by Linus Torvalds.

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

Document git-gui, git-citool as mainporcelain manual pages

Jakub Narebski pointed out that the git-gui blame viewer is not a
widely known feature, but is incredibly useful.  Part of the issue
is advertising.  Up until now we haven't even referenced git-gui from
within the core Git manual pages, mostly because I just wasn't sure
how I wanted to supply git-gui documentation to end-users, or how
that documentation should integrate with the core Git documentation.

Based upon Jakub's comment that many users may not even know that
the gui is available in a stock Git distribution I'm offering up
two basic manual pages: git-citool and git-gui.  These should offer
enough of a starting point for users to identify that the gui exists,
and how to start it.  Future releases of git-gui may contain their
own documentation system available from within a running git-gui.
But not today.

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

Generate tags with correct timestamp (git-svnimport)

Now uses git-tag instead of manually constructing the tag.  This gives us a
correct timestamp, removes some crufty code, and makes it work the same as
git-cvsimport.

The generated tags are now lightweight tags instead of tag objects, which may
or may not be the behaviour we want.

Also, remove two unused variables from git-cvsimport.

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

Import branch 'git-p4' of git://repo.or.cz/fast-export

Simon has asked that the git.git project include the git-p4 project
as at least a contrib/fast-import within git.git.  I think it makes
a lot of sense, as git-p4 nicely complements the only other in-tree
fast-import user: import-tars.perl.

git-p4 is offered under the MIT license by its authors.

Avoid src:dst syntax as default bash completion for git push

Raimund Bauer just discovered that the default bash completion for
a local branch name in a git-push line is not the best choice when
the branch does not exist on the remote system.

In the past we have always completed the local name 'test' as
"test:test", indicating that the destination name is the same as
the local name.  But this fails when "test" does not yet exist on
the remote system, as there is no "test" branch for it to match
the name against.

Fortunately git-push does the right thing when given just the
local branch, as it assumes you want to use the same name in the
destination repository.  So we now offer "test" as the completion
in a git-push line, and let git-push assume that is also the remote
branch name.

We also still support the remote branch completion after the :,
but only if the user manually adds the colon before trying to get
a completion.

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

git-gui: Don't require $DISPLAY just to get --version

Junio asked that we don't force the user to have a valid X11 server
configured in $DISPLAY just to obtain the output of `git gui version`.
This makes sense, the user may be an automated tool that is running
without an X server available to it, such as a build script or other
sort of package management system.  Or it might just be a user working
in a non-GUI environment and wondering "what version of git-gui do I
have installed?".

Tcl has a lot of warts, but one of its better ones is that a comment
can be continued to the next line by escaping the LF that would have
ended the comment using a backslash-LF sequence.  In the past we have
used this trick to escape away the 'exec wish' that is actually a Bourne
shell script and keep Tcl from executing it.

I'm using that feature here to comment out the Bourne shell script and
hide it from the Tcl engine.  Except now our Bourne shell script is a
few lines long and checks to see if it should print the version, or not.

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

Make it possible to specify the HEAD for the internal findUpstreamBranchPoint function.

This isn't used right now in git-p4 but I use it in an external script that loads git-p4 as module.

Signed-off-by: Simon Hausmann <shausman@trolltech.com>

Merge branch 'maint'

* maint:
  git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
  git-gui: Correctly install to /usr/bin on Cygwin

git-gui: Quiet our installation process

Alex Riesen wanted a quieter installation process for git and its
contained git-gui.  His earlier patch to do this failed to work
properly when V=1, and didn't really give a great indication of
what the installation was doing.

These rules are a little bit on the messy side, as each of our
install actions is composed of at least two variables, but in the
V=1 case the text is identical to what we had before, while in the
non-V=1 case we use some more complex rules to show the interesting
details, and hide the less interesting bits.

We now can also set QUIET= (nothing) to see the rules that are used
when V= (nothing), so we can debug those too if we have to.  This is
actually a side-effect of how we insert the @ into the rules we use
for the "lists of things", like our builtins or our library files.

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

git-gui: Bind Tab/Shift-Tab to cycle between panes in blame

The blame viewer is composed of two different areas, the file
area on top and the commit area on the bottom.  If users are
trying to shift the focus it is probably because they want to
shift from one area to the other, so we just setup Tab and
Shift-Tab to jump from the one half to the other in a cycle.

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

git-gui: Correctly install to /usr/bin on Cygwin

Mark Levedahl <mlevedahl@gmail.com> noted that installation on Cygwin
to /usr/bin can cause problems with the automatic guessing of our
library location.  The problem is that installation to /usr/bin
means we actually have:

  /usr/bin   = c:\cygwin\bin
  /usr/share = c:\cygwin\usr\share

So git-gui guesses that its library should be found within the
c:\cygwin\share directory, as that is where it should be relative
to the script itself in c:\cygwin\bin.

In my first version of this patch I tried to use `cygpath` to resolve
/usr/bin and /usr/share to test that they were in the same relative
locations, but that didn't work out correctly as we were actually
testing /usr/share against itself, so it always was equal, and we
always used relative paths.  So my original solution was quite wrong.

Mark suggested we just always disable relative behavior on Cygwin,
because of the complexity of the mount mapping problem, so that's
all I'm doing.

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

Cloning from a repo without "current branch"

If the remote repository does not have a "current branch", git-clone
was confused and did not set up the resulting new repository
correctly.  It did not reset HEAD from the default 'master', and did
not write the SHA1 to the master branch.

Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Change default man page path to /usr/share/man

According to FHS,

    http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES

default man page path is $prefix/share/man.

Signed-off-by: Ismail Donmez <ismail@pardus.org.tr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

INSTALL: explain how to build documentation

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

cvsserver: Actually implement --export-all

Frank Lichtenheld, Fri, Jun 15, 2007 03:01:53 +0200:
> +test_expect_failure 'req_Root failure (export-all w/o whitelist)' \
> +  'cat request-anonymous | git-cvsserver --export-all pserver >log 2>&1
> +   || false'

This does not work, at least for bash in current Ubuntu:

    GNU bash, version 3.2.13(1)-release

You have to put "||" on the previous line:

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

Added git-p4 branches command that shows the mapping of perforce depot paths to imported git branches.

Signed-off-by: Simon Hausmann <simon@lst.de>

Warn about conflicting p4 branch mappings and use the first one found.

Signed-off-by: Simon Hausmann <simon@lst.de>

Fix the branch mapping detection to be independent from the order of the "p4 branches" output.

Collect "unknown" source branches separately and register them at the end.

Also added a minor speed up to splitFilesIntoBranches by breaking out of the loop through all branches when it's safe.

Signed-off-by: Simon Hausmann <simon@lst.de>

Fix ALLOC_GROW calls with obsolete semantics

ALLOC_GROW now expects the 'nr' argument to be "how much you
want" and not "how much you have". This fixes all cases
where we weren't previously adding anything to the 'nr'.

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

Merge branch 'jk/add-empty' into ei/oneline+add-empty

* jk/add-empty:
  builtin-add: simplify (and increase accuracy of) exclude handling
  dir_struct: add collect_ignored option

pp_header(): work around possible memory corruption

add_user_info() possibly adds way more than just the commit header line.
In fact, it sometimes needs so much more space that there is a buffer
overrun, leading to an ugly crash. For example, the date is printed in its
own line, and usually takes up more space than the equivalent Unix epoch.

So, for good measure, add 80 characters (a full line) to the allocated
space, in addition to the header line length.

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

Fix ALLOC_GROW off-by-one

The ALLOC_GROW macro will never let us fill the array completely,
instead allocating an extra chunk if that would be the case. This is
because the 'nr' argument was originally treated as "how much we do have
now" instead of "how much do we want". The latter makes much more
sense because you can grow by more than one item.

This off-by-one never resulted in an error because it meant we were
overly conservative about when to allocate. Any callers which passed
"how much we have now" need to be updated, or they will fail to allocate
enough.

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

Document git log --full-diff

Based on description of commit 477f2b41310c4b1040a9e7f72720b9c39d82caf9
"git log --full-diff" adding this option.

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

Document git log --abbrev-commit, as a kind of pretty option

Documentation taken from paraphrased description of "--abbrev[=<n>]"
diff option, and from description of commit 5c51c985 introducing
this option.

Note that to change number of digits one must use "--abbrev=<n>",
which affects [also] diff output.

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