tokkee.org

Do not verify filenames in a bare repository

For example, it makes no sense to check the presence of a file
named "HEAD" when calling "git log HEAD" in a bare repository.

Noticed by Han-Wen Nienhuys.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

Stop ignoring Documentation/README

We do not copy this file from elsewhere anymore.

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

apply --cached: fix crash in subdirectory

The static variable "prefix" was shadowed by an unused parameter
of the same name. In case of execution in a subdirectory, the
static variable was accessed, leading to a crash.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

show-branch --reflog: fix show_date() call

Not passing tz to show_date() is not a fix.

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

show_date(): fix relative dates

We pass a timestamp (i.e. number of seconds elapsed since Jan 1 1970,
00:00:00 GMT) to the function. So there is no need to "fix" the
timestamp according to the timezone.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

show-branch --reflog: tighten input validation.

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

show-branch --reflog: show the reflog message at the top.

This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.

You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>.  <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').

Here is a sample output (with --list option):

  $ git show-branch --reflog=10 --list jc/show-reflog
    [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
    [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
    [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
    [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
    [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
    [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
    [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
    [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
    [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
    [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use

This shows what I did more cleanly:

  $ git show-branch --reflog=10 jc/show-reflog
  ! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
   ! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
    ! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
     ! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
      ! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
       ! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
        ! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
         ! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
          ! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
           ! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
  ----------
  +          [jc/show-reflog@{0}] show-branch --reflog: show the reflog
    +        [jc/show-reflog@{2}] show-branch --reflog: show the reflog
   +++       [jc/show-reflog@{1}] show-branch --reflog: show the reflog
  +++++      [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
       +     [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
        +    [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
         +   [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
           + [jc/show-reflog@{9}] show-branch --reflog: use updated rea
           + [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
           + [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
           + [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
  ++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM

At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).

I first saved them with "format-patch -4", and then did a reset
at @{8}.  At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent).  I did not like the
log message, so I amended again at @{5}.

Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it).  Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.

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

Extend read_ref_at() to be usable from places other than sha1_name.

You can pass an extra argument to the function to receive the
reflog message information.  Also when the log does not go back
beyond the point the user asked, the cut-off time and count are
given back to the caller for emitting the error messages as
appropriately.

We could later add configuration for get_sha1_basic() to make it
an error instead of it being just a warning.

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

dwim_ref(): Separate name-to-ref DWIM code out.

I'll be using this in another function to figure out what to
pass to resolve_ref().

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

config_set_multivar(): disallow newlines in keys

This will no longer work:

$ git repo-config 'key.with
newline' some-value

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

rename --exec to --receive-pack for push and send-pack

For now it's just to get a more descriptive name.  Later we might update the
push protocol to run more than one program on the other end.  Moreover this
matches better the corresponding config option remote.<name>. receivepack.

--exec continues to work

Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

make --exec=... option to git-push configurable

Having to specify git push --exec=... is annoying if you cannot have
git-receivepack in your PATH on the remote side (or don't want to).

This introduces the config item remote.<name>.receivepack to override
the default value (which is "git-receive-pack").

Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Update documentation of fetch-pack, push and send-pack

add all supported options to Documentation/git-....txt and the usage strings.

Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Documentation/git.txt: command re-classification

This adds two new classes (pure-helpers and "Interacting with
Others") to the command list in the main manual page.  The
latter class is primarily about foreign SCM interface and is
placed before low-level (plumbing) commands.

Also it promotes a handful commands to mainporcelain category
while demoting some others.

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

Documentation: generated cmds-*.txt does not depend on git.txt

Pointed out by Santi.

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

refs.c::read_ref_at(): fix bogus munmap() call.

The code uses mmap() to read reflog data, but moves the pointer around
while reading, and uses that updated pointer in the call to munmap().

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

for_each_reflog_ent: do not leak FILE *

The callback function can signal an early return by returning non-zero,
but the function leaked the FILE * opened on the reflog when doing so.

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

Documentation: Generate command lists.

This moves the source of the list of commands and categorization
to the end of Documentation/cmd-list.perl, so that re-categorization
and re-ordering would become easier to manage.

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

Documentation: sync git.txt command list and manual page title

Also reorders a handful entries to make each list sorted
alphabetically.

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

Documentation: move command list in git.txt into separate files.

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

prune-packed: add -q to usage

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

Document --ignore-if-in-upstream in git-format-patch

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

Shell syntax fix in git-reset

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

Use standard -t option for touch.

Non-GNU touch do not have the -d option to take free form
date strings.  The POSIX -t option should be more widespread.
For this to work, date needs to output YYYYMMDDHHMM.SS date strings.

Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use fixed-size integers for .idx file I/O

This attempts to finish what Simon started in the previous commit.

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

Use fixed-size integers for the on-disk pack structure.

Plain integer types without a fixed size can vary between platforms.  Even
though all common platforms use 32-bit ints, there is no guarantee that
this won't change at some point.  Furthermore, specifying an integer type
with explicit size makes the definition of structures more obvious.

Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Accept 'inline' file data in fast-import commit structure.

Its very annoying to need to specify the file content ahead of a
commit and use marks to connect the individual blobs to the commit's
file modification entry, especially if the frontend can't/won't
generate the blob SHA1s itself.  Instead it would much easier to
use if we can accept the blob data at the same time as we receive
each file_change line.

Now fast-import accepts 'inline' instead of a mark idnum or blob
SHA1 within the 'M' type file_change command.  If an inline is
detected the very next line must be a 'data n' command, supplying
the file data.

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

Reduce value duplication in t9300-fast-import.

It is error prone to list the value of each file twice, instead we
should list the value only once early in the script and reuse the
shell variable when we need to access it.

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

Create test case for fast-import.

Now that its easier to craft test cases (thanks to 'data <<')
we should start to verify fast-import works as expected.

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

Support delimited data regions in fast-import.

During testing its nice to not have to feed the length of a data
chunk to the 'data' command of fast-import.  Instead we would
prefer to be able to establish a data chunk much like shell's <<
operator and use a line delimiter to denote the end of the input.

So now if a data command is started as 'data <<EOF' we will look
for a terminator line containing only the string EOF on that line.
Once found, we stop the data command.  Everything between the two
lines is used as the data value.

The 'data <<' syntax is slower than 'data n', as we don't know how
many bytes to expect and instead must grow our buffer on the fly.
It also has the problem that the frontend must use a string which
will not appear on a line by itself in the input, and the data
region will always end in an LF.  For these reasons real import
frontends are encouraged to continue to use _only_ 'data n'.

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

Remove unnecessary options from fast-import.

The --objects command line option is rather unnecessary.  Internally
we allocate objects in 5000 unit blocks, ensuring that any sort
of malloc overhead is ammortized over the individual objects to
almost nothing.  Since most frontends don't know how many objects
they will need for a given import run (and its hard for them to
predict without just doing the run) we probably won't see anyone
using --objects.  Further since there's really no major benefit
to using the option, most frontends won't even bother supplying
it even if they could estimate the number of objects.  So I'm
removing it.

The --max-objects-per-pack option was probably a mistake to even
have added in the first place.  The packfile format is limited
to 4 GiB today; given that objects need at least 3 bytes of data
(and probably need even more) there's no way we are going to exceed
the limit of 1<<32-1 objects before we reach the file size limit.
So I'm removing it (to slightly reduce the complexity of the code)
before anyone gets any wise ideas and tries to use it.

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

Use fixed-size integers when writing out the index in fast-import.

Currently the pack .idx file format uses 32-bit unsigned integers
for the fan-out table and the object offsets.  We had previously
defined these as 'unsigned int', but not every system will define
that type to be a 32 bit value.  To ensure maximum portability we
should always use 'uint32_t'.

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

Always use struct pack_header for pack header in fast-import.

Previously we were using 'unsigned int' to update the hdr_entries
field of the pack header after the file had been completed and
was being hashed.  This may not be 32 bits on all platforms.
Instead we want to always uint32_t.

I'm actually cheating here by just using the pack_header like the
rest of Git and letting the struct definition declare the correct
type.  Right now that field is still 'unsigned int' (wrong) but a
pending change submitted by Simon 'corecode' Schubert changes it
to uint32_t.  After that change is merged in fast-import will do
the right thing all of the time.

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

git-format-patch: the default suffix is now .patch, not .txt

Editors often give easier handling of patch files if the
filename ends with .patch, so use it instead of .txt.

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

git-format-patch: make --binary on by default

It does not make much sense to generate a patch that cannot be
applied.  If --text is specified on the command line it still
takes precedence.

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

Add --summary to git-format-patch by default

This adds --summary output in addition to the --stat to the
output from git-format-patch by default.

I think additions, removals and filemode changes are rare but
notable events and always showing it makes sense.

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

git-format-patch -3

This teaches "git-format-patch" to honor the --max-count
parameter revision traversal machinery takes, so that you can
say "git-format-patch -3" to process the three topmost commits
from the current HEAD (or "git-format-patch -2 topic" to name a
specific branch).

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

Document pack .idx file format upgrade strategy.

Way back when Junio developed the 64 bit index topic he came up
with a means of changing the .idx file format so that older Git
clients would recognize that they don't understand the file and
refuse to read it, while newer clients could tell the difference
between the old-style and new-style .idx files.  Unfortunately
this wasn't recorded anywhere.

This change documents how we might go about changing the .idx
file format by using a special signature in the first four bytes.
Credit (and possible blame) goes completely to Junio for thinking
up this technique.

The change also modifies the error message of the current Git code
so that users get a recommendation to upgrade their Git software
should this version or later encounter a new-style .idx which it
cannot process.  We already do this for the .pack files, but since
we usually process the .idx files first its important that these
files are recognized and encourage an upgrade.

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

Refer users to git-rev-parse for revision specification syntax.

The revision specification syntax (sometimes referred to as
SHA1-expressions) is accepted almost everywhere in Git by
almost every tool.  Unfortunately it is only documented in
git-rev-parse.txt, and most users don't know to look there.

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

Document the master@{n} reflog query syntax.

In ab2a1a32 Junio improved the reflog query logic to support
obtaining the n-th prior value of a ref, but this was never
documented in git-rev-parse.  Now it is.

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

Documentation/git-parse-remote.txt: we deal with config vars as well

... but we never documented it.

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

Documentation: m can be relative in "git-blame -Ln,m"

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

Documentation: suggest corresponding Porcelain-level in plumbing docs.

Instead of keeping the confused end user reading low-level
documentation, suggest the higher level commands that implement
what the user may want to do using them upfront.

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

Documentation/git-resolve: deprecated.

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

sanitize content of README file

Current README content is way too esoteric for someone looking at GIT
for the first time. Instead it should provide a quick summary of what
GIT is with a few pointers to other resources.

The bulk of the previous README content is moved to
Documentation/core-intro.txt.

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

git-format-patch: do not crash with format.headers without value.

An incorrect config file can say:

[format]
headers

and crash the parsing.

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

Introduce 'git-format-patch --suffix=.patch'

The default can also be changed with "format.suffix" configuration.
Leaving it empty would not add any suffix.

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

Documentation/glossary.txt: describe remotes/ tracking and packed-refs

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

Documentation/glossary.txt: unpacked objects are loose.

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

Documentation: describe shallow repository

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

Make a short-and-sweet "git-add -i" synonym for "git-add --interactive"

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

Documentation: detached HEAD

Add discussion section to git-checkout documentation and mention
detached HEAD in repository-layout document.

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

Documentation: a few spelling fixes

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

Documentation/git-sh-setup.txt: programmer's docs

Clarify that this is not meant for end users, and list what
shell functions are defined.

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

Documentation/git-whatchanged.txt: show -<n> instead of --max-count.

... to match the change we did earlier to git-log documentation.

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

Documentation/git-status.txt: mention color configuration

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

Documentation/git-tar-tree.txt: default umask is now 002

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

Documentation/git-tools.txt: mention tig and refer to wiki

In general list at Wiki seems to be maintained a lot better than
this list.

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

Documentation/git-tag: the command can be used to also verify a tag.

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

Documentation/SubmittingPatches: Gnus tips

Also warn about format=flowed (aka 'flawed').

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

Correct packfile edge output in fast-import.

Branches are only contained by a packfile if the branch actually
had its most recent commit in that packfile.  So new branches are
set to MAX_PACK_ID to ensure they don't cause their commit to list
as part of the first packfile when it closes out if the commit was
actually in existance before fast-import started.

Also corrected the type of last_commit to be umaxint_t to prevent
overflow and wraparound on very large imports.  Though that is
highly unlikely to occur as we're talking 4 billion commits, which
no real project has right now.

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

git-commit: document log message formatting convention

Take it from the tutorial, since not everybody necessarily reads it.

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

Declare no-arg functions as (void) in fast-import.

Apparently the git convention is to declare any function which
takes no arguments as taking void.  I did not do this during the
early fast-import development, but should have.

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

cache.h; fix a couple of prototypes

Trivial patch.

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

Document where configuration files are in config.txt

Talking about what the files contain without talking about where
they are does not help new users.

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

Correct a few types to be unsigned in fast-import.

The length of an atom string cannot be negative.  So make it
explicit and declare it as an unsigned value.

The shift width in a mark table node also cannot be negative.
I'm also moving it to after the pointer arrays to prevent any
possible alignment problems on a 64 bit system.

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

Corrected BNF input documentation for fast-import.

Now that fast-import uses uintmax_t (the largest available unsigned
integer type) for marks we don't want to say its an unsigned 32
bit integer in ASCII base 10 notation.  It could be much larger,
especially on 64 bit systems, and especially if a frontend uses
a very large number of marks (1 per file revision on a very, very
large import).

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

Use merge-recursive in git-checkout -m (branch switching)

This allows "git checkout -m <other-branch>" to notice renames and
carry local changes in the working tree forward.

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

git-commit documentation: remove comment on unfixed git-rm

... which was fixed since then.

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

tutorial: shorthand for remotes but show distributed nature of git

* Promiscous pull shows the distributed nature of git better.
* Add a new step after that to teach "remote add".
* Highlight that with the shorthand defined you will get
  remote tracking branches for free.
* Fix Alice's workflow.

Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

tutorial: Use only separate layout

Then the newbies only have to understand one layout.

Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix spurious compile error

From time to time, I would get this error:

[...]
sed: -e expression #8, char 41: Unterminated `s' command
make: *** [git-add--interactive] Error 1

Turns out that the function WriteMakefile() called in Makefile.PL
outputs the message "Writing perl.mak for Git" to stdout! Thus,
the output of "make -C perl -s --no-print-directory instlibdir"
would be prefixed by that message whenever Makefile.PL was newer
than perl.mak.

This is fixed by redirecting stdout to stderr in Makefile.PL.

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

Print out the edge commits for each packfile in fast-import.

To help callers repack very large repositories into a series of
packfiles fast-import now outputs the last commits/tags it wrote to
a packfile when it prints out the packfile name.  This information
can be feed to pack-objects --revs to repack.  For the first pack
of an initial import this is pretty easy (just feed those SHA1s on
stdin) but for subsequent packs you want to feed the subsequent
pack's final SHA1s but also all prior pack's SHA1s prefixed with
the negation operator.  This way the prior pack's data does not
get included into the subsequent pack.

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

git-rm documentation: remove broken behaviour from the example.

The example section were talking about the old broken default
behaviour.  Correct it.

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

git-push documentation: remaining bits

Mention --thin, --no-thin, --repo and -v.

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

document --exec for git-push

The text is just copied from git-send-pack.txt.

Signed-off-by: Uwe Kleine-K\e,Av\e(Bnig <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Correct object_count type and stat output in fast-import.

Since object_count is limited to 'unsigned long' (really an
unsigned 32 bit integer value) by the pack file format we may as
well use exactly that type here in fast-import for that counter.
An earlier change by me incorrectly made it uintmax_t.

But since object_count is a counter for the current packfile only,
we don't want to output its value at the end.  Instead we should
sum up the individual type counters and report that total, as that
will cover all of the packfiles.

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

Correct max_packsize default in fast-import.

Apparently amd64 has defined 'unsigned long' to be a 64 bit value,
which means -1 was way over the 4 GiB packfile limit.  Whoops.

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

git-svn: print and flush authentication prompts to STDERR

People that redirect STDOUT output should always see STDERR
prompts interactively.

STDERR should always be flushed without buffering, so
they should always show up.  If that is unset, we still
explicitly flush by calling STDERR->flush.

The svn command-line client prompts to STDERR, too.

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

Solaris 5.8 returns ENOTDIR for inappropriate renames.

The reflog code clears empty directories when rename returns
either EISDIR or ENOTDIR.  Seems to be the only place.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Replace "echo -n" with printf in shell scripts.

Not all echos know -n.  This was causing a test failure in
t5401-update-hooks.sh, but not t3800-mktag.sh for some reason.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Set _ALL_SOURCE for AIX, but avoid its struct list.

AIX 5.3 seems to need _ALL_SOURCE for struct addrinfo, but that
introduces a struct list in grp.h.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Remove unnecessary pack_fd global in fast-import.

Much like the pack_sha1 the pack_fd is an unnecessary global
variable, we already have the fd stored in our struct packed_git
*pack_data so that the core library functions in sha1_file.c are
able to lookup and decompress object data that we have previously
written.  Keeping an extra copy of this value in our own variable
is just a hold-over from earlier versions of fast-import and is
now completely unnecessary.

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

Ensure we close the packfile after creating it in fast-import.

Because we are renaming the packfile into its file destination we
need to be sure its not open when the rename is called, otherwise
some operating systems (e.g. Windows) may prevent the rename from
occurring.

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

Use .keep files in fast-import during processing.

Because fast-import automatically updates all references (heads
and tags) at the end of its run the repository is corrupt unless
the objects are available in the .git/objects/pack directory prior
to the refs being modified.  The easiest way to ensure that is true
is to move the packfile and its associated index directly into the
.git/objects/pack directory as soon as we have finished output to it.

But the only safe way to do this is to create the a temporary .keep
file for that pack, so we use the same tricks that index-pack uses
when its being invoked by receive-pack.

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

Reuse sha1 in packed_git in fast-import.

Rather than maintaing our own packfile level sha1 variable we
can make use of the one already available in struct packed_git.
Its meant for the SHA1 of the index but it can also hold the
SHA1 of the packfile itself between final checksumming of the
packfile and creation of the index.

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

Replace redundant yread() with read_in_full() in fast-import.

Prior to git having read_in_full() fast-import used its own private
function yread to perform the header reading task.  No sense in
keeping that around now that read_in_full is a public, stable
function.

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

Use uintmax_t for marks in fast-import.

If a frontend wants to use a mark per file revision and per commit
and is doing a truly huge import (such as a 32 GiB SVN repository)
we may need more than 2**32 unique mark values, especially if the
frontend is unable (or unwilling) to recycle mark values.  For mark
idnums we should use the largest unsigned integer type available,
hoping that will be at least 64 bits when we are compiled as a 64
bit executable.  This way we may consume huge amounts of memory
storing our mark table, but we'll at least be able to process
the entire import without failing.

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

Corrected buffer overflow during automatic checkpoint in fast-import.

If we previously were using a delta but we needed to checkpoint the
current packfile and switch to a new packfile we need to throw away
the delta and compress the raw object by itself, as delta chains
cannot span non-thin packfiles.  Unfortunately the output buffer
in this case needs to grow, as the size of the compressed object
may be quite a bit larger than the size of the compressed delta.

I've also avoided recompressing the object if we are checkpointing
and we didn't use a delta.  In this case the output buffer is the
correct size and has already been populated with the right data,
we just need to close out the current packfile and open a new one.

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

Start all test scripts with /bin/sh.

My bash refused to run the two scripts missing a #!, and it's
better to use the same line for all the scripts.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-pull: disallow implicit merging to detached HEAD

Instead, we complain to the user and suggest that they explicitly
specify the remote and branch. We depend on the exit status of
git-symbolic-ref, so let's go ahead and document that.

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

Fix git-fetch while on detached HEAD not to give needlessly alarming errors

When we are on a detached HEAD, there is no current branch.
There is no reason to leak the error messages to the end user
since this is a situation we expect to see.

This adds -q option to git-symbolic-ref to exit without issuing
an error message if the given name is not a symbolic ref.

By the way, with or without this patch, there currently is no
good way to tell failure modes between "git symbolic-ref HAED"
and "git symbolic-ref HEAD".  Both says "is not a symbolic ref".

We may want to do something about it.

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

git reflog expire: document --stale-fix option.

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

Print the packfile names to stdout from fast-import.

Caller scripts may want to know what packfiles the fast-import
process just wrote out for them.  This is now output to stdout,
one packfile name per line, after we checkpoint each packfile.

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

Implemented automatic checkpoints within fast-import.

When the number of objects or number of bytes gets close to the limit
allowed by the packfile format (or configured on the command line by
our caller) we should automatically checkpoint the current packfile
and start a new one before writing the object out.  This does however
require that we abandon the delta (if we had one) as its not valid
in a new packfile.

I also added the simple rule that if we got a delta back but the
delta itself is the same size as or larger than the uncompressed
object to ignore the delta and just store the object data.  This
should avoid some really bad behavior caused by our current delta
strategy.

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

Optimize index creation on large object sets in fast-import.

When we are generating multiple packfiles at once we only need
to scan the blocks of object_entry structs which contain objects
for the current packfile.  Because the most recent blocks are at
the front of the linked list, and because all new objects going
into the current file are allocated from the front of that list,
we can stop scanning for objects as soon as we identify one which
doesn't belong to the current packfile.

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

Don't create a final empty packfile in fast-import.

If the last packfile is going to be empty (has 0 objects) then it
shouldn't be kept after the import has terminated, as there is no
point to the packfile.  So rather than hashing it and making the
index file, just delete the packfile.

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

Implemented manual packfile switching in fast-import.

To help importers which are dealing with massive amounts of data
fast-import needs to be able to close the packfile it is currently
writing to and open a new packfile for any additional data that
will be received.  A new 'checkpoint' command has been introduced
which can be used by the frontend import process to force this
to occur at any time.  This may be useful to ensure a very long
running import doesn't lose any work due to unexpected failures.

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

Remove unnecessary duplicate_count in fast-import.

There is little reason to be keeping a global duplicate_count
value when we also keep it per object type.  The global counter can
easily be computed at the end, once all processing has completed.
This saves us a couple of machine instructions in an unimportant
part of code.  But it looks slightly better to me to not keep
two counters around.

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

Restructure fast-import to support creating multiple packfiles.

Now that we are starting to see some really large projects (such
as KDE or a fork of FreeBSD) get imported into Git we're running
into the upper limit on packfile object count as well as overall
byte length.  The KDE and FreeBSD projects are both likely to
require more than 4 GiB to store their current history, which means
we really need multiple packfiles to handle their content.

This is a fairly simple restructuring of the internal code to help
us support creating multiple packfiles from within fast-import.
We are now adding a 5 digit incrementing suffix to the end of the
basename supplied to us by the caller, permitting up to 99,999
packs to be generated in a single fast-import run.

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