diff --dirstat: saner handling of binary and unmerged files

We do not account binary nor unmerged files when --shortstat is
asked for (or the summary stat at the end of --stat).

The new option --dirstat should work the same way as it is about
summarizing the changes of multiple files by adding them up.

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

Add "--dirstat" for some directory statistics

This adds a new form of overview diffstat output, doing something that I
have occasionally ended up doing manually (and badly, because it's
actually pretty nasty to do), and that I think is very useful for an
project like the kernel that has a fairly deep and well-separated
directory structure with semantic meaning.

What I mean by that is that it's often interesting to see exactly which
sub-directories are impacted by a patch, and to what degree - even if you
don't perhaps care so much about the individual files themselves.

What makes the concept more interesting is that the "impact" is often
hierarchical: in the kernel, for example, something could either have a
very localized impact to "fs/ext3/" and then it's interesting to see that
such a patch changes mostly that subdirectory, but you could have another
patch that changes some generic VFS-layer issue which affects _many_
subdirectories that are all under "fs/", but none - or perhaps just a
couple of them - of the individual filesystems are interesting in
themselves.

So what commonly happens is that you may have big changes in a specific
sub-subdirectory, but still also significant separate changes to the
subdirectory leading up to that - maybe you have significant VFS-level
changes, but *also* changes under that VFS layer in the NFS-specific
directories, for example. In that case, you do want the low-level parts
that are significant to show up, but then the insignificant ones should
show up as under the more generic top-level directory.

This patch shows all of that with "--dirstat". The output can be either
something simple like

        commit 81772fe...
        Author: Thomas Gleixner <tglx@linutronix.de>
        Date:   Sun Feb 10 23:57:36 2008 +0100

            x86: remove over noisy debug printk

            pageattr-test.c contains a noisy debug printk that people reported.
            The condition under which it prints (randomly tapping into a mem_map[]
            hole and not being able to c_p_a() there) is valid behavior and not
            interesting to report.

            Remove it.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
         100.0% arch/x86/mm/

or something much more complex like

        commit e231c2e...
        Author: David Howells <dhowells@redhat.com>
        Date:   Thu Feb 7 00:15:26 2008 -0800

            Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)

  20.5% crypto/
   7.6% fs/afs/
   7.6% fs/fuse/
   7.6% fs/gfs2/
   5.1% fs/jffs2/
   5.1% fs/nfs/
   5.1% fs/nfsd/
   7.6% fs/reiserfs/
  15.3% fs/
   7.6% net/rxrpc/
  10.2% security/keys/

where that latter example is an example of significant work in some
individual fs/*/ subdirectories (like the patches to reiserfs accounting
for 7.6% of the whole), but then discounting those individual filesystems,
there's also 15.3% other "random" things that weren't worth reporting on
their oen left over under fs/ in general (either in that directory itself,
or in subdirectories of fs/ that didn't have enough changes to be reported
individually).

I'd like to stress that the "15.3% fs/" mentioned above is the stuff that
is under fs/ but that was _not_ significant enough to report on its own.
So the above does _not_ mean that 15.3% of the work was under fs/ per se,
because that 15.3% does *not* include the already-reported 7.6% of afs,
7.6% of fuse etc.

If you want to enable "cumulative" directory statistics, you can use the
"--cumulative" flag, which adds up percentages recursively even when
they have been already reported for a sub-directory.  That cumulative
output is disabled if *all* of the changes in one subdirectory come from
a deeper subdirectory, to avoid repeating subdirectories all the way to
the root.

For an example of the cumulative reporting, the above commit becomes

commit e231c2e...
Author: David Howells <dhowells@redhat.com>
Date:   Thu Feb 7 00:15:26 2008 -0800

    Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p)

  20.5% crypto/
   7.6% fs/afs/
   7.6% fs/fuse/
   7.6% fs/gfs2/
   5.1% fs/jffs2/
   5.1% fs/nfs/
   5.1% fs/nfsd/
   7.6% fs/reiserfs/
  61.5% fs/
   7.6% net/rxrpc/
  10.2% security/keys/

in which the commit percentages now obviously add up to much more than
100%: now the changes that were already reported for the sub-directories
under fs/ are then cumulatively included in the whole percentage of fs/
(ie now shows 61.5% as opposed to the 15.3% without the cumulative
reporting).

The default reporting limit has been arbitrarily set at 3%, which seems
to be a pretty good cut-off, but you can specify the cut-off manually by
giving it as an option parameter (eg "--dirstat=5" makes the cut-off be
at 5% instead)

NOTE! The percentages are purely about the total lines added and removed,
not anything smarter (or dumber) than that. Also note that you should not
generally expect things to add up to 100%: not only does it round down, we
don't report leftover scraps (they add up to the top-level change count,
but we don't even bother reporting that, it only reports subdirectories).

Quite frankly, as a top-level manager this is really convenient for me,
but it's going to be very boring for git itself since there are few
subdirectories. Also, don't expect things to make tons of sense if you
combine this with "-M" and there are cross-directory renames etc.

But even for git itself, you can get some fun statistics. Try out

        git log --dirstat

and see the occasional mentions of things like Documentation/, git-gui/,
gitweb/ and gitk-git/. Or try out something like

        git diff --dirstat v1.5.0..v1.5.4

which does kind of git an overview that shows *something*. But in general,
the output is more exciting for big projects with deeper structure, and
doing a

        git diff --dirstat v2.6.24..v2.6.25-rc1

on the kernel is what I actually wrote this for!

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

.mailmap: adjust to a recent patch application glitch.

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

Update the main documentation (stale notes section)

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

Merge branch 'db/no-separate-ls-remote-connection' (early part)

* 'db/no-separate-ls-remote-connection' (early part):
  Fix "git clone" for git:// protocol
  Reduce the number of connects when fetching

Merge branch 'mw/send-email'

* mw/send-email:
  git-send-email: Better handling of EOF
  git-send-email: SIG{TERM,INT} handlers
  git-send-email: ssh/login style password requests

Merge branch 'db/send-email-omit-cc'

* db/send-email-omit-cc:
  git-send-email: Generalize auto-cc recipient mechanism.

Merge branch 'jc/error-message-in-cherry-pick'

* jc/error-message-in-cherry-pick:
  Make error messages from cherry-pick/revert more sensible

Merge branch 'lt/in-core-index'

* lt/in-core-index:
  lazy index hashing
  Create pathname-based hash-table lookup into index
  read-cache.c: introduce is_racy_timestamp() helper
  read-cache.c: fix a couple more CE_REMOVE conversion
  Also use unpack_trees() in do_diff_cache()
  Make run_diff_index() use unpack_trees(), not read_tree()
  Avoid running lstat(2) on the same cache entry.
  index: be careful when handling long names
  Make on-disk index representation separate from in-core one

Merge branch 'ph/describe-match'

* ph/describe-match:
  git-name-rev: add a --(no-)undefined option.
  git-describe: Add a --match option to limit considered tags.

git-blame.el: show the when, who and what in the minibuffer.

Change the default operation to show 'when (day the commit was made),
who (who made the commit), what (what the commit log was)' in the
minibuffer instead of SHA1 and title of the commit log.

Since the user may prefer other displaying options, it is made as a
user-configurable option.

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

Define the project whitespace policy

This establishes what the "bad" whitespaces are for this
project.

The rules are:

 - Unless otherwise specified, indent with SP that could be
   replaced with HT are not "bad".  But SP before HT in the
   indent is "bad", and trailing whitespaces are "bad".

 - For C source files, initial indent by SP that can be replaced
   with HT is also "bad".

 - Test scripts in t/ and test vectors in its subdirectories can
   contain anything, so we make it unrestricted for now.

Anything "bad" will be shown in WHITESPACE error indicator in
diff output, and "apply --whitespace=warn" will warn about it.

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

Add `git svn blame' command

This command is identical to `git blame', but it shows SVN revision
numbers instead of git commit hashes.

[ew: support "^initial commit" and minor formatting fixes]

Signed-off-by: Tim Stoakes <tim@stoakes.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint: (35 commits)
  config.c: guard config parser from value=NULL
  builtin-log.c: guard config parser from value=NULL
  imap-send.c: guard config parser from value=NULL
  wt-status.c: guard config parser from value=NULL
  setup.c: guard config parser from value=NULL
  remote.c: guard config parser from value=NULL
  merge-recursive.c: guard config parser from value=NULL
  http.c: guard config parser from value=NULL
  help.c: guard config parser from value=NULL
  git.c: guard config parser from value=NULL
  diff.c: guard config parser from value=NULL
  convert.c: guard config parser from value=NULL
  connect.c: guard config parser from value=NULL
  builtin-tag.c: guard config parser from value=NULL
  builtin-show-branch.c: guard config parser from value=NULL
  builtin-reflog.c: guard config parser from value=NULL
  builtin-log.c: guard config parser from value=NULL
  builtin-config.c: guard config parser from value=NULL
  builtin-commit.c: guard config parser from value=NULL
  builtin-branch.c: guard config parser from value=NULL
  ...

config.c: guard config parser from value=NULL

user.{name,email}, core.{pager,editor,excludesfile,whitespace} and
i18n.{commit,logoutput}encoding all expect string values.

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

builtin-log.c: guard config parser from value=NULL

format.suffix expects a string value.  format.numbered is bool plus "auto"

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

imap-send.c: guard config parser from value=NULL

None of the configuration variables this expects is boolean.

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

wt-status.c: guard config parser from value=NULL

status.color.* and color.status.* expect a string value

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

setup.c: guard config parser from value=NULL

core.worktree expects a string value

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

remote.c: guard config parser from value=NULL

branch.*.{remote,merge} expect a string value

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

merge-recursive.c: guard config parser from value=NULL

merge.default, merge.*.{name,driver} expect a string value

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

http.c: guard config parser from value=NULL

http.sslcert and friends expect a string value

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

help.c: guard config parser from value=NULL

help.format configuration expects a string value

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

git.c: guard config parser from value=NULL

alias.* configuration expects a string value

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

diff.c: guard config parser from value=NULL

diff.external, diff.*.command, diff.color.*, color.diff.* and
diff.*.funcname configuration variables expect a string value.

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

convert.c: guard config parser from value=NULL

filter.*.smudge and filter.*.clean configuration variables expect a
string value.

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

connect.c: guard config parser from value=NULL

core.gitproxy configuration expects a string value.

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

builtin-tag.c: guard config parser from value=NULL

user.signingkey configuration expects a string value.

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

builtin-show-branch.c: guard config parser from value=NULL

showbranch.default configuration expects a string value.

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

builtin-reflog.c: guard config parser from value=NULL

gc.reflogexpire and gc.reflogexpireunreachable configuration expect
 a string value suitable for calling approxidate() with.

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

builtin-log.c: guard config parser from value=NULL

format.subjectprefix configuration expects a string value.

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

builtin-config.c: guard config parser from value=NULL

color configuration variables expect a string value.

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

builtin-commit.c: guard config parser from value=NULL

commit.template configuration expects a string value.

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

builtin-branch.c: guard config parser from value=NULL

color.branch.* configuration variables expect a string value.

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

builtin-apply.c: guard config parser from value=NULL

apply.whitespace configuration expects a string value.

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

Add config_error_nonbool() helper function

This is used to report misconfigured configuration file that does not
give any value to a non-boolean variable, e.g.

[section]
var

It is perfectly fine to say it if the section.var is a boolean (it means
true), but if a variable expects a string value it should be flagged as
a configuration error.

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

builtin-gc.c: guard config parser from value=NULL

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

archive-tar.c: guard config parser from value=NULL

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

Work around curl-gnutls not liking to be reinitialized

curl versions 7.16.3 to 7.18.0 included had a regression in which https
requests following curl_global_cleanup/init sequence would fail with ASN1
parser errors with curl-gnutls. Such sequences happen in some cases such
as git fetch.

We work around this by removing the http_init and http_cleanup calls from
get_refs_via_curl, replacing them with a transport->data initialization
with the http_walker (which does http_init).

While the http_walker is not currently used in get_refs_via_curl, http
and walker code refactor will make it use it.

Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

man pages are littered with .ft C and others

Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458
> Julian Phillips:
> > Are you using docbook xsl 1.72?  There are known problems building the
> > manpages with that version.  1.71 works, and 1.73 should work when it get
> > released.

I was able to solve this problem with this patch, which adds a XSL file
used specifically for DOCBOOK_XSL_172=YesPlease and where dots and
backslashes are escaped properly so they won't be substituted to the
wrong thing further down the "DocBook XSL pipeline". Doing the escaping
in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end
this part of the manpage nightmare.

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

Add a BuildRequires for gettext in the spec file.

Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack-objects: only throw away data during memory pressure

If pack-objects hit the memory limit, it deletes objects from the delta
window.

This patch make it only delete the data, which is recomputed, if needed again.

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin-commit: remove .git/SQUASH_MSG upon successful commit

After doing a merge --squash, and commit afterwards, the commit message
template SQUASH_MSG in the git directory is not removed, which means that
the content of SQUASH_MSG is used as default commit message for all
subsequent commits.  So have git commit remove the file SQUASH_MSG from
the git directory upon a successful commit.

The problem was discovered by Frédéric Brière, reported through
 http://bugs.debian.org/464656

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

Make git prune remove temporary packs that look like write failures

Write errors when repacking (eg, due to out-of-space conditions)
can leave temporary packs (and possibly other files beginning
with "tmp_") lying around which no existing
codepath removes and which aren't obvious to the casual user.
These can also be multi-megabyte files wasting noticeable space.
Unfortunately there's no way to definitely tell in builtin-prune
that a tmp_ file is not being used by a concurrent process,
such as a fetch. However, it is documented that pruning should
only be done on a quiet repository and --expire is honoured
(using code from Johannes Schindelin, along with a test case
he wrote) so that its safety is the same as that of loose
object pruning.

Since they might be signs of a problem (unlike orphaned loose
objects) the names of any removed files are printed.

Signed-off-by: David Tweed (david.tweed@gmail.com)
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase -i: accept -m as advertised in the man page

Signed-off-by: Uwe Kleine-K\e,Av\e(Bnig <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Document that the default of branch.autosetupmerge is true

In 34a3e69 (git-branch: default to --track) the default was changed to
true, to help new git users.  But yours truly forgot to update the
documentation.  This fixes it.

Noticed by Kalle Olavi Niemitalo.

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

bisect: allow starting with a detached HEAD

Instead of insisting on a symbolic ref, bisect now accepts detached
HEADs, too.

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

git-pull documentation: fix markup

A note paragraph was mistakenly made into an indented monospace display.
Noticed by Miklos Vajna.

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

config: Fix --unset for continuation lines

find_beginning_of_line didn't take into account that the
previous line might have ended with \ in which case it shouldn't
stop but continue its search.

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

Merge branch 'maint'

* maint:
  Fix typo in 'blame' documentation.

Work around curl-gnutls not liking to be reinitialized

curl versions 7.16.3 to 7.18.0 included had a regression in which https
requests following curl_global_cleanup/init sequence would fail with ASN1
parser errors with curl-gnutls. Such sequences happen in some cases such
as git fetch.

We work around this by removing the http_init and http_cleanup calls from
get_refs_via_curl, replacing them with a transport->data initialization
with the http_walker (which does http_init).

While the http_walker is not currently used in get_refs_via_curl, http
and walker code refactor will make it use it.

Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Introduce the config variable pack.packSizeLimit

"git pack-objects" has the option --max-pack-size to limit the file
size of the packs to a certain amount of bytes.  On platforms where
the pack file size is limited by filesystem constraints, it is easy
to forget this option, and this option does not exist for "git gc"
to begin with.

So introduce a config variable to set the default maximum, but make
this overrideable by the command line.

Suggested by Tor Arvid Lund.

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

Fix typo in 'blame' documentation.

Signed-off-by: Tim Stoakes <tim@stoakes.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix "git clone" for git:// protocol

In ba227857(Reduce the number of connects when fetching), we checked
the return value of git_connect() to see if the connection was
successful.

However, for the git:// protocol, there is no need to have another
process, so the return value was NULL.

Now, it makes sense to assume the rule that git_connect() will return
NULL if it fails (at the moment, it die()s if it fails), so return
a dummy child process.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Make use of the $git_dir variable at sub git_get_project_url_list

Signed-off-by: Bruno Ribas <ribas@c3sl.ufpr.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.el: Better handling of subprocess errors.

Where possible, capture the output of the git command and display it
if the command fails.

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

git.el: Check for existing buffers on revert.

Refuse to revert a file if it is modified in an existing buffer but
not saved. On success, revert the buffers that contains the files that
have been reverted.

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

git.el: Added a command to amend a commit.

It reverts the commit and sets up the status and edit log buffer to
allow making changes and recommitting it. Bound to C-c C-a.

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

git.el: Support for showing unknown/ignored directories.

Instead of recursing into directories that only contain unknown files,
display only the directory itself. Its contents can be expanded with
git-find-file (bound to C-m).

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

git-p4: Fix indentation from tab to spaces

Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>

Merge branch 'maint'

* maint:
  gitattributes: fix relative path matching

gitattributes: fix relative path matching

There was an embarrassing pair of off-by-one miscounting that
failed to match path "a/b/c" when "a/.gitattributes" tried to
name it with relative path "b/c".

This fixes it.

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

config: add test cases for empty value and no value config variables.

The tests in 't1300-repo-config.sh' did not check what happens when
an empty value like the following is used in the config file:

[emptyvalue]
variable =

Also it was not checked that a variable with no value like the
following:

[novalue]
variable

gives a boolean "true" value, while an ampty value gives a boolean
"false" value.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Improve bash prompt to detect various states like an unfinished merge

This patch makes the git prompt (when enabled) show if a merge or a
rebase is unfinished. It also detects if a bisect is being done as
well as detached checkouts.

An uncompleted git-am cannot be distinguised from a rebase (the
non-interactive version). Instead of having an even longer prompt
we simply ignore that and hope the power users that use git-am knows
the difference.

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'maint'

* maint:
  Fix parsing numeric color values
  INSTALL: git-merge no longer uses cpio

Fix parsing numeric color values

Numeric color only worked if it was at end of line.
Noticed by Chris Larson <clarson@kergoth.com>.

Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Make feed entries point to commitdiff view

Change feeds entries (feeds items) from pointing (linking) to 'commit'
view to pointing to 'commitdiff' view.

First, feed entries have whatchanged-like list of files which were
modified in a commit, so 'commitdiff' view more naturally reflects
feed entry (is more naturally alternate / extended version of a feed
item). Second, this way the patches are shown directly and code review
is done more easily via watching feeds.

[jn: Rewritten commit message]

Signed-off-by: Florian La Roche <laroche@redhat.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: improve repository URL matching when following parents

This way we can avoid the spawning of a new SVN::Ra session by
reusing the existing one.

The most problematic issue is that some svn servers disallow
too many connections from a single IP, so this will allow
git-svn to fetch from those repositories with a higher success
rate by using fewer connections.

This sometimes showed up as a new (and redundant)
[svn-remote "$parent_refname"] entry in $GIT_DIR/svn/.metadata.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Make git-remote.perl "use strict" compliant

I was looking at some of the perl commands, and noticed that
git-remote was the only one to lack a 'use strict' pragma at the top,
which could be a good thing for its maintainability. Hopefully, the
required changes are minimal.

Signed-off-by: Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

INSTALL: git-merge no longer uses cpio

Since a64d7784e830b3140e7d0f2b45cb3d8fafb84cca git merge doesn't use cpio
anymore, adapt the documentation.

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

Fix misuse of prefix_path()

When DEFAULT_GIT_TEMPLATE_DIR is specified as a relative path,
init-db made it relative to exec_path using prefix_path(), which
is wrong.  prefix_path() is about a file inside the work tree.
There was a similar misuse in config.c that takes relative
ETC_GITCONFIG path. Noticed by Junio C Hamano.

We concatenate the paths manually. (prefix_filename() won't do
because it expects a prefix with a trailing '/'.)

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

git-send-email: Generalize auto-cc recipient mechanism.

There are a few options to git-send-email to suppress the automatic
generation of 'Cc' fields: --suppress-from, and --signed-off-cc.
However, there are other times that git-send-email automatically
includes Cc'd recipients.  This is not desirable for all development
environments.

Add a new option --suppress-cc, which can be specified one or more
times to list the categories of auto-cc fields that should be
suppressed.  If not specified, it defaults to values to give the same
behavior as specified by --suppress-from, and --signed-off-cc.  The
categories are:

  self   - patch sender.  Same as --suppress-from.
  author - patch author.
  cc     - cc lines mentioned in the patch.
  cccmd  - avoid running the cccmd.
  sob    - signed off by lines.
  all    - all non-explicit recipients

Signed-off-by: David Brown <git@davidb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Reduce the number of connects when fetching

This shares the connection between getting the remote ref list and
getting objects in the first batch. (A second connection is still used
to follow tags).

When we do not fetch objects (i.e. either ls-remote disconnects after
getting list of refs, or we decide we are already up-to-date), we
clean up the connection properly; otherwise the connection is left
open in need of cleaning up to avoid getting an error message from
the remote end when ssh is used.

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

Make error messages from cherry-pick/revert more sensible

The original "rewrite in C" did somewhat a sloppy job while
stealing code from git-write-tree.

The caller pretends as if the write_tree() function would return
an error code and being able to issue a sensible error message
itself, but write_tree() function just calls die() and never
returns an error.  Worse yet, the function claims that it was
running git-write-tree (which is no longer true after
cherry-pick stole it).

Tested-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-send-email: Better handling of EOF

Before, when the user sent the EOF control character, the
prompts would be repeated on the same line as the previous
prompt.

Now, repeat prompts display on separate lines.

Signed-off-by: Michael Witten <mfwitten@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-send-email: SIG{TERM,INT} handlers

A single signal handler is used for both SIGTERM and
SIGINT in order to clean up after an uncouth termination
of git-send-email.

In particular, the handler resets the text color (this cleanup
was already present), turns on tty echoing (in case termination
occurrs during a masked Password prompt), and informs the user
of of any temporary files created by --compose.

Signed-off-by: Michael Witten <mfwitten@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-send-email: ssh/login style password requests

Whilst convenient, it is most unwise to record passwords
in any place but one's brain. Moreover, it is especially
foolish to store them in configuration files, even with
access permissions set accordingly.

git-send-email has been amended, so that if it detects
an smtp username without a password, it promptly prompts
for the password and masks the input for privacy.

Furthermore, the argument to --smtp-pass has been rendered
optional.

The documentation has been updated to reflect these changes.

Signed-off-by: Michael Witten <mfwitten@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

man pages are littered with .ft C and others

Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458
> Julian Phillips:
> > Are you using docbook xsl 1.72?  There are known problems building the
> > manpages with that version.  1.71 works, and 1.73 should work when it get
> > released.

I was able to solve this problem with this patch, which adds a XSL file
used specifically for DOCBOOK_XSL_172=YesPlease and where dots and
backslashes are escaped properly so they won't be substituted to the
wrong thing further down the "DocBook XSL pipeline". Doing the escaping
in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end
this part of the manpage nightmare.

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

Add a BuildRequires for gettext in the spec file.

Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Test :/string form for checkout

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

fix misuse of prefix_path()

When DEFAULT_GIT_TEMPLATE_DIR is specified as a relative path,
init-db made it relative to exec_path using prefix_path(), which
is wrong.  prefix_path() is about a file inside the work tree.
There was a similar misuse in config.c that takes relative
ETC_GITCONFIG path.

A convenience function prefix_filename() can concatenate two paths
to form a path that points at somewhere outside the work tree.
Use it in these codepaths instead.

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

parse_object_buffer: don't ignore errors from the object specific parsing functions

In the case of an malformed object, the object specific parsing functions
would return an error, which is currently ignored. The object can be partial
initialized in this case.

This patch make parse_object_buffer propagate such errors.

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-fsck: report missing author/commit line in a commit as an error

A zero commit date could be caused by:
* a missing author line
* a missing commiter line
* a malformed email address in the commiter line
* a malformed commit date

Simply reporting it as zero commit date is missleading.

Additionally, it upgrades the message to an error (instead of an printf).

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  git-remote documentation: fix synopsis to match description
  git-am: fix type in its usage string

git-remote documentation: fix synopsis to match description

In the text, the argument of -m is <master> which should be used in the
command synopsis, too.

Signed-off-by: Jörg Sommer <joerg@alea.gnuu.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-am: fix type in its usage string

Signed-off-by: Jörg Sommer <joerg@alea.gnuu.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: Fix an obvious typo

The regexp "$," can't match anything. Clearly not intended.

This was introduced in ce6f33c8 which is quite a while ago.

Signed-off-by: Tommy Thorn <tommy-git@thorn.ws>
Acked-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Let "git svn" run "git gc --auto" occasionally

Let "git svn" run "git gc --auto" every 1000 imported commits to
reduce the number of loose objects.

To handle the common use case of frequent imports, where each
invocation typically fetches much less than 1000 commits, also run gc
unconditionally at the end of the import.

"1000" is the same number that was used by default when we called
git-repack. It isn't necessarily still the best choice.

Signed-off-by: Karl Hasselström <kha@treskal.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: Don't call git-repack anymore

In a moment, we'll start calling git-gc --auto instead, since it is a
better fit to what we're trying to accomplish.

The command line options are still accepted, but don't have any
effect, and we warn the user about that.

Signed-off-by: Karl Hasselström <kha@treskal.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: Ensure the working directory and the index are clean before "git-p4 rebase"

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

git-p4: Fix submit user-interface.

Don't ask any questions when submitting, behave similar to git-svn dcommit.

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

Remove $Id: ..$ $Header: ..$ etc from +ko and +k files during import

This patch removes the '$Keyword: ...$' '...' data, so that files
don't have spurious megre conflicts between branches.

Handles both +ko and +k styles, and leaves the '$Foo$' in
the original file.

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

Merge branch 'maint'

* maint:
  Fix "git-commit -C $tag"
  Documentation/git-stash.txt: Adjust SYNOPSIS command syntax (2)

Fix "git-commit -C $tag"

The scripted version might not have handled this correctly
either, but the version rewritten in C definitely does not grok
this and complains $tag is not a commit object.

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

Documentation/git-stash.txt: Adjust SYNOPSIS command syntax (2)

Adjust the command syntax to better reflect the call parameters:
[save] [message...] => [save [<message>]].

Signed-off-by: Jari Aalto <jari.aalto AT cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

known breakage: revision range computation with clock skew

This is the absolute minimum (and reliable) reproduction recipe
to demonstrate that revision range in a history with clock skew
sometimes fails to mark UNINTERESTING commit in topologically
early parts of the history.

The history looks like this:

o---o---o---o
one         four

but one has the largest timestamp.  "git rev-list four..one"
fails to notice that "one" should not be emitted.

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

test: reword the final message of tests with known breakages

When we have known breakages, we still said "passed all N
test(s)", which was a bit funny.

This rewords it to read "passed all remaining N test(s)" in such
a case.

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

Sane use of test_expect_failure

Originally, test_expect_failure was designed to be the opposite
of test_expect_success, but this was a bad decision.  Most tests
run a series of commands that leads to the single command that
needs to be tested, like this:

    test_expect_{success,failure} 'test title' '
setup1 &&
        setup2 &&
        setup3 &&
        what is to be tested
    '

And expecting a failure exit from the whole sequence misses the
point of writing tests.  Your setup$N that are supposed to
succeed may have failed without even reaching what you are
trying to test.  The only valid use of test_expect_failure is to
check a trivial single command that is expected to fail, which
is a minority in tests of Porcelain-ish commands.

This large-ish patch rewrites all uses of test_expect_failure to
use test_expect_success and rewrites the condition of what is
tested, like this:

    test_expect_success 'test title' '
setup1 &&
        setup2 &&
        setup3 &&
        ! this command should fail
    '

test_expect_failure is redefined to serve as a reminder that
that test *should* succeed but due to a known breakage in git it
currently does not pass.  So if git-foo command should create a
file 'bar' but you discovered a bug that it doesn't, you can
write a test like this:

    test_expect_failure 'git-foo should create bar' '
        rm -f bar &&
        git foo &&
        test -f bar
    '

This construct acts similar to test_expect_success, but instead
of reporting "ok/FAIL" like test_expect_success does, the
outcome is reported as "FIXED/still broken".

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

Update stale documentation links from the main documentation.

This could have been part of the 1.5.4 commit, but it isn't.

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

GIT 1.5.4

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