GIT 0.99.8d

> GIT 0.99.8d is available as usual at:
> 
>     RPMs and tarball: www.kernel.org:/pub/software/scm/git/
>     Debs and tarball: www.kernel.org:/pub/software/scm/git/debian/
> 
> In addition to accumulated bugfixes, there is one important
> futureproofing changes.
> 
> The "master" branch has changes to git-upload-pack (which would
> affect what git-fetch-pack/git-clone-pack see) and
> git-update-server-info (which would affect what fetch and clone
> over http:// transport see) to send extra information about the
> available references, so that the clients can find out what
> objects are referenced by remote tags before downloading them.
> They take the form of "tagname^{}".  "git ls-remote $repository"
> command would show something like this:
> 
>     7a3ca7d2b5ec31b2cfa594b961d77e68075e33c7        refs/heads/master
>     5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c        refs/tags/v2.6.11-tree
>     c39ae07f393806ccf406ef966e9a15afc43cc36a        refs/tags/v2.6.11-tree^{}
>     ...
>     c2bbf523f1d454649897b3e4bcd71778e4fa5913        refs/tags/v2.6.14-rc2
>     676d55ae30ea3b688f0386f70553489f25f24d55        refs/tags/v2.6.14-rc2^{}
>     f92737b18abac90af30ac26a050fda879c9b238b        refs/tags/v2.6.14-rc3
>     1c9426e8a59461688bb451e006456987b198e4c0        refs/tags/v2.6.14-rc3^{}
> 
> when the server side updates to the version in the "master"
> branch.  These "^{}" entries describe the SHA1 of the object the
> tag object points at (so v2.6.11-tree tag, whose object name is
> 5dc01c... points at a tree object whose object name is
> c39ae0...).
> 
> The downloading clients (git-clone and git-fetch) in the
> "master" branch have been taught to recognize these entries;
> after all, these are not real refs and you cannot give them to
> git-http-fetch to fetch from.  GIT 0.99.8d clients have the same
> change, so that people staying with the maintenance branch can
> download from the server that already runs the "master" version
> and sends these fake references without getting confused.
> 
> upload-pack and update-server-info in GIT 0.99.8d would not show
> these extra "fake refs" when used on the server side.  In other
> words, 0.99.8d is to keep the maintenance branch working with
> newer servers.
> 
> There will be GIT 0.99.8e at around the time "master" branch
> will get the updated "git-diff-*", for similar purposes.  The
> updated "git-diff-*" commands deal with pathnames with funny
> characters (most importantly tabs and newlines) in a way
> compatible with the proposed change to GNU patch, which was
> outlined in:
> 
>     http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2
> 
> The change to "git-diff-*", and corresponding change to
> "git-apply" are cooking in the proposed updates branch right
> now.  When people start generating diffs with them, patches that
> touch paths that have double-quotes '"' or spaces ' ' in them
> need to be applied with the updated git-apply that knows how new
> "git-diff-*" encodes these funny pathnames.  GIT 0.99.8e is
> planned to backport the necessary git-apply changes, in case we
> do not bump the major release number by then.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

> > Debian users beware.  This version introduces a dependency - package: 
> > libcurl3-gnutls-dev
> > is now needed to build git.
> 
> Is this really true?  The one I uploaded was built on this
> machine:
> 
> : siamese; dpkg -l libcurl\* | sed -ne 's/^ii  //p'
> libcurl3          7.14.0-2       Multi-protocol file transfer library, now wi
> libcurl3-dev      7.14.0-2       Development files and documentation for libc
> 
> Having said that, a tested patch to debian/control to adjust
> Build-Depends is much appreciated.

> On Sunday October 16th 2005 Junio C Hamano wrote:
> 
> > > Debian users beware.  This version introduces a dependency - package: 
> > > libcurl3-gnutls-dev
> > > is now needed to build git.
> > 
> > Is this really true?  The one I uploaded was built on this
> > machine:
> > 
> > : siamese; dpkg -l libcurl\* | sed -ne 's/^ii  //p'
> > libcurl3          7.14.0-2       Multi-protocol file transfer library, now wi
> > libcurl3-dev      7.14.0-2       Development files and documentation for libc
> > 
> > Having said that, a tested patch to debian/control to adjust
> > Build-Depends is much appreciated.
> 
> The present line is correct. In 'debian/control' the line reads
> (word-wrapped here):
> 
> Build-Depends-Indep: libz-dev, libssl-dev,
>  libcurl3-dev|libcurl3-gnutls-dev|libcurl3-openssl-dev, asciidoc (>=
>  6.0.3), xmlto, debhelper (>= 4.0.0), bc
> 
> So it works correct on 'stable' versions ('libcurl3-dev') and
> latest 'unstable' as well, where you have the choice of either
> 'libcurl3-gnutls-dev' or 'libcurl3-openssl-dev'.

> Date: Sun, 16 Oct 2005 11:22:57 -0700
> From: Junio C Hamano <junkio@cox.net>
> To: Ed Tomlinson <tomlins@cam.org>
> Cc: git@vger.kernel.org, linux-kernel@vger.kernel.org
> Subject: Re: GIT 0.99.8d
> 
> Ed Tomlinson <tomlins@cam.org> writes:
>
> (Obligatory "do not top post" request omitted)
>
>> Debian users beware.  This version introduces a dependency - package:
>> libcurl3-gnutls-dev
>> is now needed to build git.
>
> Is this really true?  The one I uploaded was built on this
> machine:
>
> : siamese; dpkg -l libcurl\* | sed -ne 's/^ii  //p'
> libcurl3          7.14.0-2       Multi-protocol file transfer library, now wi
> libcurl3-dev      7.14.0-2       Development files and documentation for libc
>
> Having said that, a tested patch to debian/control to adjust
> Build-Depends is much appreciated.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>