tokkee.org

pack-objects: remove obsolete comments

The sorted-by-sha ans sorted-by-type arrays are no more.

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

pack-objects: better check_object() performances

With large amount of objects, check_object() is really trashing the pack
sliding map and the filesystem cache.  It has a completely random access
pattern especially with old objects where delta replay jumps back and
forth all over the pack.

This patch improves things by:

 1) sorting objects by their offset in pack before calling check_object()
    so the pack access pattern is linear;

 2) recording the object type at add_object_entry() time since it is
    already known in most cases;

 3) recording the pack offset even for preferred_base objects;

 4) avoid calling sha1_object_info() if all possible.

This limits pack accesses to the bare minimum and makes them perfectly
linear.

In the process check_object() was made more clear (to me at least).

Note: I thought about walking the sorted_by_offset list backward in
get_object_details() so if a pack happens to be larger than the available
file cache, then the cache would have been populated with useful data from
the beginning of the pack already when find_deltas() is called.  Strangely,
testing (on Linux) showed absolutely no performance difference.

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

add get_size_from_delta()

... which consists of existing code split out of packed_delta_info()
for other callers to use it as well.

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

pack-objects: make in_pack_header_size a variable of its own

It currently aliases delta_size on the principle that reused deltas won't
go through the whole delta matching loop hence delta_size was unused.
This is not true if given delta doesn't find its base in the pack though.
But we need that information even for whole object data reuse.

Well in short the current state looks awful and is prone to bugs.  It just
works fine now because try_delta() tests trg_entry->delta before using
trg_entry->delta_size, but that is a bit subtle and I was wondering for a
while why things just worked fine... even if I'm guilty of having
introduced this abomination myself in the first place.

Let's do the sensible thing instead with no ambiguity, which is to have
a separate variable for in_pack_header_size.  This might even help future
optimizations.

While at it, let's reorder some struct object_entry members so they all
align well with their own width, regardless of the architecture or the
size of off_t.  Some memory saving is to be expected with this alone.

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

pack-objects: get rid of create_final_object_list()

Because we don't have to know the SHA1 h(hence the name) of the pack
up front anymore, let's get rid of yet another global sorted object list
and sort them only in write_index_file(), then compute the object list
SHA1 on the fly.

This has the advantage of saving another chunk of memory, and the sorted
list SHA1 won't be computed needlessly on servers during a fetch.

Of course the cunning plan is also to make write_index_file() much like
the function with the same name in index-pack.c for an eventual easy
sharing.

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

pack-objects: get rid of reuse_cached_pack

This capability is practically never useful, and therefore never tested,
because it is fairly unlikely that the requested pack will be already
available.  Furthermore it is of little gain over the ability to reuse
existing pack data.

In fact the ability to change delta type on the fly when reusing delta
data is a nice thing that has almost no cost and allows greater backward
compatibility with a client's capabilities than if the client is blindly
sent a whole pack without any discrimination.

And this "feature" is simply in the way of other cleanups.
Let's get rid of it.

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

pack-objects: clean up list sorting

Get rid of sort_comparator() as it impose a run time double indirect
function call for little compile time type checking gain.

Also get rid of create_sorted_list() as it only has one user which would
as well be just fine doing its sorting locally.  Eventually the list of
deltifiable objects might be shorter than the whole object list.

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

pack-objects: rework check_delta_limit usage

Objects that have delta "children" from pack data reuse must consider the
depth of their deepest child when they try to deltify themselves for those
children not to become too deep.

However, in the context of a "thin" pack, the delta children depth was
skipped entirely on the presumption that the pack was always going to be
exploded on the receiving end, hence the delta length wasn't an issue.

Now that we keep received packs as is and reuse pack data when repacking,
those packs do contain delta chains that are longer than expected. Worse,
those delta chain may even grow longer when the pack is further repacked
into another thin pack for a subsequent transmission.

So this patch restores strict delta length even for thin packs, and it
moves check_delta_limit() usage directly in the delta loop where it is
needed.  This way the delta_limit can be removed from struct object_entry
as well.  Oh and the initial value was wrong too.

The  progress_interval() function was moved to a more logical location in
the process.

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

pack-objects: equal objects in size should delta against newer objects

Before finding best delta combinations, we sort objects by name hash,
then by size, then by their position in memory.  Then we walk the list
backwards to test delta candidates.

We hope that a bigger size usually means a newer objects.  But a bigger
address in memory does not mean a newer object.  So the last comparison
must be reversed.

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

pack-objects: optimize preferred base handling a bit

Let's avoid some cycles when there is no base to test against, and avoid
unnecessary object lookups.

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

clean up add_object_entry()

This function used to call locate_object_entry_hash() _twice_ per added
object while only once should suffice. Let's reorganize that code a bit.

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

tests for various pack index features

This is a fairly complete list of tests for various aspects of pack
index versions 1 and  2.

Tests on index v2 include 32-bit and 64-bit offsets, as well as a nice
demonstration of the flawed repacking integrity checks that index
version 2 intend to solve over index version 1 with the per object CRC.

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

use test-genrandom in tests instead of /dev/urandom

This way tests are completely deterministic and possibly more portable.

Signed-off-by: Nicolas Pitre <nico@cam.org>

simple random data generator for tests

Reliance on /dev/urandom produces test vectors that are, well, random.
This can cause problems impossible to track down when the data is
different from one test invokation to another.

The goal is not to have random data to test, but rather to have a
convenient way to create sets of large files with non compressible and
non deltifiable data in a reproducible way.

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

validate reused pack data with CRC when possible

This replaces the inflate validation with a CRC validation when reusing
data from a pack which uses index version 2.  That makes repacking much
safer against corruptions, and it should be a bit faster too.

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

allow forcing index v2 and 64-bit offset treshold

This is necessary for testing the new capabilities in some automated
way without having an actual 4GB+ pack.

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

pack-redundant.c: learn about index v2

Initially the conversion was made using nth_packed_object_sha1() which
made this file completely index version agnostic. Unfortunately the
overhead was quite significant so I went back to raw index walking but
with selectable base and step values which brought back similar
performances as the original.

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

show-index.c: learn about index v2

When index v2 is encountered, the CRC32 of each object is also displayed
in parenthesis at the end of the line.

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

sha1_file.c: learn about index version 2

With this patch, packs larger than 4GB are usable, even on a 32-bit machine
(at least on Linux).  If off_t is not large enough to deal with a large
pack then die() is called instead of attempting to use the pack and
producing garbage.

This was tested with a 8GB pack specially created for the occasion on
a 32-bit machine.

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

index-pack: learn about pack index version 2

Like previous patch but for index-pack.

[ There is quite some code duplication between pack-objects and index-pack
  for generating a pack index (and fast-import as well I suppose).  This
  should be reworked into a common function eventually. But not now. ]

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

pack-objects: learn about pack index version 2

Pack index version 2 goes as follows:

 - 8 bytes of header with signature and version.

 - 256 entries of 4-byte first-level fan-out table.

 - Table of sorted 20-byte SHA1 records for each object in pack.

 - Table of 4-byte CRC32 entries for raw pack object data.

 - Table of 4-byte offset entries for objects in the pack if offset is
   representable with 31 bits or less, otherwise it is an index in the next
   table with top bit set.

 - Table of 8-byte offset entries indexed from previous table for offsets
   which are 32 bits or more (optional).

 - 20-byte SHA1 checksum of sorted object names.

 - 20-byte SHA1 checksum of the above.

The object SHA1 table is all contiguous so future pack format that would
contain this table directly won't require big changes to the code. It is
also tighter for slightly better cache locality when looking up entries.

Support for large packs exceeding 31 bits in size won't impose an index
size bloat for packs within that range that don't need a 64-bit offset.
And because newer objects which are likely to be the most frequently used
are located at the beginning of the pack, they won't pay the 64-bit offset
lookup at run time either even if the pack is large.

Right now an index version 2 is created only when the biggest offset in a
pack reaches 31 bits.  It might be a good idea to always use index version
2 eventually to benefit from the CRC32 it contains when reusing pack data
while repacking.

[jc: with the "oops" fix to keep track of the last offset correctly]

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

compute object CRC32 with index-pack

Same as previous patch but for index-pack.

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

compute a CRC32 for each object as stored in a pack

The most important optimization for performance when repacking is the
ability to reuse data from a previous pack as is and bypass any delta
or even SHA1 computation by simply copying the raw data from one pack
to another directly.

The problem with  this is that any data corruption within a copied object
would go unnoticed and the new (repacked) pack would be self-consistent
with its own checksum despite containing a corrupted object.  This is a
real issue that already happened at least once in the past.

In some attempt to prevent this, we validate the copied data by inflating
it and making sure no error is signaled by zlib.  But this is still not
perfect as a significant portion of a pack content is made of object
headers and references to delta base objects which are not deflated and
therefore not validated when repacking actually making the pack data reuse
still not as safe as it could be.

Of course a full SHA1 validation could be performed, but that implies
full data inflating and delta replaying which is extremely costly, which
cost the data reuse optimization was designed to avoid in the first place.

So the best solution to this is simply to store a CRC32 of the raw pack
data for each object in the pack index.  This way any object in a pack can
be validated before being copied as is in another pack, including header
and any other non deflated data.

Why CRC32 instead of a faster checksum like Adler32?  Quoting Wikipedia:

   Jonathan Stone discovered in 2001 that Adler-32 has a weakness for very
   short messages. He wrote "Briefly, the problem is that, for very short
   packets, Adler32 is guaranteed to give poor coverage of the available
   bits. Don't take my word for it, ask Mark Adler. :-)" The problem is
   that sum A does not wrap for short messages. The maximum value of A for
   a 128-byte message is 32640, which is below the value 65521 used by the
   modulo operation. An extended explanation can be found in RFC 3309,
   which mandates the use of CRC32 instead of Adler-32 for SCTP, the
   Stream Control Transmission Protocol.

In the context of a GIT pack, we have lots of small objects, especially
deltas, which are likely to be quite small and in a size range for which
Adler32 is dimed not to be sufficient.  Another advantage of CRC32 is the
possibility for recovery from certain types of small corruptions like
single bit errors which are the most probable type of corruptions.

OK what this patch does is to compute the CRC32 of each object written to
a pack within pack-objects.  It is not written to the index yet and it is
obviously not validated when reusing pack data yet either.

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

add overflow tests on pack offset variables

Change a few size and offset variables to more appropriate type, then
add overflow tests on those offsets.  This prevents any bad data to be
generated/processed if off_t happens to not be large enough to handle
some big packs.

Better be safe than sorry.

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

make overflow test on delta base offset work regardless of variable size

This patch introduces the MSB() macro to obtain the desired number of
most significant bits from a given variable independently of the variable
type.

It is then used to better implement the overflow test on the OBJ_OFS_DELTA
base offset variable with the property of always working correctly
regardless of the type/size of that variable.

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

get rid of num_packed_objects()

The coming index format change doesn't allow for the number of objects
to be determined from the size of the index file directly.  Instead, Let's
initialize a field in the packed_git structure with the object count when
the index is validated since the count is always known at that point.

While at it let's reorder some struct packed_git fields to avoid padding
due to needed 64-bit alignment for some of them.

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

git-archive: make tar the default format

As noted by Junio, --format=tar should be assumed if no format
was specified.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'jc/push'

* jc/push:
  git-push to multiple locations does not stop at the first failure
  git-push reports the URL after failing.

Merge branch 'jc/merge-subtree'

* jc/merge-subtree:
  A new merge stragety 'subtree'.

It is safe to merge this early as this is a feature that user
explicitly needs to ask for and would not trigger otherwise.  A
known issue with the current implementation is that the subtree
matching heuristics is very stupid.  It could run ls-tree twice
and try to count intersection.

Giving it wider audience would help it to get improved by
motivated volunteers.

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

Merge branch 'js/fetch-progress'

* js/fetch-progress:
  git-fetch: add --quiet

Merge branch 'maint'

* maint:
  Add Documentation/cmd-list.made to .gitignore
  git-svn: fix log command to avoid infinite loop on long commit messages
  git-svn: dcommit/rebase confused by patches with git-svn-id: lines
  git-svn: bail out on incorrect command-line options

Add Documentation/cmd-list.made to .gitignore

Noticed by Randal L. Schwartz.

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

git-svn: fix log command to avoid infinite loop on long commit messages

This bug has been around since the the conversion to use the
Git.pm library back in October or November.  Eventually I'd like
"git rev-list/log" to have the option to not truncate overly
long messages.

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

git-svn: dcommit/rebase confused by patches with git-svn-id: lines

When patches are merged from another git-svn managed branch,
they will have the git-svn-id: metadata line in them (generated
by git-format-patch).

When doing rebase or dcommit via git-svn, this would cause
git-svn to find the wrong upstream branch.  We now verify
that the commit is consistent with the value in the .rev_db
file.

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

git-svn: bail out on incorrect command-line options

"git svn log" is the only command that needs the pass-through
option in Getopt::Long; otherwise we will bail out and let the
user know something is wrong.

Also, avoid printing out unaccepted mixed-case options (that
are reserved for the command-line) such as --useSvmProps
in the usage() function.

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

Start 1.5.2 cycle by prepareing RelNotes for it.

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

Merge branch 'jc/read-tree-df' (early part)

* 'jc/read-tree-df' (early part):
  Fix switching to a branch with D/F when current branch has file D.
  Fix twoway_merge that passed d/f conflict marker to merged_entry().
  Fix read-tree --prefix=dir/.
  unpack-trees: get rid of *indpos parameter.
  unpack_trees.c: pass unpack_trees_options structure to keep_entry() as well.
  add_cache_entry(): removal of file foo does not conflict with foo/bar

Merge branch 'maint'

* maint:
  Prepare for 1.5.1.1
  cvsserver: small corrections to asciidoc documentation

Prepare for 1.5.1.1

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

cvsserver: small corrections to asciidoc documentation

Fix a typo: s/Not/Note/

Some formating fixes: Use ` ` syntax for all filenames and
' ' syntax for all commandline switches.

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

A new merge stragety 'subtree'.

This merge strategy largely piggy-backs on git-merge-recursive.
When merging trees A and B, if B corresponds to a subtree of A,
B is first adjusted to match the tree structure of A, instead of
reading the trees at the same level.  This adjustment is also
done to the common ancestor tree.

If you are pulling updates from git-gui repository into git.git
repository, the root level of the former corresponds to git-gui/
subdirectory of the latter.  The tree object of git-gui's toplevel
is wrapped in a fake tree object, whose sole entry has name 'git-gui'
and records object name of the true tree, before being used by
the 3-way merge code.

If you are merging the other way, only the git-gui/ subtree of
git.git is extracted and merged into git-gui's toplevel.

The detection of corresponding subtree is done by comparing the
pathnames and types in the toplevel of the tree.

Heuristics galore!  That's the git way ;-).

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

git-push to multiple locations does not stop at the first failure

When pushing into multiple repositories with git push, via
multiple URL in .git/remotes/$shorthand or multiple url
variables in [remote "$shorthand"] section, we used to stop upon
the first failure.  Continue the operation and report the
failure at the end.

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

git-push reports the URL after failing.

This came up on #git when somebody was getting 'unable to create
./objects/tmp_oXXXX' but sweared he had write permission to that
directory.  It turned out that the repository URL was changed
and he was accessing a repository he does not have a write
permission anymore.

I am not sure how much this would have helped somebody who
believed he was accessing location when the permission of that
location was changed while he was looking the other way, though.
But giving more information on the error path would be better,
and the next change would be helped with this as well.

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

Merge branch 'jc/index-output'

* jc/index-output:
  git-read-tree --index-output=<file>
  _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.

Conflicts:

builtin-apply.c

Merge branch 'fp/make-j'

* fp/make-j:
  Makefile: Add '+' to QUIET_SUBDIR0 to fix parallel make.

Merge branch 'cc/bisect'

* cc/bisect:
  git-bisect: allow bisecting with only one bad commit.
  t6030: add a bit more tests to git-bisect
  git-bisect: modernization
  Documentation: bisect: "start" accepts one bad and many good commits
  Bisect: teach "bisect start" to optionally use one bad and many good revs.

Merge branch 'jc/checkout' (early part)

* 'jc/checkout' (early part):
  checkout: allow detaching to HEAD even when switching to the tip of a branch

Merge branch 'maint'

* maint:
  Documentation: tighten dependency for git.{html,txt}
  Makefile: iconv() on Darwin has the old interface
  t5300-pack-object.sh: portability issue using /usr/bin/stat
  t3200-branch.sh: small language nit
  usermanual.txt: some capitalization nits
  Make builtin-branch.c handle the git config file
  rename_ref(): only print a warning when config-file update fails
  Distinguish branches by more than case in tests.
  Avoid composing too long "References" header.
  cvsimport: Improve formating consistency
  cvsimport: Reorder options in documentation for better understanding
  cvsimport: Improve usage error reporting
  cvsimport: Improve documentation of CVSROOT and CVS module determination
  cvsimport: sync usage lines with existing options

Conflicts:

Documentation/Makefile

Documentation: tighten dependency for git.{html,txt}

Every time _any_ documentation page changed, cmds-*.txt files
were regenerated, which caused git.{html,txt} to be remade.  Try
not to update cmds-*.txt files if their new contents match the
old ones.

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

Makefile: iconv() on Darwin has the old interface

The libiconv on Darwin uses the old iconv() interface (2nd argument is a
const char **, instead of a char **).  Add OLD_ICONV to the Darwin
variable definitions to handle this.

Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Acked-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

t5300-pack-object.sh: portability issue using /usr/bin/stat

In the test 'compare delta flavors', /usr/bin/stat is used to get file size.
This isn't portable.  There already is a dependency on Perl, use its '-s'
operator to get the file size.

Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-bisect: allow bisecting with only one bad commit.

This allows you to say:

git bisect start
git bisect bad $bad
git bisect next

to start bisection without knowing a good commit.  This would
have you try a commit that is half-way since the beginning of
the history, which is rather wasteful if you already know a good
commit, but if you don't (or your history is short enough that
you do not care), there is no reason not to allow this.

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

t6030: add a bit more tests to git-bisect

Verify that git-bisect does not start before getting one bad and
one good commit.

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

t3200-branch.sh: small language nit

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

usermanual.txt: some capitalization nits

Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Make builtin-branch.c handle the git config file

This moves the knowledge about .git/config usage out of refs.c and into
builtin-branch.c instead, which allows git-branch to update HEAD to point
at the moved branch before attempting to update the config file. It also
allows git-branch to exit with an error code if updating the config file
should fail.

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

rename_ref(): only print a warning when config-file update fails

If git_config_rename_section() fails, rename_ref() used to return 1, which
left HEAD pointing to an absent refs/heads file (since the actual renaming
had already occurred).

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

Distinguish branches by more than case in tests.

The renaming without config test changed a branch from q to Q, which
fails on non-case sensitive file systems.  Change the test to use q
and q2.

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

Avoid composing too long "References" header.

The number of characters in a line MUST be no more than 998 characters,
and SHOULD be no more than 78 characters (RFC2822).
It is much safer to fold the header by ourselves.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

cvsimport: Improve formating consistency

Use ' ' syntax for all commandline options mentioned in text.

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

cvsimport: Reorder options in documentation for better understanding

The current order the options are documented in makes no sense
at all to me. Reorder them so that similar options are grouped
together and also order them somehwhat by importance.

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

cvsimport: Improve usage error reporting

Actually tell the user what he did wrong in case of usage errors
instead of only printing the general usage information.

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

cvsimport: Improve documentation of CVSROOT and CVS module determination

Document the fact that git-cvsimport tries to find out CVSROOT from
CVS/Root and $ENV{CVSROOT} and CVS_module from CVS/Repository.

Also use ` ` syntax for all filenames for consistency.

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

cvsimport: sync usage lines with existing options

Sync both the usage lines in the code and the asciidoc
documentation with the real list of options. While
all options seems to be documented in the asciidoc
document, not all of them were listed in the usage line.

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

git-bisect: modernization

This slightly modernizes the bisect script to use show-ref/for-each-ref
instead of looking into $GIT_DIR/refs files directly.

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

Merge branch 'maint'

* maint:
  Fix lseek(2) calls with args 2 and 3 swapped
  Honor -p<n> when applying git diffs
  Fix dependency of common-cmds.h
  Fix renaming branch without config file
  DESTDIR support for git/contrib/emacs
  gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches
  Document --left-right option to rev-list.
  Revert "builtin-archive: use RUN_SETUP"
  rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.
  rerere: make sorting really stable.
  Fix t4200-rerere for white-space from "wc -l"

Fix lseek(2) calls with args 2 and 3 swapped

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

Makefile: Add '+' to QUIET_SUBDIR0 to fix parallel make.

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

Documentation: bisect: "start" accepts one bad and many good commits

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Bisect: teach "bisect start" to optionally use one bad and many good revs.

One bad commit is fundamentally needed for bisect to run,
and if we beforehand know more good commits, we can narrow
the bisect space down without doing the whole tree checkout
every time we give good commits.

This patch implements:

    git bisect start [<bad> [<good>...]] [--] [<pathspec>...]

as a short-hand for this command sequence:

    git bisect start
    git bisect bad $bad
    git bisect good $good1 $good2...

On the other hand, there may be some confusion between revs
(<bad> and <good>...) and <pathspec>... if -- is not used
and if an invalid rev or a pathspec that looks like a rev is
given.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix passing of TCLTK_PATH to git-gui

GNU make does not include environment variables by default
in its namespace. Just pass them in make command line.

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

Rename add_file_to_index() to add_file_to_cache()

This function was not called "add_file_to_cache()" only because
an ancient program, update-cache, used that name as an internal
function name that does something slightly different.  Now that
is gone, we can take over the better name.

The plan is to name all functions that operate on the default
index xxx_cache().  Later patches create a variant of them that
take an explicit parameter xxx_index(), and then turn
xxx_cache() functions into macros that use "the_index".

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

Rename static variable write_index to update_index in builtin-apply.c

This is an internal variable used to tell if we need to write
out the resulting index.

I'll be introducing write_index() function which would collide
with it.

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

Rename internal function "add_file_to_cache" in builtin-update-index.c

I'd like to consistently name all index-layer functions that
operate on the default index xxx_cache(), and this application
specific function interferes with the plan.

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

Propagate cache error internal to refresh_cache() via parameter.

The function refresh_cache() is the only user of cache_errno
that switches its behaviour based on what internal function
refresh_cache_entry() finds; pass the error status back in a
parameter passed down to it, to get rid of the global variable
cache_errno.

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

Fix bogus error message from merge-recursive error path

This error message should not usually trigger, but the function
make_cache_entry() called by add_cacheinfo() can return early
without calling into refresh_cache_entry() that sets cache_errno.

Also the error message had a wrong function name reported, and
it did not say anything about which path failed either.

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

Show binary file size change in diff --stat

Previously, a binary file in the diffstat would show as:

 some-binary-file.bin       |  Bin

The space after the "Bin" was never used.  This patch changes binary
lines in the diffstat to be:

 some-binary-file.bin       |  Bin 12345 -> 123456 bytes

The very nice "->" notation was suggested by Johannes Schindelin, and
shows the before and after sizes more clearly than "+" and "-" would.
If a size is 0 it's not shown (although it would probably be better to
treat no-file differently from zero-byte-file).

The user can see what changed in the binary file, and how big the new
file is.  This is in keeping with the information in the rest of the
diffstat.

The diffstat_t members "added" and "deleted" were unused when the file
was binary, so this patch loads them with the file sizes in
builtin_diffstat().  These figures are then read in show_stats() when
the file is marked binary.

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

Honor -p<n> when applying git diffs

If the user is trying to apply a Git generated diff file and they
have specified a -p<n> option, where <n> is not 1, the user probably
has a good reason for doing this.  Such as they are me, trying to
apply a patch generated in git.git for the git-gui subdirectory to
the git-gui.git repository, where there is no git-gui subdirectory
present.

Users shouldn't supply -p2 unless they mean it.  But if they are
supplying it, they probably have thought about how to make this
patch apply to their working directory, and want to risk whatever
results may come from that.

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

Fix dependency of common-cmds.h

Say $(wildcard ...) when we mean it.

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

Fix lost-found to show commits only referenced by reflogs

Prior to 1.5.0 the git-lost-found utility was useful to locate
commits that were not referenced by any ref.  These were often
amends, or resets, or tips of branches that had been deleted.
Being able to locate a 'lost' commit and recover it by creating a
new branch was a useful feature in those days.

Unfortunately 1.5.0 added the reflogs to the reachability analysis
performed by git-fsck, which means that most commits users would
consider to be lost are still reachable through a reflog.  So most
(or all!) commits are reachable, and nothing gets output from
git-lost-found.

Now git-fsck can be told to ignore reflogs during its reachability
analysis, making git-lost-found useful again to locate commits
that are no longer referenced by a ref itself, but may still be
referenced by a reflog.

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

clean up and optimize nth_packed_object_sha1() usage

Let's avoid the open coded pack index reference in pack-object and use
nth_packed_object_sha1() instead.  This will help encapsulating index
format differences in one place.

And while at it there is no reason to copy SHA1's over and over while a
direct pointer to it in the index will do just fine.

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

Fix renaming branch without config file

Make git_config_rename_section return success if no config file
exists.  Otherwise, renaming a branch would abort, leaving the
repository in an inconsistent state.

[jc: test]

Signed-off-by: Geert Bosch <bosch@gnat.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

DESTDIR support for git/contrib/emacs

make install DESTDIR=... support for git/contrib/emacs

Signed-off-by: Ville Skyttä <scop@xemacs.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches

git_patchset_body needs patch generated with --full-index option to
detect split patches, meaning two patches which corresponds to single
difftree (raw diff) entry.  An example of such situation is changing
type (mode) of a file, e.g. from plain file to symbolic link.

Add, in git_blobdiff, --full-index option to patch generating git diff
invocation, for the 'html' format output ("blobdiff" view).

"blobdiff_plain" still uses shortened sha1 in the extended git diff
header "index <hash>..<hash>[ <mode>]" line.

Noticed-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Document --left-right option to rev-list.

Explanation is paraphrased from "577ed5c... rev-list --left-right"

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

Revert "builtin-archive: use RUN_SETUP"

Commit 64edf4b2 cleaned up the initialization of git-archive,
at the cost of 'git-archive --list' now requiring a git repo.
This patch reverts the cleanup and documents the requirement
for this particular dirtyness in a test.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>

rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.

 $ git grep post-receieve-email
 $ git grep post-receive-email
 templates/hooks--post-receive:#. /usr/share/doc/git-core/contrib/hooks/post-receive-email
 $

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

RPM spec: include git-p4 in the list of all packages.

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

rerere: make sorting really stable.

The earlier code does not swap hunks when the beginning of the
first side is identical to the whole of the second side.  In
such a case, the first one should sort later.

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

Fix t4200-rerere for white-space from "wc -l"

On OS X, wc outputs 6 spaces before the number of lines, so the test
expecting the string "10" failed.  Do not quote $cmd to strip away
the problematic whitespace as other tests do.

Also fix the grammar of the test name while making changes to it.
There's only one preimage, so it's "has", not "have".

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

git-svn: bail out on incorrect command-line options

"git svn log" is the only command that needs the pass-through
option in Getopt::Long; otherwise we will bail out and let the
user know something is wrong.

Also, avoid printing out unaccepted mixed-case options (that
are reserved for the command-line) such as --useSvmProps
in the usage() function.

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

gitweb: Quote hash keys, and do not use barewords keys

Ensure that in all references to an element of a hash, the
key is singlequoted, instead of using bareword: use $hash{'key'}
instead of $hash{key}

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

gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (3)

Code should be look the same way, regardless of tab size.
Use tabs for indent, but spaces for align.

Indent continued part of command spanning multiple lines, but only once.

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

Fix switching to a branch with D/F when current branch has file D.

This loosens the over-eager verify_absent() check that gets
upset to find directory D in the current working tree when
switching to a branch that has a file there.  The check needs to
make sure that we do not lose precious working tree files as a
result of removing directory D and replacing it with the file
from the other branch, which is a tad expensive but this is a
less common case.

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

Fix twoway_merge that passed d/f conflict marker to merged_entry().

When switching from one tree to another, we should not send a
marker that says "this file does not exist in the new tree -- I
am a placeholder to tell you that, and not a real blob" down to
merged_entry() as the result of the merge.

Fix read-tree --prefix=dir/.

The existing code is not wrong per-se, but it started scanning the index
from a location that does not match the tree being read, and wasted
cycles.

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

unpack-trees: get rid of *indpos parameter.

This variable keeps track of which entry in the original index
the traversal is looking at, and belongs to the unpack_trees_options
structure along with other traversal status information.

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

unpack_trees.c: pass unpack_trees_options structure to keep_entry() as well.

Other decision functions, deleted_entry() and merged_entry() take one as
their parameter, and this function should.  I'll be introducing a separate
index to build the result in, and am planning to pass it as the part of the
structure.

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

add_cache_entry(): removal of file foo does not conflict with foo/bar

Similarly, removal of file foo/bar does not conflict with a file foo.

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

Merge branch 'jc/bisect'

* jc/bisect:
  make the previous optimization work also on path-limited rev-list --bisect
  rev-list --bisect: Fix "halfway" optimization.
  t6004: add a bit more path optimization test.
  git-rev-list --bisect: optimization
  git-rev-list: add --bisect-vars option.
  t6002: minor spelling fix.