GIT 0.99.8d

GIT 0.99.8d

[Junio C Hamano]

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.

Re: GIT 0.99.8d

[Ed Tomlinson]

Hi,

Debian users beware.  This version introduces a dependency - package: 
libcurl3-gnutls-dev
is now needed to build git.

Thanks
Ed Tomlinson

On Sunday 16 October 2005 01:41, Junio C Hamano wrote:
> 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/
> 
> 

Re: GIT 0.99.8d

[Junio C Hamano]

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.

Re: GIT 0.99.8d

[Marco Roeland]

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'.
-- 
Marco Roeland

Re: GIT 0.99.8d

[Ed Tomlinson]

Hi,

This explains things.  I am not building via the debian package.  What happened is that
sid (amd64) dropped libcurl3-dev and I did not add one of the other packages...

Thanks
Ed

On Sunday 16 October 2005 14:55, Marco Roeland wrote:
> 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'.

Re: GIT 0.99.8d

[David Lang]

when I recently installed git 0.99.8c on my gentoo system it died during 
the install without curl installed, but worked once curl was installed. (I 
haven't gotten around to reporting th packaging bug to gentoo yet)

David Lang

  On Sun, 
16 Oct 2005, Junio C Hamano wrote:

> 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
>

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

GIT 0.99.8e

[Junio C Hamano]

GIT 0.99.8e 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/

The "master" branch has updated "git-diff-*" commands, that 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

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
contains the necessary backport of the git-apply changes.

This will hopefully be the last 0.99.8 maintenance release.