tokkee.org

gitweb: Handle non UTF-8 text better

gitweb assumes that everything is in UTF-8. If a text contains invalid
UTF-8 character sequences, the text must be in a different encoding.

This commit introduces $fallback_encoding which would be used as input
encoding if gitweb encounters text with is not valid UTF-8.

Add basic test for this in t/t9500-gitweb-standalone-no-errors.sh

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Tested-by: Alexandre Julliard <julliard@winehq.org>
Tested-by: Ismail Dönmez <ismail@pardus.org.tr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add test-sha1 to .gitignore.

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

git-apply: what is detected and fixed is not just trailing spaces.

But we kept saying "trailing whitespace" all the same.  Reword the
error messages a bit.

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

Update to SubmittingPatches

Make people aware of our testsuite, and of non-ASCII encodings.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'maint' to sync with 1.5.2.1

Release Notes: start preparing for 1.5.3

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

Merge branches 'lh/submodules' and 'pb/am'

* lh/submodules:
  Add basic test-script for git-submodule
  Add git-submodule command

* pb/am:
  Remove git-applypatch
  git-applymbox: Remove command

GIT 1.5.2.1

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

Add basic test-script for git-submodule

This test tries to verify basic sanity of git-submodule, i.e. that it is
able to clone and update a submodule repository, that its status output is
sane, and that it barfs when the submodule path is occupied during init.

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

Merge branch 'np/pack'

* np/pack:
  fix repack with --max-pack-size
  builtin-pack-object: cache small deltas
  git-pack-objects: cache small deltas between big objects
  builtin-pack-objects: don't fail, if delta is not possible

Merge branch 'sp/pack'

* sp/pack:
  Style nit - don't put space after function names
  Ensure the pack index is opened before access
  Simplify index access condition in count-objects, pack-redundant
  Test for recent rev-parse $abbrev_sha1 regression
  rev-parse: Identify short sha1 sums correctly.
  Attempt to delay prepare_alt_odb during get_sha1
  Micro-optimize prepare_alt_odb
  Lazily open pack index files on demand

git-rebase: suggest to use git-add instead of git-update-index

The command is part of the main porcelain making git-add more
appropriate.

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'maint'

* maint:
  Use =20 when rfc2047 encoding spaces.
  Create a new manpage for the gitignore format, and reference it elsewhere
  Documentation: robustify asciidoc GIT_VERSION replacement

Use =20 when rfc2047 encoding spaces.

Encode ' ' using '=20' even though rfc2047 allows using '_' for
readability.  Unfortunately, many programs do not understand this and
just leave the underscore in place.  Using '=20' seems to work better.

[jc: with adjustment to t3901]

Signed-off-by: Kristian Høgsberg <hoegsberg@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Create a new manpage for the gitignore format, and reference it elsewhere

Only git-ls-files(1) describes the gitignore format in detail, and it does so
with reference to git-ls-files options.  Most users don't use the plumbing
command git-ls-files directly, and shouldn't have to look in its manpage for
information on the gitignore format.

Create a new manpage gitignore(5) (Documentation/gitignore.txt), and factor
out the gitignore documentation into that file, changing it to refer to
.gitignore and $GIT_DIR/info/exclude as used by porcelain commands.  Reference
gitignore(5) from other relevant manpages and documentation.  Remove
now-redundant information on exclude patterns from git-ls-files(1), leaving
only information on how git-ls-files options specify exclude patterns and what
precedence they have.

Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: robustify asciidoc GIT_VERSION replacement

Instead of using sed on the resulting file, we now have a
git_version asciidoc attribute. This means that we don't
pipe the output of asciidoc, which means we can detect build
failures.

Problem reported by Scott Lamb, solution suggested by Jonas Fonseca.

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

Fix git-am(1) synopsis formatting

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix minor grammatical typos in the git-gc man page

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

diff-delta: use realloc instead of xrealloc

Commit 83572c1a914d3f7a8dd66d954c11bbc665b7b923 changed many
realloc to xrealloc. This change was made in diff-delta.c too,
although the code can handle an out of memory failure.

This patch reverts this change in diff-delta.c.

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'maint'

* maint:
  git-config: Improve documentation of git-config file handling
  git-config: Various small fixes to asciidoc documentation
  decode_85(): fix missing return.
  fix signed range problems with hex conversions

Merge branch 'maint-1.5.1' into maint

* maint-1.5.1:
  git-config: Improve documentation of git-config file handling
  git-config: Various small fixes to asciidoc documentation
  decode_85(): fix missing return.
  fix signed range problems with hex conversions

git-config: Improve documentation of git-config file handling

The description which files git-config uses and how the various
command line options and environment variables affect its
behaviour was incomplete, outdated and confusing.

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

git-config: Various small fixes to asciidoc documentation

Add '' around the only mentioned commandline option that didn't
have it.

Make reference to section EXAMPLE a link and rename it to
EXAMPLES because it actually contains a lot of examples.

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

always start looking up objects in the last used pack first

Jon Smirl said:

| Once an object reference hits a pack file it is very likely that
| following references will hit the same pack file. So first place to
| look for an object is the same place the previous object was found.

This is indeed a good heuristic so here it is.  The search always start
with the pack where the last object lookup succeeded.  If the wanted
object is not available there then the search continues with the normal
pack ordering.

To test this I split the Linux repository into 66 packs and performed a
"time git-rev-list --objects --all > /dev/null".  Best results are as
follows:

Pack Sort w/o this patch w/ this patch
-------------------------------------------------------------
recent objects last 26.4s 20.9s
recent objects first 24.9s 18.4s

This shows that the pack order based on object age has some influence,
but that the last-used-pack heuristic is even more significant in
reducing object lookup.

Signed-off-by: Nicolas Pitre <nico@cam.org> --- Note: the
--max-pack-size to git-repack currently produces packs with old objects
after those containing recent objects.  The pack sort based on
filesystem timestamp is therefore backward for those.  This needs to be
fixed of course, but at least it made me think about this variable for
the test.
Signed-off-by: Junio C Hamano <junkio@cox.net>

fix repack with --max-pack-size

Two issues here:

1) git-repack -a --max-pack-size=10 on the GIT repo dies pretty quick.
   There is a lot of confusion about deltas that were suposed to be
   reused from another pack but that get stored undeltified due to pack
   limit and object size doesn't match entry->size anymore.  This test
   is not really worth the complexity for determining when it is valid
   so get rid of it.

2) If pack limit is reached, the object buffer is freed, including when
   it comes from a cached delta data.  In practice the object will be
   stored in a subsequent pack undeltified, but let's make sure no
   pointer to freed data subsists by clearing entry->delta_data.

I also reorganized that code a bit to make it more readable.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Makefile: Use generic rule to build test programs

Use a generic make rule to build all the test programs, rather than
specifically mentioning each one.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

decode_85(): fix missing return.

When the function detected an invalid base85 sequence, it issued
an error message but forgot to return error status at that point
and kept going.

Signed-off-by: Jerald Fitzjerald <jfj@freemail.gr>
Signed-off-by: Junio C Hamano <junkio@cox.net>

fix signed range problems with hex conversions

Make hexval_table[] "const".  Also make sure that the accessor
function hexval() does not access the table with out-of-range
values by declaring its parameter "unsigned char", instead of
"unsigned int".

With this, gcc can just generate:

movzbl  (%rdi), %eax
movsbl  hexval_table(%rax),%edx
movzbl  1(%rdi), %eax
movsbl  hexval_table(%rax),%eax
sall    $4, %edx
orl     %eax, %edx

for the code to generate a byte from two hex characters.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Add DLH to .mailmap

... and make the entries sorted.

Style nit - don't put space after function names

Our style is to not put a space after a function name.  I did here,
and Junio applied the patch with the incorrect formatting.  So I'm
cleaning up after myself since I noticed it upon review.

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

Ensure the pack index is opened before access

In this particular location of fsck the index should have already
been opened by verify_pack, which is called just before we get
here and loop through the object names.  However, just in case a
future version of that function does not use the index file we'll
double-check its open before we access the num_objects field.

Better safe now than sorry later.

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

Simplify index access condition in count-objects, pack-redundant

My earlier lazy index opening patch changed this condition to check
index_data and call open_pack_index if it was NULL. In truth we only
care about num_objects.  Since open_pack_index does no harm if the
index is already open, and all indexes are likely to be closed in
this application, the "performance optimization" of inlining the
index_data check here was wrong.

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

Test for recent rev-parse $abbrev_sha1 regression

My recent patch "Lazily open pack index files on demand" caused a
regression in the case of parsing abbreviated SHA-1 object names.
Git was unable to translate the abbreviated name into the full name
if the object was packed, as the pack .idx files were not opened
before being accessed.

This is a simple test to repack a repository then test for an
abbreviated SHA-1 within the packfile.

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

rev-parse: Identify short sha1 sums correctly.

find_short_packed_object was not loading the pack index files.
Teach it to do so.

Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

builtin-pack-object: cache small deltas

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-pack-objects: cache small deltas between big objects

Creating deltas between big blobs is a CPU and memory intensive task.
In the writing phase, all (not reused) deltas are redone.

This patch adds support for caching deltas from the deltifing phase, so
that that the writing phase is faster.

The caching is limited to small deltas to avoid increasing memory usage very much.
The implemented limit is (memory needed to create the delta)/1024.

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>

builtin-pack-objects: don't fail, if delta is not possible

If builtin-pack-objects runs out of memory while finding
the best deltas, it bails out with an error.

If the delta index creation fails (because there is not enough memory),
we can downgrade the error message to a warning and continue with the
next object.

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'db/remote'

* db/remote:
  Move refspec pattern matching to match_refs().
  Update local tracking refs when pushing
  Add handlers for fetch-side configuration of remotes.
  Move refspec parser from connect.c and cache.h to remote.{c,h}
  Move remote parsing into a library file out of builtin-push.

Merge branch 'dh/repack' (early part)

* 'dh/repack' (early part):
  Ensure git-repack -a -d --max-pack-size=N deletes correct packs
  pack-objects: clarification & option checks for --max-pack-size
  git-repack --max-pack-size: add option parsing to enable feature
  git-repack --max-pack-size: split packs as asked by write_{object,one}()
  git-repack --max-pack-size: write_{object,one}() respect pack limit
  git-repack --max-pack-size: new file statics and code restructuring
  Alter sha1close() 3rd argument to request flush only

Merge branch 'np/delta'

* np/delta:
  update diff-delta.c copyright
  improve delta long block matching with big files

Merge branch 'jc/nodelta'

* jc/nodelta:
  builtin-pack-objects: remove unnecessary code for no-delta
  Teach "delta" attribute to pack-objects.
  pack-objects: pass fullname down to add_object_entry()

Merge branch 'ar/verbose'

* ar/verbose:
  Add another verbosity level to git-fetch
  Verbose connect messages to show the IP addresses used

Merge branch 'ar/run'

* ar/run:
  Allow environment variables to be unset in the processes started by run_command
  Add ability to specify environment extension to run_command
  Add run_command_v_opt_cd: chdir into a directory before exec

Merge branch 'ar/mergestat'

* ar/mergestat:
  Add a configuration option to control diffstat after merge

Merge branch 'rr/cvsexport'

* rr/cvsexport:
  Add option to cvs update before export

Merge branch 'maint'

* maint:
  cvsserver: Fix some typos in asciidoc documentation
  cvsserver: Note that CVS_SERVER can also be specified as method variable
  cvsserver: Correct inetd.conf example in asciidoc documentation
  user-manual: fixed typo in example
  Add test case for $Id$ expanded in the repository
  git-svn: avoid md5 calculation entirely if SVN doesn't provide one
  Makefile: Remove git-fsck and git-verify-pack from PROGRAMS
  Fix stupid typo in lookup_tag()
  git-gui: Guess our share/git-gui/lib path at runtime if possible
  Correct key bindings to Control-<foo>
  git-gui: Tighten internal pattern match for lib/ directory

cvsserver: Handle 'cvs login'

Since this is a trivial variation of the general pserver
authentication, there is really no reason not to support
it.

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

t9400: Work around CVS' deficiencies

If we are too fast with our changes, the file in
the working copy might still have the same mtime
as noted in the CVS/Entries. This will cause CVS
to happily report to the server that the file is
unmodified which can lead to data loss (and in
our case test failure).

CVS sucks!

Work around that by sleeping for a second.

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

Allow contrib new-workdir to link into bare repositories

On one particular system I like to keep a cluster of bare Git
repositories and spawn new-workdirs off of them.  Since the bare
repositories don't have working directories associated with them
they don't have a .git/ subdirectory that hosts the repository we
are linking to.

Using a bare repository as the backing repository for a workdir
created by this script does require that the user delete core.bare
from the repository's configuration file, so that Git auto-senses
the bareness of a repository based on pathname information, and
not based on the config file.

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

mailsplit: fix for more than one input files

Earlier commit d63bd9a broke the case where more than one input
files are fed to mailsplit by not incrementing the base counter
when splitting second and subsequent input files.  This should
fix it.

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

cvsserver: Fix some typos in asciidoc documentation

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

cvsserver: Note that CVS_SERVER can also be specified as method variable

Reasonably new versions of the cvs CLI client allow one to
specifiy CVS_SERVER as a method variable directly in
CVSROOT. This is way more convinient than using an
environment variable since it gets saved in CVS/Root.

Since I only discovered this by accident I guess there
might be others out there that learnt CVS on the 1.11
series (or even earlier) and profit from such a note
about cvs improvements in the last couple years.

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

cvsserver: Correct inetd.conf example in asciidoc documentation

While the given example worked, it made us look rather
incompetent. Give the correct reason why one needs the
more complex syntax and change the example to reflect
that.

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

user-manual: fixed typo in example

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

Add test case for $Id$ expanded in the repository

This test case would have caught the bug fixed by revision
c23290d5.

It puts various forms of $Id$ into a file in the repository,
without allowing git to collapse them to uniformity.  Then enables the
$Id$ expansion on checkout, and checks that what is checked out has
coped with the various forms.

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

Merge branch 'maint-1.5.1' into maint

* maint-1.5.1:
  git-svn: avoid md5 calculation entirely if SVN doesn't provide one
  Fix stupid typo in lookup_tag()

git-svn: avoid md5 calculation entirely if SVN doesn't provide one

There's no point in calculating an MD5 if we're not going to use
it.  We'll also avoid the possibility of there being a bug in the
Perl MD5 library not being able to handle zero-sized files.

This is a followup to 20b3d206acbbb042c7ad5f42d36ff8d036a538c5,
which allows us to track repositories that do not provide MD5
checksums.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

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

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Guess our share/git-gui/lib path at runtime if possible
  Correct key bindings to Control-<foo>
  git-gui: Tighten internal pattern match for lib/ directory

Makefile: Remove git-fsck and git-verify-pack from PROGRAMS

Those are builtins. Remove them from PROGRAMS variable

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix stupid typo in lookup_tag()

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-gui: Guess our share/git-gui/lib path at runtime if possible

Johannes Sixt asked me to try to avoid embedding the runtime location
of git-gui's library directory in the executable script.  Not embedding
it helps the MinGW to be relocatable to another directory should a user
wish to install the programs in a directory other than the location the
packager wanted them to be installed into.

Most of this is a hack.  We try to determine if the path of our master
git-gui script will be able to locate the lib by ../share/git-gui/lib.
This should be true if $(gitexecdir) and $(libdir) have the same prefix.
If they do then we defer the assignment of $(libdir) until runtime, and
we get it from $argv0 rather than embedding it into the script itself.

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

update diff-delta.c copyright

There is actually nothing left from the original LibXDiff code I used
over 2 years ago, and even the GIT implementation has diverged quite a
bit from LibXDiff's at this point.  Let's update the copyright notice
to better reflect that fact.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

improve delta long block matching with big files

Martin Koegler noted that create_delta() performs a new hash lookup
after every block copy encoding which are currently limited to 64KB.

In case of larger identical blocks, the next hash lookup would normally
point to the next 64KB block in the reference buffer and multiple block
copy operations will be consecutively encoded.

It is however possible that the reference buffer be sparsely indexed if
hash buckets have been trimmed down in create_delta_index() when hashing
of the reference buffer isn't well balanced.  In that case the hash
lookup following a block copy might fail to match anything and the fact
that the reference buffer still matches beyond the previous 64KB block
will be missed.

Let's rework the code so that buffer comparison isn't bounded to 64KB
anymore.  The match size should be as large as possible up front and
only then should multiple block copy be encoded to cover it all.
Also, fewer hash lookups will be performed in the end.

According to Martin, this patch should reduce his 92MB pack down to 75MB
with the dataset he has.

Tests performed on the Linux kernel repo show a slightly smaller pack and
a slightly faster repack.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Attempt to delay prepare_alt_odb during get_sha1

Not every input value passed to get_sha1 is an abbreviated SHA-1.
Its actually quite common for refs to be passed and for those
refs to resolve to full SHA-1s, in which case we may not need to
initialize the alternate object database list in this process.

I'm relocating the call to prepare_alt_odb closer to the code
that actually needs it to maintain the fix first introduced by
Junio in 99a19b43 (to avoid ambiguous SHA-1 abbreviations from
being accepted).  This allows us to avoid the alt_odb list setup
if we won't actually need it.

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

Micro-optimize prepare_alt_odb

Calling getenv() is not that expensive, but its also not free,
and its certainly not cheaper than testing to see if alt_odb_tail
is not null.

Because we are calling prepare_alt_odb() from within find_sha1_file
every time we cannot find an object file locally we want to skip out
of prepare_alt_odb() as early as possible once we have initialized
our alternate list.

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

Lazily open pack index files on demand

In some repository configurations the user may have many packfiles,
but all of the recent commits/trees/tags/blobs are likely to
be in the most recent packfile (the one with the newest mtime).
It is therefore common to be able to complete an entire operation
by accessing only one packfile, even if there are 25 packfiles
available to the repository.

Rather than opening and mmaping the corresponding .idx file for
every pack found, we now only open and map the .idx when we suspect
there might be an object of interest in there.

Of course we cannot known in advance which packfile contains an
object, so we still need to scan the entire packed_git list to
locate anything.  But odds are users want to access objects in the
most recently created packfiles first, and that may be all they
ever need for the current operation.

Junio observed in b867092f that placing recent packfiles before
older ones can slightly improve access times for recent objects,
without degrading it for historical object access.

This change improves upon Junio's observations by trying even harder
to avoid the .idx files that we won't need.

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

Add git-submodule command

This command can be used to initialize, update and inspect submodules. It
uses a .gitmodules file, readable by git-config, in the top level directory
of the 'superproject' to specify a mapping between submodule paths and
repository url.

Example .gitmodules layout:

[module "git"]
url = git://git.kernel.org/pub/scm/git/git.git

With this entry in .gitmodules (and a commit reference in the index entry for
the path "git"), the command 'git submodule init' will clone the repository
at kernel.org into the directory "git".

Known issues
============
There is currently no way to override the url found in the .gitmodules file,
except by manually creating the subproject repository. The place to fix this
in the script has a rather long comment about a possible plan.

Funny paths will be quoted in the output from git-ls-files, but git-submodule
does not attempt to unquote (or even detect the presence of) such paths.

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

Make the pack-refs interfaces usable from outside

This just basically creates a "pack_refs()" function that could be used by
anybody. You pass it in the flags you want as a bitmask (PACK_REFS_ALL and
PACK_REFS_PRUNE), and it will do all the heavy lifting.

Of course, it's still static, and it's all in the builtin-pack-refs.c
file, so it's not actually visible to the outside, but the next step would
be to just move it all to a library file (probably refs.c) and expose it.

Then we could easily make "git gc" do this too.

While I did it, I also made it check the return value of the fflush and
fsync stage, to make sure that we don't overwrite the old packed-refs file
with something that got truncated due to write errors!

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'maint'

* maint:
  Fix git-svn to handle svn not reporting the md5sum of a file, and test.
  Fix mishandling of $Id$ expanded in the repository copy in convert.c
  More echo "$user_message" fixes.
  Add tests for the last two fixes.
  git-commit: use printf '%s\n' instead of echo on user-supplied strings
  git-am: use printf instead of echo on user-supplied strings
  Documentation: Add definition of "evil merge" to GIT Glossary
  Replace the last 'dircache's by 'index'
  Documentation: Clean up links in GIT Glossary

Merge branch 'maint-1.5.1' into maint

* maint-1.5.1:
  Fix git-svn to handle svn not reporting the md5sum of a file, and test.
  More echo "$user_message" fixes.
  Add tests for the last two fixes.
  git-commit: use printf '%s\n' instead of echo on user-supplied strings
  git-am: use printf instead of echo on user-supplied strings
  Documentation: Add definition of "evil merge" to GIT Glossary
  Replace the last 'dircache's by 'index'
  Documentation: Clean up links in GIT Glossary

Move refspec pattern matching to match_refs().

This means that send-pack and http-push will support pattern refspecs,
so builtin-push.c doesn't have to expand them, and also git push can
just turn --tags into "refs/tags/*", further simplifying
builtin-push.c

check_ref_format() gets a third "conditionally okay" result for
something that's valid as a pattern but not as a particular ref.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix git-svn to handle svn not reporting the md5sum of a file, and test.

Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix mishandling of $Id$ expanded in the repository copy in convert.c

If the repository contained an expanded ident keyword (i.e. $Id:XXXX$),
then the wrong bytes were discarded, and the Id keyword was not
expanded.  The fault was in convert.c:ident_to_worktree().

Previously, when a "$Id:" was found in the repository version,
ident_to_worktree() would search for the next "$" after this, and
discarded everything it found until then.  That was done with the loop:

    do {
        ch = *cp++;
        if (ch == '$')
            break;
        rem--;
    } while (rem);

The above loop left cp pointing one character _after_ the final "$"
(because of ch = *cp++).  This was different from the non-expanded case,
were cp is left pointing at the "$", and was different from the comment
which stated "discard up to but not including the closing $".  This
patch fixes that by making the loop:

    do {
        ch = *cp;
        if (ch == '$')
            break;
        cp++;
        rem--;
    } while (rem);

That is, cp is tested _then_ incremented.

This loop exits if it finds a "$" or if it runs out of bytes in the
source.  After this loop, if there was no closing "$" the expansion is
skipped, and the outer loop is allowed to continue leaving this
non-keyword as it was.  However, when the "$" is found, size is
corrected, before running the expansion:

    size -= (cp - src);

This is wrong; size is going to be corrected anyway after the expansion,
so there is no need to do it here.  This patch removes that redundant
correction.

To help find this bug, I heavily commented the routine; those comments
are included here as a bonus.

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

More echo "$user_message" fixes.

Here are fixes to more uses of 'echo "$msg"' where $msg could contain
backslashed sequence.

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

Add tests for the last two fixes.

This updates t4014 to check the two fixes for git-am and git-commit
we observed with "echo" that does backslash interpolation by default
without being asked with -e option.

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

git-commit: use printf '%s\n' instead of echo on user-supplied strings

This fixes the same issue git-am had, which was fixed by Jeff
King in the previous commit.  Cleverly enough, this commit's log
message is a good test case at the same time.

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

git-am: use printf instead of echo on user-supplied strings

Under some implementations of echo (such as that provided by
dash), backslash escapes are recognized without any other
options. This means that echo-ing user-supplied strings may
cause any backslash sequences in them to be converted. Using
printf resolves the ambiguity.

This bug can be seen when using git-am to apply a patch
whose subject contains the character sequence "\n"; the
characters are converted to a literal newline. Noticed by
Szekeres Istvan.

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

fixes to output of git-verify-pack -v

Now that the default delta depth is 50, it is a good idea to also bump
MAX_CHAIN to 50.

While at it, make the display a bit prettier by making the MAX_CHAIN
limit inclusive, and display the number of deltas that are above that
limit at the end instead of the beginning.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation: Add definition of "evil merge" to GIT Glossary

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

Replace the last 'dircache's by 'index'

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

Documentation: Clean up links in GIT Glossary

Ensure that the same link is not repeated in single glossary entry,
and that there is no self-link i.e. link to current entry.

Add links to other definitions in git glossary.

Remove inappropriate (nonsense) links, or change link to link to
correct definition (to correct term).

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

Add a configuration option to control diffstat after merge

The diffstat can be controlled either with command-line options
(--summary|--no-summary) or with merge.diffstat. The default is
left as it was: diffstat is active by default.

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

Add another verbosity level to git-fetch

Use "-v -v" to run git-fetch-pack in verbose mode.

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

Verbose connect messages to show the IP addresses used

Also, the patch makes the error messages more verbose. Helps when
diagnosing connect problems on weird systems.

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

Add option to cvs update before export

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Remove git-applypatch

The previous one removed git-applymbox, which was the sole user
of this tool.

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

git-applymbox: Remove command

I believe noone uses git-applymbox, and noone definitely should, since it
is supposed to be completely superseded and everything by its younger
cousin git-am. The only known person in the universe to use it was Linus
and he declared some time ago that he will try to use git-am instead in his
famous dotest script.

The trouble is that git-applymbox existence creates confusing UI. I'm a bit
like a recycled newbie to the git porcelain and *I* was confused by
git-applymbox primitiveness until I've realized a while later that I'm of
course using the wrong command.

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

Merge branch 'maint'

* maint:
  fix memory leak in parse_object when check_sha1_signature fails
  name-rev: tolerate clock skew in committer dates
  Update bash completion for git-config options
  Teach bash completion about recent log long options
  Teach bash completion about 'git remote update'
  Update bash completion header documentation
  Remove a duplicate --not option in bash completion
  Teach bash completion about git-shortlog
  Hide the plumbing diff-{files,index,tree} from bash completion
  Update bash completion to ignore some more plumbing commands

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

* 'master' of git://repo.or.cz/git/fastimport:
  Update bash completion for git-config options
  Teach bash completion about recent log long options
  Teach bash completion about 'git remote update'
  Update bash completion header documentation
  Remove a duplicate --not option in bash completion
  Teach bash completion about git-shortlog
  Hide the plumbing diff-{files,index,tree} from bash completion
  Update bash completion to ignore some more plumbing commands

Ensure git-repack -a -d --max-pack-size=N deletes correct packs

The packfile portion of the "remove redundant" code
near the bottom of git-repack.sh is broken when
pack splitting occurs.  Particularly since this is
the only place where we automatically delete packfiles,
make sure it works properly for all cases,  old or new.

Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Make "git gc" pack all refs by default

I've taught myself to use "git gc" instead of doing the repack explicitly,
but it doesn't actually do what I think it should do.

We've had packed refs for a long time now, and I think it just makes sense
to pack normal branches too. So I end up having to do

git pack-refs --all --prune

in order to get a nice git repo that doesn't have any unnecessary files.

So why not just do that in "git gc"? It's not as if there really is any
downside to packing branches, even if they end up changing later. Quite
often they don't, and even if they do, so what?

Also, make the default for refs packing just be an unambiguous "do it",
rather than "do it by default only for non-bare repositories". If you want
that behaviour, you can always just add a

[gc]
packrefs = notbare

in your ~/.gitconfig file, but I don't actually see why bare would be any
different (except for the broken reason that http-fetching used to be
totally broken, and not doing it just meant that it didn't even get
fixed in a timely manner!).

So here's a trivial patch to make "git gc" do a better job. Hmm?

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Teach mailsplit about Maildir's

Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'maint-1.5.1' into maint

* maint-1.5.1:
  fix memory leak in parse_object when check_sha1_signature fails
  name-rev: tolerate clock skew in committer dates

fix memory leak in parse_object when check_sha1_signature fails

When check_sha1_signature fails, program is not terminated:
it prints an error message and returns NULL, so the
buffer returned by read_sha1_file should be freed before.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

name-rev: tolerate clock skew in committer dates

In git.git repository, "git-name-rev v1.3.0~158" cannot name the
rev, while adjacent revs can be named.

This was because it gives up traversal from the tips of existing
refs as soon as it sees a commit that has older commit timestamp
than what is being named.  This is usually a good heuristics,
but v1.3.0~158 has a slightly older commit timestamp than
v1.3.0~157 (i.e. it's child), as these two were made in a
separate repostiory (in fact, in a different continent).

This adds a hardcoded slop value (1 day) to the cut-off
heuristics to work this kind of problem around.  The current
algorithm essentially runs around from the available tips down
to ancient commits and names every single rev available that are
newer than cut-off date, so a single day slop would not add that
much overhead in repositories with long enough history where the
performance of name-rev matters.

I think the algorithm could be made a bit smarter by deepening
the graph on demand as a new commit is asked to be named (this
would require rewriting of name_rev() function not to recurse
itself but use a traversal list like revision.c traverser does),
but that would be a separate issue.

Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Correct key bindings to Control-<foo>

Alberto Bertogli reported on #git that git-gui was exiting with
alt-q, while gitk on the same system was exiting with ctrl-q.
That was not what I wanted.  I really wanted M1B to be bound to
the Control key on most non-Mac OS X platforms, but according to
Sam Vilain M1 on most systems means alt.  Since gitk always does
control, I'm doing the same thing for all non-Mac OS X systems.

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

Update bash completion for git-config options

A few new configuration options grew out of the woodwork during the
1.5.2 series.  Most of these are pretty easy to support a completion
of, so we do so.

I wanted to also add completion support for the <driver> part of
merge.<driver>.name but to do that we have to look at all of the
.gitattributes files and guess what the unique set of <driver>
strings would be.  Since this appears to be non-trivial I'm punting
on it at this time.

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

Teach bash completion about recent log long options

(Somewhat) recently git-log learned about --reverse (to show commits
in the opposite order) and a looong time ago I think it learned
about --raw (to show the raw diff, rather than a unified diff).
These are both useful options, so we should make them easy for the
user to complete.

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

Teach bash completion about 'git remote update'

Recently the git-remote command grew an update subcommand, which
can be used to execute git-fetch across multiple repositories
in a single step.  These can be configured with the 'remotes.*'
configuration options, so we can offer completion for any name that
matches and appears to be useful to git-remote update.

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

Allow environment variables to be unset in the processes started by run_command

To unset a variable, just specify its name, without "=". For example:

    const char *env[] = {"GIT_DIR=.git", "PWD", NULL};
    const char *argv[] = {"git-ls-files", "-s", NULL};
    int err = run_command_v_opt_cd_env(argv, RUN_GIT_CMD, ".", env);

The PWD will be unset before executing git-ls-files.

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