RelNotes: spelling & grammar fixes

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mb/relnotes-1.8.5-fix'

* mb/relnotes-1.8.5-fix:
  RelNotes: spelling & grammar fixes
Git 1.8.4.4

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with 1.8.4.4
Git 1.8.5-rc3

Signed-off-by: Junio C Hamano <gitster@pobox.com>
transport.h: remove send_pack prototype, already defined in send-pack.h
send-pack: forbid pushing from a shallow repository

send-pack can send a pack with loose ends to the server.  receive-pack
before 6d4bb38 (fetch: verify we have everything we need before
updating our ref - 2011-09-01) does not detect this and keeps the pack
anyway, which corrupts the repository, at least from fsck point of
view.

send-pack will learn to safely push from a shallow repository later.
clone: prevent --reference to a shallow repository

If we borrow objects from another repository, we should also pay
attention to their $GIT_DIR/shallow (and even info/grafts). But
current alternates code does not.

Reject alternate repos that are shallow because we do not do it
right. In future we alternate code may be updated to check
$GIT_DIR/shallow properly so that this restriction could be lifted.
update-server-info: do not publish shallow clones

Dumb commit walker does not care about .git/shallow and until someone
steps up to make it happen, let's not publish shallow clones using
dumb protocols.
Advertise shallow graft information on the receiver end

If either receive-pack or upload-pack is called on a shallow
repository, shallow graft points will be sent after the ref
advertisement (but before the packet flush), so that the client has
the full "shape" of the server's commit graph.

This breaks the protocol for all clients trying to push to a shallow
repo, or fetch from one. Which is basically the same end result as
today's "is_repository_shallow() && die()" in receive-pack and
upload-pack. New clients will be made aware of shallow upstream and
can make use of this information.

Smart HTTP is not affected by this patch. Shallow support on
smart-http comes later separately.
connect.c: teach get_remote_heads to parse "shallow" lines

No callers pass a non-empty pointer as shallow_points at this
stage. As a result, all clients still refuse to talk to shallow
repository on the other end.
shallow.c: add remove_reachable_shallow_points()

When we receive a pack and the shallow points from another repository,
we may want to add more shallow points to current repo to make sure no
commits point to nowhere. However we do not want to add unnecessary
shallow points and cut our history short because the other end is a
shallow version of this repo. The output shallow points may or may not
be added to .git/shallow, depending on whether they are actually
reached by the new pack.

This function filters such shallow points out, leaving ones that might
potentially be added. A simple has_sha1_file won't do because we may
have incomplete object islands (i.e. not connected to any refs) and
the shallow points are on these islands. In that case we want to keep
the shallow points as candidates until we figure out if the new pack
connects to such object islands.

The function must be called before the new pack is installed, or we
won't know which objects are ours, which theirs.
shallow.c: add mark_new_shallow_refs()

When we receive a pack and the shallow points from another repository,
we may need to add more shallow points to current repo to make sure no
commits point to nowhere. But usually we don't want to do so because
(in future) new shallow points invalidate pack bitmaps and we need to
rebuild them again, which is not cheap.

So the default way is we allow ref updates that do not introduce new
shallow points and mark the others. If the user is fine with new
shallow point addition, we accept the marked refs.

But even so we do not blindly accept all shallow points provided. Some
of them might not point to any commits in the new pack. Some might
even do, but those might be unreachable object islands. Only shallow
points that are reachable from old and new refs can stay.

The way it's implemented is paint down from each ref, attach a bitmap
to each commit where one bit represents one ref. In order to avoid
allocating new bitmap for every commit, we try to reuse the same
bitmap for parent commits if possible. This reduces allocation and
leaks deliberately because it's hard to keep/time consuming track how
many pointers to the same buffer.
shallow.c: extend setup_*_shallow() to accept extra shallow points
fetch-pack.c: move shallow update code out of fetch_pack()
fetch-pack.h: one statement per bitfield declaration
clone: support remote shallow repository

The gist of cloning a remote shallow repository is simple. The remote
gives you a pack and all its shallow roots. All you need to do is set
your .git/shallow correctly.

The rule to create this .git/shallow is simple and more importantly,
cheap: if a shallow root is found in the pack, it's probably be used
(i.e. reachable from some refs), so we add it. Others are dropped.

One may notice this method seems flawed by the word "probably". A
shallow point may not be reachable from any refs at all if it's
attached to an object island (a group of objects that are not
reachable by any refs).

If that object island is not complete, a new fetch request may send
more objects to connect it to some ref. At that time, because we
incorrectly installed the shallow root in this island, the user will
not see anything after that root. This is not desired.

There is a stricter method to rule out unwanted shallow roots above
and it will be added later for general fetches. But it's expensive and
even more so for a clone because it's proportional to the (potentially
huge) number of commits. Given that object islands are rare (C Git
never sends such islands), a tradeoff is made to surprise the user
occasionally but work faster everyday. --strict option could be added
later.
fetch: support fetching from a shallow repository

This patch just put together pieces from the previous patches:

 - Before getting the new pack, we need to remove all new reachable
   shallow roots, in favor of current shallow roots.

 - After getting the pack, walk all new refs until they connect to
   current refs, or hit the bottom of current repo, or hit new
   shallow roots.

   Those that hit new shallow roots are rejected because by default we
   do not allow updating .git/shallow
upload-pack: make sure deepening preserves shallow roots

When "fetch --depth=N" where N exceeds the longest chain of history in
the source repo, usually we just send an "unshallow" line to the
client so full history is obtained.

When the source repo is shallow we need to make sure to "unshallow"
the current shallow point and "shallow" again when the commit reaches
its shallow bottom in the source repo.

This should solve both cases: large <N> and --unshallow
fetch: add --update-shallow to get refs that require updating .git/shallow