GIT 0.99.9e maintenance release is found at the usual places:
RPM, tarballs, and deb:
http://www.kernel.org/pub/software/scm/git/
With git, fetch maint branch from
git://git.kernel.org/pub/scm/git/git.git/
It contains everything from the master branch. Since we seem to
be shelving the separate git binary directory idea indefinitely,
what we have here is pretty much what will be in 1.0, from the
source code POV.
- http-push seems to still have a bug or two but that is to be
expected for any new code, and I am reasonably sure it can be
ironed out; preferably before 1.0 but it is not a
showstopper.
- I've done the initial round of package splitting for Debian
side myself, but it probably needs proofreading and fixing by
experienced Debian person. Similar RPM package splitting
that parallels the above is needed. Although it is not an
absolute requirement for my sources to have perfect binary
packaging support (I am just an upstream for binary
packagers), it is certainly desirable to have RPM specs and
debian/ files in a presentable shape for 1.0.
- I still need to go over the tutorial and core-ish
documentation once for consistency checks.
Changes since 0.99.9d are:
Johannes Schindelin:
Allow GIT_DIR to be an absolute path
http-fetch: do not use curl_message after releasing it
Jon Loeliger:
Refactor merge strategies into separate includable file.
Junio C Hamano:
test: t4102-apply-rename fails with strict umask (Peter Baumann).
git-format-patch: silly typo fix.
Documentation: pull/clone ref mapping clarification (Josef Weidendorfer).
git-fetch: fail if specified refspec does not match remote.
Simplify CFLAGS/DEFINES in Makefile
Package split: Debian.
Install asciidoc sources as well.
Further Debian split fixes.
Debian: test build.
Merge in http-push first stage.
Document expat dependency when using http-push.
ls-files: --others should not say unmerged paths are unknown.
git-status: do not mark unmerged paths as committable.
Set up remotes/origin to track all remote branches.
Nick Hengeveld:
Add support for pushing to a remote repository using HTTP/DAV
Verify remote packs, speed up pending request queue
Support remote references with slashes in their names
Improve lock handling
Refresh the remote lock if it is about to expire
Paul Collins:
http-push.c: include with angle bracket, not dq.
Randal L. Schwartz:
Use fink/darwinport paths for OSX
Hi,
On Sun, 6 Nov 2005, Junio C Hamano wrote:
> - http-push seems to still have a bug or two but that is to be
> expected for any new code, and I am reasonably sure it can be
> ironed out; preferably before 1.0 but it is not a
> showstopper.
I am reasonably sure that a run with valgrind will show the way to a
stable http-push. It is just a little memory corruption: the rest works
wonderfully.
Ciao,
Dscho
On Sun, Nov 06, 2005 at 09:43:19PM -0800, Junio C Hamano wrote:
> - http-push seems to still have a bug or two but that is to be
> expected for any new code, and I am reasonably sure it can be
> ironed out; preferably before 1.0 but it is not a
> showstopper.
It seems like a minor point, but is this the appropriate name or should
it be dav-push? Not that there's anything else in the works AFAIK but
it's certainly possible that something else could run over HTTP later
on.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
Nick Hengeveld wrote:
> On Sun, Nov 06, 2005 at 09:43:19PM -0800, Junio C Hamano wrote:
>
>
>> - http-push seems to still have a bug or two but that is to be
>> expected for any new code, and I am reasonably sure it can be
>> ironed out; preferably before 1.0 but it is not a
>> showstopper.
>
> It seems like a minor point, but is this the appropriate name or should
> it be dav-push? Not that there's anything else in the works AFAIK but
> it's certainly possible that something else could run over HTTP later
> on.
>
Push over HTTP POST would at least be theoretically possible.
-hpa