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:
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:
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.
> 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:
> 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:
> 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.
> 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.
> > 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):
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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):
> 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'.
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:
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.
