tokkee.org

Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file.

Runtime is now independent of the number of modified files.

The old implementation executed 'cvs status' for each file touched by the patch
to be applied. The new code calls 'cvs status' only once with all touched files
and parses cvs's output to collect all available status information.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs

$Id$ is present already in SVN and CVS; it would mean that people
converting their existing repositories won't have to make any changes to
the source files should they want to make use of the ident attribute.

Given that it's a feature that's meant to calm those very people, it
seems obtuse to make them edit every file just to make use of it.

I think that bzr uses $Id$; Mercurial has examples hooks for $Id$;
monotone has $Id$ on its wishlist.  I can't think of a good reason not
to stick with the de-facto standard and call ours $Id$ instead of
$ident$.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'maint'

* maint:
  Prepare for 1.5.1.5 Release Notes
  gitweb: Add a few comments about %feature hash
  git-am: Clean up the asciidoc documentation
  Documentation: format-patch has no --mbox option
  builtin-log.c: Fix typo in comment
  Fix git-clone buglet for remote case.

Prepare for 1.5.1.5 Release Notes

Hopefully we will have 1.5.2 soonish, to contain all of these,
but we should summarize what we have done regardless.

Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Add a few comments about %feature hash

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-am: Clean up the asciidoc documentation

Add --keep to synopsis.

The synopsys used a mix of tabs and spaces, unify to use only
spaces.

Shuffle options around in synopsys and description for grouping
them logically.

Add more gitlink references to other commands.

Various grammatical fixes and improvements.

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: format-patch has no --mbox option

git-applymbox and git-mailinfo refer to a --mbox option of
git-format-patch when talking about their -k options. But there
is no such option.  What -k does to the former two commands is
to keep the Subject: lines unmunged, meant to be used on output
generated with format-patch -k.

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

builtin-log.c: Fix typo in comment

s/fmt-patch/format-patch/

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix git-clone buglet for remote case.

c2f599e09fd0496413d1744b5b89b9b5c223555d introduced a buglet while
cloning from a remote URL; we forgot to squelch the unnecessary
error message when we try to cd to the given "remote" name,
in order to see if it is a local directory.

Signed-off-by: Junio C Hamano <junkio@cox.net>

cvsserver: Don't send mixed messages to clients

After we send I HATE YOU we should probably exit and not happily
continue with I LOVE YOU and further communication.

Most clients will probably just exit and ignore everything we
send after the I HATE YOU and it is not a security problem
either because we don't really care about the user name anyway.

But it is still the right thing to do.

[jc: with a minor fixup to its exit code...]

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: "Martin Langhoff" <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation/git-add: clarify -u with path limiting

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: Split description of pretty formats of commit log

Split description of pretty formats into list of pretty options
(--pretty and --encoding) in new file Documentation/pretty-options.txt
and description of formats itself as a separate "PRETTY FORMATS"
section in pretty-formats.txt

While at it correct formatting a bit, to be better laid out in the
resulting manpages: git-rev-list(1), git-show(1), git-log(1) and
git-diff-tree(1).  Those manpages now include pretty options in the
same place as it was before, and description of formats just after
all options.

Inspired by the split into two filesdocumentation for merge strategies:
Documentation/merge-options.txt and Documentation/merge-strategies.txt

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Fix "Use of unitialized value" warnings in empty repository

Fix it so gitweb doesn't write "Use of unitialized value..." warnings
(which gets written in web server logs) for empty (no commits)
repository.

In empty repository "last change" (last activity) doesn't make sense;
also there is no sense in parsing commits which aren't there.

In projects list for empty repositories gitweb now writes "No commits"
using "noage" class, instead of leaving cell empty, in the last change
column.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'maint'

* maint:
  git-svn: don't attempt to minimize URLs by default
  git-svn: fix segfaults due to initial SVN pool being cleared
  git-svn: clean up caching of SVN::Ra functions
  git-svn: don't drop the username from URLs when dcommit is run
  RPM spec: include files in technical/ to package.
  Remove stale non-static-inline prototype for tree_entry_extract()
  git-config: test for 'do not forget "a.b.var" ends "a.var" section'.
  git-config: do not forget seeing "a.b.var" means we are out of "a.var" section.

cvsserver: Limit config parser to needed options

Change the configuration parser so that it ignores
everything except for ^gitcvs.((ext|pserver).)?
This greatly reduces the risk of failing while
parsing some unknown and irrelevant config option.

The bug that triggered this change was that the
parsing doesn't handle sections that have a
subsection and a variable with the same name.

While this bug still remains, all remaining
causes can be attributed to user error, since
there are no defined variables gitcvs.ext and
gitcvs.pserver.

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Check if requested object exists

Try to avoid "Use of uninitialized value ..." errors caused by bad
revision, incorrect filename, wrong object id, bad file etc. (wrong
value of 'h', 'hb', 'f', etc. parameters). This avoids polluting web
server errors log.

Correct git_get_hash_by_path and parse_commit_text (and, in turn,
parse_commit) to return undef if object does not exist.  Check in
git_tag if requested tag exists.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Link to HTML version of external doc if available

Currently

$ git grep '\([^t]\|^\)'link: user-manual.txt

gives four hits that refer to .txt version of the documentation
set, but at least "hooks" and "cvs-migration" have HTML variants
installed, so refer to them instead.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-svn: don't attempt to minimize URLs by default

For tracking branches and tags, git-svn prefers to connect
to the root of the repository or at least the level that
houses branches and tags as well as trunk.  However, users
that are accustomed to tracking a single directory have
no use for this feature.

As pointed out by Junio, users may not have permissions to
connect to connect to a higher-level path in the repository.

While the current minimize_url() function detects lack of
permissions to certain paths _after_ successful logins, it
cannot effectively determine if it is trying to access a
login-only portion of a repo when the user expects to
connect to a part where anonymous access is allowed.

For people used to the git-svnimport switches of
--trunk, --tags, --branches, they'll already pass the
repository root (or root+subdirectory), so minimize URL
isn't of too much use to them, either.

For people *not* used to git-svnimport, git-svn also
supports:

 git svn init --minimize-url \
  --trunk http://repository-root/foo/trunk \
  --branches http://repository-root/foo/branches \
  --tags http://repository-root/foo/tags

And this is where the new --minimize-url command-line switch
comes in to allow for this behavior to continue working.

git-svn: fix segfaults due to initial SVN pool being cleared

Some parts of SVN always seem to use it, even if the SVN::Ra
object we're using is no longer used and we've created a new one
in its place.  It's also true that only one SVN::Ra connection
can exist at once...  Using SVN::Pool->new_default when the
SVN::Ra object is created doesn't seem to help very much,
either...

Hopefully this fixes all segfault problems users have been
experiencing over the past few months.

Signed-off-by: Eric Wong <normalperson@yhbt.net>

git-svn: clean up caching of SVN::Ra functions

This patch was originally intended to make the Perl GC more
sensitive to the SVN::Pool objects and not accidentally clean
them up when they shouldn't be (causing segfaults).  That didn't
work, but this patch makes the code a bit cleaner regardless

Put our caches for get_dir and check_path calls directly into
the SVN::Ra object so they auto-expire when it is destroyed.

dirents returned by get_dir() no longer needs the pool object
stored persistently along with the cache data, as they'll be
converted to native Perl hash references.

Since calling rev_proplist repeatedly per-revision is no longer
needed in git-svn, we do not cache calls to it.

Signed-off-by: Eric Wong <normalperson@yhbt.net>

git-svn: don't drop the username from URLs when dcommit is run

We no longer store usernames in URLs stored in git-svn-id lines
for dcommit, so we shouldn't rely on those URLs when connecting
to the remote repository to commit.

RPM spec: include files in technical/ to package.

Not only that they are interesting to users, some of the
files are linked to by the included "Git User's Manual"

Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Remove stale non-static-inline prototype for tree_entry_extract()

When 4651ece8 made the function a "static inline", it should
have removd the stale prototype but everybody missed that.

Thomas Glanzmann noticed this broke compilation with Forte12
compiler on his Sun boxes.

Signed-off-by: Junio C Hamano <junkio@cox.net>

git-config: test for 'do not forget "a.b.var" ends "a.var" section'.

Added test for mentioned bugfix.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-config: do not forget seeing "a.b.var" means we are out of "a.var" section.

Earlier code tried to be half-careful and knew the logic that
seeing "a.var" after seeing "a.b.var" is a sign of the previous
"a.b." section has ended, but forgot it has to handle the other
way.  Seeing "a.b.var" after seeing "a.var" is a sign that "a."
section has ended, so a new "a.var2" variable should be added
before the location "a.b.var" appears.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Minor fixup to documentation of hooks in git-receive-pack.

Small additional changes to the cbb84e5d174cf33fd4dcf3136de50a886ff9a2e2
commit, which introduced documentation to pre-receive and post-receive:
 - Mention that stdout and stderr are equivalent.
 - Add one cross-section link and fix one other.
 - Fix information on advantages of post-receive over post-update.

Signed-off-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'maint'

* maint:
  checkout: allow detaching to HEAD even when switching to the tip of a branch
  Updated documentation of hooks in git-receive-pack.
  Allow fetching references from any namespace
  tiny fix in documentation of git-clone
  Fix an unmatched comment end in arm/sha1_arm.S

checkout: allow detaching to HEAD even when switching to the tip of a branch

You cannot currently checkout the tip of an existing branch
without moving to the branch.

This allows you to detach your HEAD and place it at such a
commit, with:

    $ git checkout master^0

Signed-off-by: Junio C Hamano <junkio@cox.net>

Updated documentation of hooks in git-receive-pack.

Added documentation of pre-receive and post-receive hooks and updated
documentation of update and post-update hooks.

[jc: with minor copy-editing]

Signed-off-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>

t9400: Use the repository config and nothing else.

git-cvsserver has a bug in its configuration file output parser
that makes it choke if the configuration has these:

        [diff]
                color = auto
        [diff.color]
                whitespace = blue reverse

This needs to be fixed, but thanks to that bug, a separate bug
in t9400 test script was discovered.  The test discarded
GIT_CONFIG instead of pointing at the proper one to be used in
the exoprted repository.  This allowed user's .gitconfig and (if
exists) systemwide /etc/gitconfig to affect the outcome of the
test, which is a big no-no.

The patch fixes the problem in the test.  Fixing the
git-cvsserver's configuration parser is left as an exercise to
motivated volunteers ;-)

Signed-off-by: Junio C Hamano <junkio@cox.net>

Allow fetching references from any namespace

not only from the three defined: heads, tags and remotes.

Noticed when I tried to fetch the references created by git-p4-import.bat:
they are placed into separate namespace (refs/p4import/, to avoid showing
them in git-branch output). As canon_refs_list_for_fetch always prepended
refs/heads/ it was impossible, and annoying: it worked before. Normally,
the p4import references are useless anywhere but in the directory managed
by perforce, but in this special case the cloned directory was supposed
to be a backup, including the p4import branch: it keeps information about
where the imported perforce state came from.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-archive: don't die when repository uses subprojects

Both archive-tar and archive-zip needed to be taught about subprojects.
The tar function died when trying to read the subproject commit object,
while the zip function reported "unsupported file mode".

This fixes both by representing the subproject as an empty directory.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

tiny fix in documentation of git-clone

path in example was missing '../'

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Test if $from_id and $to_id are defined before comparison

Get rid of "Use of uninitialized value in string eq at
gitweb/gitweb.perl line 2320" warning caused by the fact that "empty"
patches, consisting only of extended git diff header and with patch
body empty, such as patch for pure rename, does not have "index" line
in extended diff header.  For such patches $from_id and $to_id, filled
from parsing extended diff header, are undefined.  But such patches
cannot be continuation patches.

Test if $from_id and $to_id are defined before comparing them with
$diffinfo.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix an unmatched comment end in arm/sha1_arm.S

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-add: allow path limiting with -u

Rather than updating all working tree paths, we limit
ourselves to paths listed on the command line.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

read-tree -m -u: avoid getting confused by intermediate symlinks.

When switching from a branch with both x86_64/boot/Makefile and
i386/boot/Makefile to another branch that has x86_64/boot as a
symlink pointing at ../i386/boot, the code incorrectly removed
i386/boot/Makefile.

This was because we first removed everything under x86_64/boot
to make room to create a symbolic link x86_64/boot, then removed
x86_64/boot/Makefile which no longer exists but now is pointing
at i386/boot/Makefile, thanks to the symlink we just created.

This fixes it by using the has_symlink_leading_path() function
introduced previously for git-apply in the checkout codepath.
Earlier, "git checkout" was broken in t4122 test due to this
bug, and the test had an extra "git reset --hard" as a
workaround, which is removed because it is not needed anymore.

Signed-off-by: Junio C Hamano <junkio@cox.net>

apply: do not get confused by symlinks in the middle

HPA noticed that git-rebase fails when changes involve symlinks
in the middle of the hierarchy.  Consider:

 * The tree state before the patch is applied has arch/x86_64/boot
   as a symlink pointing at ../i386/boot/

 * The patch tries to remove arch/x86_64/boot symlink, and
   create bunch of files there: .gitignore, Makefile, etc.

git-apply tries to be careful while applying patches; it never
touches the working tree until it is convinced that the patch
would apply cleanly.  One of the check it does is that when it
knows a path is going to be created by the patch, it runs
lstat() on the path to make sure it does not exist.

This leads to a false alarm.  Because we do not touch the
working tree before all the check passes, when we try to make
sure that arch/x86_64/boot/.gitignore does not exist yet, we
haven't removed the arch/x86_64/boot symlink.  The lstat() check
ends up seeing arch/i386/boot/.gitignore through the
yet-to-be-removed symlink, and says "Hey, you already have a
file there, but what you fed me is a patch to create a new
file. I am not going to clobber what you have in the working
tree."

We have similar checks to see a file we are going to modify does
exist and match the preimage of the diff, which is done by
directly opening and reading the file.

For a file we are going to delete, we make sure that it does
exist and matches what is going to be removed (a removal patch
records the full preimage, so we check what you have in your
working tree matches it in full -- otherwise we would risk
losing your local changes), which again is done by directly
opening and reading the file.

These checks need to be adjusted so that they are not fooled by
symlinks in the middle.

 - To make sure something does not exist, first lstat().  If it
   does not exist, it does not, so be happy.  If it _does_, we
   might be getting fooled by a symlink in the middle, so break
   leading paths and see if there are symlinks involved.  When
   we are checking for a path a/b/c/d, if any of a, a/b, a/b/c
   is a symlink, then a/b/c/d does _NOT_ exist, for the purpose
   of our test.

   This would fix this particular case you saw, and would not
   add extra overhead in the usual case.

 - To make sure something already exists, first lstat().  If it
   does not exist, barf (up to this, we already do).  Even if it
   does seem to exist, we might be getting fooled by a symlink
   in the middle, so make sure leading paths are not symlinks.

   This would make the normal codepath much more expensive for
   deep trees, which is a bit worrisome.

This patch implements the first side of the check "making sure
it does not exist".  The latter "making sure it exists" check is
not done yet, so applying the patch in reverse would still
fail, but we have to start from somewhere.

Signed-off-by: Junio C Hamano <junkio@cox.net>

Add has_symlink_leading_path() function.

When we are applying a patch that creates a blob at a path, or
when we are switching from a branch that does not have a blob at
the path to another branch that has one, we need to make sure
that there is nothing at the path in the working tree, as such a
file is a local modification made by the user that would be lost
by the operation.

Normally, lstat() on the path and making sure ENOENT is returned
is good enough for that purpose.  However there is a twist.  We
may be creating a regular file arch/x86_64/boot/Makefile, while
removing an existing symbolic link at arch/x86_64/boot that
points at existing ../i386/boot directory that has Makefile in
it.  We always first check without touching filesystem and then
perform the actual operation, so when we verify the new file,
arch/x86_64/boot/Makefile, does not exist, we haven't removed
the symbolic link arc/x86_64/boot symbolic link yet.  lstat() on
the file sees through the symbolic link and reports the file is
there, which is not what we want.

The function has_symlink_leading_path() function takes a path,
and sees if any of the leading directory component is a symbolic
link.

When files in a new directory are created, we tend to process
them together because both index and tree are sorted.  The
function takes advantage of this and allows the caller to cache
and reuse which symbolic link on the filesystem caused the
function to return true.

The calling sequence would be:

char last_symlink[PATH_MAX];

        *last_symlink = '\0';
        for each index entry {
if (!lose)
continue;
if (lstat(it))
if (errno == ENOENT)
; /* happy */
else
error;
else if (has_symlink_leading_path(it, last_symlink))
; /* happy */
else
error; /* would lose local changes */
unlink_entry(it, last_symlink);
}

Signed-off-by: Junio C Hamano <junkio@cox.net>

Minor copyediting on Release Notes for 1.5.2

Signed-off-by: Junio C Hamano <junkio@cox.net>

GIT v1.5.2-rc3

Signed-off-by: Junio C Hamano <junkio@cox.net>

Document 'git-log --decorate'

Signed-off-by: Michael Hendricks <michael@ndrix.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Correct error message in revert/cherry-pick

We now write to MERGE_MSG, not .msg.  I missed this earlier
when I changed the target we write to.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

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

* 'master' of git://repo.or.cz/git-gui:
  git gui 0.7.0
  git-gui: Paperbag fix blame in subdirectory
  git-gui: Format author/committer times in ISO format
  git-gui: Cleanup minor nits in blame code
  git-gui: Generate blame on uncommitted working tree file
  git-gui: Smarter command line parsing for browser, blame
  git-gui: Use prefix if blame is run in a subdirectory
  git-gui: Convert blame to the "class" way of doing things
  git-gui: Don't attempt to inline array reads in methods
  git-gui: Convert browser, console to "class" format
  git-gui: Define a simple class/method system
  git-gui: Allow shift-{k,j} to select a range of branches to merge
  git-gui: Call changes "Staged" and "Unstaged" in file list titles.

git gui 0.7.0

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

git-gui: Paperbag fix blame in subdirectory

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

Merge branch 'maint'

* maint:
  Fix documentation of tag in git-fast-import.txt
  Properly handle '0' filenames in import-tars

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

* 'maint' of git://repo.or.cz/git/fastimport:
  Fix documentation of tag in git-fast-import.txt
  Properly handle '0' filenames in import-tars

Fix documentation of tag in git-fast-import.txt

The tag command does not take a trailing LF.

Signed-off-by: Richard P. Curnow <rc@rc0.org.uk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'gfi-maint' into maint

* gfi-maint:
  Properly handle '0' filenames in import-tars

gitweb: Do not use absolute font sizes

Avoid specifying font sizes in pixels, since that is just pure evil.
Pointed out by Chris Riddoch.

Note that this is pretty much just a proposal; I didn't test if everything
fits perfectly right, but things seem to be pretty much okay. repo.or.cz
uses it now as a test drive - if you find any visual quirks, please point
them out, with a patch if possible since I'm total CSS noob and debugging
CSS is an extremely painful experience for me.

Note that this patch actually does change visual look of gitweb in Firefox
with my resolution and default settings - everything is bigger and I can't
explain the joy of actually seeing gitweb text that is in _readable_ size;
also, my horizontal screen real estate feels better used now. But judging
from the look of most modern webpages on the 'net, most people prefer
reading the web with strained eyes and/or a magnifying glass (I wonder what
species of scientists should look into this mystifying phenomenon) - so,
please tell us what you think.

Maybe we might want to get rid of absolute sizes other than font sizes in
the CSS file too in the long term.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Git.pm: config_boolean() -> config_bool()

This patch renames config_boolean() to config_bool() for consistency with
the commandline interface and because it is shorter but still obvious. ;-)
It also changes the return value from some obscure string to real Perl
boolean, allowing for clean user code.

Signed-off-by: Petr Baudis <pasky@suse.cz>

Merge branch 'maint'

* maint:
  .mailmap: add some aliases
  SPECIFYING RANGES typo fix: it it => it is
  git-clone: don't get fooled by $PWD
  Fix documentation of tag in git-fast-import.txt

.mailmap: add some aliases

SPECIFYING RANGES typo fix: it it => it is

Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-clone: don't get fooled by $PWD

If you have /home/me/git symlink pointing at /pub/git/mine,
trying to clone from /pub/git/his/ using relative path would not
work as expected:

$ cd /home/me
        $ cd git
        $ ls ../
        his    mine
        $ git clone -l -s -n ../his/stuff.git

This is because "cd ../his/stuff.git" done inside git-clone to
check if the repository is local is confused by $PWD, which is
set to /home/me, and tries to go to /home/his/stuff.git which is
different from /pub/git/his/stuff.git.

We could probably say "set -P" (or "cd -P") instead, if we know
the shell is POSIX, but the way the patch is coded is probably
more portable.

[jc: this is updated with Andy Whitcroft's improvements]

Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: choose appropriate view for file type if a= parameter missing

gitweb URLs use the a= parameter for the view to use on the given path, such
as "blob" or "tree".  Currently, if a gitweb URL omits the a= parameter,
gitweb just shows the top-level repository summary, regardless of the path
given.  gitweb could instead choose an appropriate view based on the file
type: blob for blobs (files), tree for trees (directories), and summary if
no path given (the URL included no f= parameter, or an empty f= parameter).

Apart from making gitweb more robust and supporting URL editing more easily,
this change would aid the creation of shortcuts to git repositories using
simple substitution, such as:
http://example.org/git/?p=path/to/repo.git;hb=HEAD;f=%s

With this patch, if given the hash through the h= parameter, or the hash
base (hb=) and a filename (f=), gitweb uses cat-file -t to automatically set
the a= parameter.

This feature was requested by Josh Triplett through
 http://bugs.debian.org/410465

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Added new git-gui library files to rpm spec

"make rpm" breaks without these files.

Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix documentation of tag in git-fast-import.txt

The tag command does not take a trailing LF.

Signed-off-by: Richard P. Curnow <rc@rc0.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

t9400: skip cvsserver test if Perl SQLite interface is unavailable

Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'fl/cvsserver'

* fl/cvsserver:
  cvsserver: Add test cases for git-cvsserver

Merge branch 'jc/diffopt'

* jc/diffopt:
  diff -S: release the image after looking for needle in it
  diff -M: release the preimage candidate blobs after rename detection.
  diff.c: do not use a separate "size cache".
  diff: release blobs after generating textual diff.

Merge branch 'jn/gitweb'

* jn/gitweb:
  gitweb: Show combined diff for merge commits in 'commit' view
  gitweb: Show combined diff for merge commits in 'commitdiff' view
  gitweb: Make it possible to use pre-parsed info in git_difftree_body
  gitweb: Add combined diff support to git_patchset_body
  gitweb: Add combined diff support to git_difftree_body
  gitweb: Add parsing of raw combined diff format to parse_difftree_raw_line

cvsserver: Add test cases for git-cvsserver

Use the :fork: access method to force cvs to
call "$CVS_SERVER server" even when accessing a local
repository.

Add a basic test for checkout and some tests for update.

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Update documentation links to point at 1.5.1.4

Signed-off-by: Junio C Hamano <junkio@cox.net>

Increase pack.depth default to 50

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Add pack.depth option to git-pack-objects.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use .git/MERGE_MSG in cherry-pick/revert

Rather than storing the temporary commit message data in .msg (in
the working tree) we now store the message data in .git/MERGE_MSG.

By storing the message in the .git/ directory we are sure we will
never have a collision with a user file, should a project actually
have a ".msg" file in their top level tree.  We also don't need to
worry about leaving this stale file behind during a `reset --hard`
and have it show up in the output of status.

We are using .git/MERGE_MSG here to store the temporary message as
it is an already established convention between git-merge, git-am
and git-rebase that git-commit will default the user's edit buffer
to the contents of .git/MERGE_MSG.  If the user is going to need
to resolve this commit or wants to edit the message on their own
prepping that file with the desired message "just works".

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'maint'

* maint:
  GIT v1.5.1.4
  Add howto files to rpm packages.
  wcwidth redeclaration
  user-manual: fix clone and fetch typos

GIT v1.5.1.4

Signed-off-by: Junio C Hamano <junkio@cox.net>

Add howto files to rpm packages.

RPM packages did not include howto files which causes broken
links in howto-index.html

Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-gui: Format author/committer times in ISO format

This is a simple change to match what gitk does when it shows
a commit; we format using ISO dates (yyyy-mm-dd HH:MM:SS).

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

git-gui: Cleanup minor nits in blame code

We can use [list ...] rather than "", especially when we are talking
about values as then they are properly escaped if necessary.  Small
nit, but probably not a huge deal as the only data being inlined here
is Tk paths.

Some of the lines in the parser code were longer than 80 characters
wide, and they actually were all the same value on the end part of
the line.  Rather than keeping the mess copied-and-pasted around we
can set the last argument into a local variable and reuse it many
times.

The commit display code was also rather difficult to read on an 80
character wide terminal, so I'm moving it all into a double quoted
string that is easier to read.

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

git-gui: Generate blame on uncommitted working tree file

If the user doesn't give us a revision parameter to our blame
subcommand then we can generate blame against the working tree
file by passing the file path off to blame with the --contents
argument.  In this case we cannot obtain the contents of the
file from the ODB; instead we must obtain the contents by
reading the working directory file as-is.

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

git-gui: Smarter command line parsing for browser, blame

The browser subcommand now optionally accepts a single revision
argument; if no revision argument is supplied then we use the
current branch as the tree to browse.  This is very common, so
its a nice option.

Our blame subcommand now tries to perform the same assumptions
as the command line git-blame; both the revision and the file
are optional.  We assume the argument is a filename if the file
exists in the working directory, otherwise we assume the argument
is a revision name.  A -- can be supplied between the two to force
parsing, or before the filename to force it to be a filename.

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

git-gui: Use prefix if blame is run in a subdirectory

I think it was Andy Parkins who pointed out that git gui blame HEAD f
does not work if f is in a subdirectory and we are currently running
git-gui within that subdirectory.  This is happening because we did
not take the user's prefix into account when we computed the file
path in the repository.

We now assume the prefix as returned by rev-parse --show-prefix is
valid and we use that during the command line blame subcommand when
we apply the parameters.

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

git-gui: Convert blame to the "class" way of doing things

Our blame viewer code has historically been a mess simply
because the data for multiple viewers was all crammed into
a single pair of Tcl arrays.  This made the code hard to
read and even harder to maintain.

Now that we have a slightly better way of tracking the data
for our "meta-widgets" we can make use of it here in the
blame viewer to cleanup the code and make it easier to work
with long term.

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

git-gui: Don't attempt to inline array reads in methods

If a variable reference to a field is to an array, and it is
the only reference to that field in that method we cannot make
it an inlined [set foo] call as the regexp was converting the
Tcl code wrong.  We were producing "[set foo](x)" for "$foo(x)",
and that isn't valid Tcl when foo is an array.  So we just punt
if the only occurance has a ( after it.

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

git-gui: Convert browser, console to "class" format

Now that we have a slightly easier method of working with per-widget
data we should make use of that technique in our browser and console
meta-widgets, as both have a decent amount of information that they
store on a per-widget basis and our current approach of handling
it is difficult to follow.

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

git-gui: Define a simple class/method system

As most of the git-gui interface is based upon "meta-widgets"
that need to carry around a good deal of state (e.g. console
windows, browser windows, blame viewer) we have a good deal
of messy code that tries to store this meta-widget state in
global arrays, where keys into the array are formed from a
union of a unique "object instance id" and the field name.

This is a simple class system for Tcl that allows us to
hide much of that mess by making Tcl do what it does best;
process strings to manipulate its own code during startup.

Each object instance is placed into its own namespace.  The
namespace is created when the object instance is created and
the namespace is destroyed when the object instance is removed
from the system.  Within that namespace we place variables for
each field within the class; these variables can themselves be
scalar values or full-blown Tcl arrays.

A simple class might be defined as:

  class map {
    field data
    field size 0

    constructor {} {
      return $this
    }
    method set {name value} {
      set data($name) $value
      incr size
    }
    method size {} {
      return $size
    } ifdeleted { return 0 }
  }

All fields must be declared before any constructors or methods.  This
allows our class to generate a list of the fields so it can properly
alter the definition of the constructor and method bodies prior to
passing them off to Tcl for definition with proc. A field may optionally
be given a default/initial value.  This can only be done for non-array
type fields.

Constructors are given full access to all fields of the class, so they
can initialize the data values.  The default values of fields (if any)
are set before the constructor runs, and the implicit local variable
$this is initialized to the instance identifier.

Methods are given access to fields they actually use in their body.
Every method has an implicit "this" argument inserted as its first
parameter; callers of methods must be sure they supply this value.

Some basic optimization tricks are performed (but not much).  We
try to only upvar (locally bind) fields that are accessed within a
method, but we err on the side of caution and may upvar more than
we need to.  If a variable is accessed only once within a method
and that access is by $foo (read) we avoid the upvar and instead
use [set foo] to obtain the value.  This is slightly faster as Tcl
does not need to lookup the variable twice.

We also offer some small syntatic sugar for interacting with Tk and
the fileevent callback system in Tcl.  If a field (say "foo") is used
as "@foo" we insert instead the true global variable name of that
variable into the body of the constructor or method.  This allows easy
binding to Tk textvariable options, e.g.:

  label $w.title -textvariable @title

Proper namespace callbacks can also be setup with the special cb proc
that is defined in each namespace.  [cb _foo a] will invoke the method
_foo in the current namespace, passing it $this as the first (implied)
parameter and a as the second parameter.  This makes it very simple to
connect an object instance to a -command option for a Tk widget or to
a fileevent readable or writable for a file channel.

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

git-gui: Allow shift-{k,j} to select a range of branches to merge

I found it useful to be able to use j/k (vi-like keys) to move
up and down the list of branches to merge and shift-j/k to do
the selection, much as shift-up/down (arrow keys) would alter
the selection.

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

Merge branch 'maint'

* maint:
  git-gui: Call changes "Staged" and "Unstaged" in file list titles.

git-gui: Call changes "Staged" and "Unstaged" in file list titles.

All menu entries talk about "staging" and "unstaging" changes, but the
titles of the file lists use different wording, which may confuse
newcomers.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

wcwidth redeclaration

Build fails for git 1.5.1.3 on AIX, with the message:

utf8.c:66: error: conflicting types for 'wcwidth'
/.../lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.3/include/string.h:266: error: previous declaration of 'wcwidth' was here

Fix this by renaming our static variant to our own name.

Signed-off-by: Amos Waterland <apw@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

user-manual: fix clone and fetch typos

More typo fixes from Santi Béjar, plus a couple other mistakes I noticed
along the way.

Cc: Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Remove duplicate exports from Makefile

We already export these variables earlier in the Makefile, right
after they were 'declared'.  There is no point in doing so again.

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

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

* 'master' of git://repo.or.cz/git-gui:
  git-gui: Use vi-like keys in merge dialog
  git-gui: Include commit id/subject in merge choices
  git-gui: Show all possible branches for merge
  git-gui: Move merge support into a namespace
  git-gui: Allow vi keys to scroll the diff/blame regions
  git-gui: Move console procs into their own namespace
  git-gui: Refactor into multiple files to save my sanity
  git-gui: Track our own embedded values and rebuild when they change
  git-gui: Refactor to use our git proc more often
  git-gui: Use option database defaults to set the font
  git-gui: Cleanup common font handling for font_ui
  git-gui: Correct line wrapping for too many branch message
  git-gui: Warn users before making an octopus merge
  git-gui: Include the subject in the status bar after commit

Also perform an evil merge change to update Git's main Makefile to
pass the proper options down into git-gui now that it depends on
reasonable values for 'sharedir' and 'TCL_PATH'.

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

git-gui: Use vi-like keys in merge dialog

Since we support vi-like keys for scrolling in other UI contexts
we can easily do so here too.  Tk's handy little `event generate'
makes this a lot easier than I thought it would be.  We may want
to go back and fix some of the other vi-like bindings to redirect
to the arrow and pageup/pagedown keys, rather than running the
view changes directly.

I've bound 'v' to visualize, as this is a somewhat common thing
to want to do in the merge dialog.  Control (or Command) Return
is also bound to start the merge, much as it is bound in the
main window to activate the commit.

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

git-gui: Include commit id/subject in merge choices

When merging branches using our local merge feature it can be
handy to know the first few digits of the commit the ref points
at as well as the short description of the branch name.

Unfortunately I'm unable to use three listboxes in a row, as Tcl
freaks out and refuses to let me have a selection in more than
one of them at any given point in time.  So instead we use a
fixed width font in the existing listbox and organize the data
into three columns.  Not nearly as nice looking, but users can
continue to use the listbox's features.

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

git-gui: Show all possible branches for merge

Johannes Sixt pointed out that git-gui was randomly selecting
which branch (or tag!) it will show in the merge dialog when
more than one ref points at the same commit.  This can be a
problem for the user if they want to merge a branch, but the
ref that git-gui selected to display was actually a tag that
points at the commit at the tip of that branch.  Since the
user is looking for the branch, and not the tag, its confusing
to not find it, and worse, merging the tag causes git-merge to
generate a different message than if the branch was selected.

While I am in here and am messing around I have changed the
for-each-ref usage to take advantage of its --tcl formatting,
and to fetch the subject line of the commit (or tag) we are
looking at.  This way we could present the subject line in the
UI to the user, given them an even better chance to select
the correct branch.

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

git-gui: Move merge support into a namespace

Like the console procs I have moved the code related to merge
support into their own namespace, so that they are isolated
from the rest of the world.

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

git-gui: Allow vi keys to scroll the diff/blame regions

Users who are used to vi and recent versions of gitk may want
to scroll the diff region using vi style keybindings.  Since
these aren't bound to anything else and that widget does not
accept focus for data input, we can easily support that too.

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

git-gui: Move console procs into their own namespace

To help modularize git-gui better I'm isolating the code and
variables required to handle our little console windows into
their own namespace.  This way we can say console::new rather
than new_console, and the hidden internal procs to create the
window and read data from our filehandle are off in their own
private little land, where most users don't see them.

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

git-gui: Refactor into multiple files to save my sanity

I'm finding it difficult to work with a 6,000+ line Tcl script
and not go insane while looking for a particular block of code.
Since most of the program is organized into different units of
functionality and not all users will need all units immediately
on startup we can improve things by splitting procs out into
multiple files and let auto_load handle things for us.

This should help not only to better organize the source, but
it may also improve startup times for some users as the Tcl
parser does not need to read as much script before it can show
the UI.  In many cases the user can avoid reading at least half
of git-gui now.

Unfortunately we now need a library directory in our runtime
location.  This is currently assumed to be $(sharedir)/git-gui/lib
and its expected that the Makefile invoker will setup some sort of
reasonable sharedir value for us, or let us assume its going to be
$(gitexecdir)/../share.

We now also require a tclsh (in TCL_PATH) to just run the Makefile,
as we use tclsh to generate the tclIndex for our lib directory.  I'm
hoping this is not an unncessary burden on end-users who are building
from source.

I haven't really made any functionality changes here, this is just a
huge migration of code from one file to many smaller files.  All of
the new changes are to setup the library path and install the library
files.

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

gitweb: Show combined diff for merge commits in 'commit' view

When commit shown is a merge commit (has more than one parent),
display combined difftree output (result of git-diff-tree -c).
Earlier (since commit 549ab4a30703012ff3a12b5455d319216805a8db)
difftree output (against first parent) was not printed for merges.

Examples of non-trivial merges:
  5bac4a671907604b5fb4e24ff682d5b0e8431931 (includes rename)
  addafaf92eeb86033da91323d0d3ad7a496dae83 (five parents)
  95f97567c1887d77f3a46b42d8622c76414d964d (evil merge)

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Show combined diff for merge commits in 'commitdiff' view

When 'commitdiff' action is requested without 'hp' (hash parent)
parameter, and commit given by 'h' (hash) parameter is merge commit,
show merge as combined diff.

Earlier for merge commits without 'hp' parameter diff to first parent
was shown.

Note that in compact combined (--cc) format 'uninteresting' hunks
omission mechanism can make that there is no patch corresponding to
line in raw format (difftree) output. That is why (at least for now)
we use --combined and not --cc format for showing commitdiff for merge
commits.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Make it possible to use pre-parsed info in git_difftree_body

Make it possible to use pre-parsed, or generated by hand, difftree
info in git_difftree_body, similarly to how was and is it done in
git_patchset_body.

Use just introduced feature in git_commitdiff to parse difftree info
(raw diff output) only once: difftree info is now parsed in
git_commitdiff directly, and parsed information is passed to both
git_difftree_body and git_patchset_body. (Till now only git_blobdiff
made use of git_patchset_body ability to use pre-parsed or hand
generated info.) Additionally this makes rename info for combined diff
with renames (or copies) calculated only once in git_difftree_body;
the $difftree is modified and git_patchset_body makes use of added
info.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Add combined diff support to git_patchset_body

Calling convention for combined diff similar to the one for
git_difftree_body subroutine: difftree info (first parameter) must be
result of calling git-diff-tree with -c/--cc option, and all parents
of a commit must be passed as last parameters. See also description in
  "gitweb: Add combined diff support to git_difftree_body"

This ability is not used yet.

Generating "src" file name for renames in combined diff was separated
into fill_from_file_info subroutine; git_difftree_body was modified to
use it. Currently git_difftree_body and git_patchset_body fills this
info separately.

The from-file line in two-line from-file/to-file header is not
hyperlinked: there can be more than one "from"/"src" file. This
differs from HTML output of ordinary (not combined) diff.

format_diff_line subroutine needs extra $from/$to parameters to format
combined diff patch line correctly.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Add combined diff support to git_difftree_body

You have to pass all parents as final parameters of git_difftree_body
subroutine; the number of parents of a diff must be equal to the
number derived from parsing git-diff-tree output, raw combined diff
for git_difftree_body to display combined diff correctly (but it is
not checked).

Currently the possibility of displaying diffree of combined diff is
not used in gitweb code; git_difftree_body is always caled for
ordinary diff, and with only one parent.

Description of output for combined diff:
----------------------------------------

The difftree table for combined diff starts with a cell with pathname
of changed blob (changed file), which if possible is hidden link
(class="list") to the 'blob' view of final version (if it exists),
like for difftree for ordinary diff. If file was deleted in the final
commit then filename is not hyperlinked.

There is no cell with single file status (new, deleted, mode change,
rename), as for combined diff as there is no single status: different
parents might have different status.

If git_difftree_body was called from git_commitdiff (for 'commitdiff'
action) there is inner link to anchor to appropriate fragment (patch)
in patchset body; the "patch" link does not replace "diff" link like
for ordinary diff.

Each of "diff" links is in separate cell, contrary to output for
ordinary diff in which all links are (at least for now) in a single
cell.

For each parent, if file was not present we leave cell empty. If file
was deleted in the result, we provide link to 'blob' view. Otherwise
we provide link to 'commitdiff' view, even if patch (diff) consist
only of extended diff header, and contents is not changed (pure
rename, pure mode change). The only difference is that link to
"blobdiff" view with no contents change is with 'nochange' class.

At last, there is provided link to current version of file as "blob"
link, if the file was not deleted in the result, and lik to history of
a file, if there exists one. (The link to file history might be
confused, at least for now, by renames.)

Note that git-diff-tree raw output dor combined diff does not provide
filename before change for renames and copies; we use
git_get_path_by_hash to get "src" filename for renames (this means
additional call to git-ls-tree for a _whole_ tree).

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Add parsing of raw combined diff format to parse_difftree_raw_line

Add parsing line of raw combined diff ("git diff-tree -c/-cc" output)
as described in section "diff format for merges" in diff-format.txt
to parse_difftree_raw_line subroutine.

Returned hash (or hashref) has for combined diff 'nparents' key which
holds number of parents in a merge. At keys 'from_mode' and 'from_id'
there are arrayrefs holding modes and ids, respectively. There is no
'similarity' value, and there is only 'to_file' value and no
'from_file' value.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>