0.99.9 on Saturday next week.

We have been at version "0.99.8.GIT" for too long, and maintenance branch is now up to 0.99.8f.

When git-daemon was deployed on kernel.org machines, I wanted to stabilize things a bit so that we can feature freeze and do a real 1.0. Recently we have changed things quite a bit, but having them only in the "master" branch without having an official release for some time kept Porcelains in limbo. I am sure both Pasky and Catalin want to start updating Cogito and StGIT to take advantage of what the new core offers, but they cannot just randomly use new features only available in the "master" branch and expect people to use 0.99.8.GIT version of unknown vintage.

So here is a heads-up to list what to expect in 0.99.9. I am not promising that 0.99.9 will be followed by 1.0 -- it could well be 0.99.10.

The "master" branch, not counting barebone Porcelainish scripts that real Porcelains would not utilize, contains the following additions and enhancements. Many of them have been forward ported to 0.99.8 maintenance branch already:

 - Cygwin (HPA).
 - Configuration files (Linus).
 - core.filemode to tell not to trust working tree mode bits.
 - git-daemon (HPA).
 - git-symbolic-ref for platforms with/without symlinks (Linus).
 - sparse .git/object/??/ directory (Linus).
 - git-update-ref.
 - funny pathnames quoted in C-style.
 - sha1^{} and sha1^{type} notation.
 - git-ls-remote reports object names tags point to.
 - git-apply operates in a sparse tree.
 - git-diff records which blob each patch applies to.
 - git-format-patch; --stdout and rev ranges.
 - git-update-index --index-info.
 - git-read-tree -m -u removes empty directories.
 - git-http-fetch drives multiple connections (Nick Hengeveld).
 - git-http-fetch is safer with funny-characters.
 - the name of packfile is more stable.
 - clone-pack keeps the pack unpacked.
 - git-check-ref-format; ref names are stricter than before.
 - git-pack-files --local (Linus).
 - fetch-pack git+ssh:// and ssh+git:// (Linus).
 - svn import (Matthias).
 - ls-tree filename listing bugfix (Robert Fitzsimons).
 - git-index-pack (Sergey).

In addition, we have handful things cooking in the proposed updates branch. I expect these to come to some conclusion by the end of next week, and 0.99.9 will contain what's ready by then:

 - rev-list --dense (Linus).
 - fetch-pack further improvements (Johannes).
 - pack-objects using cached results.

Although we had a good proposal for protocol rewrite from HPA and discussions that followed, it appeared to me that the change might be a bit too backward incompatible while the advantage was not obvious enough -- I do not think we have a consensus on it. 0.99.9 will not wait for this discussion to conclude.

One last request. If you have sent bugfixes in the C-part of the code (i.e. really core) that I have not applied without a good reason, please remind me. I do not think I have dropped or postponed-then-forgot anything, but I just want to be sure. I am really in stabilization mood this week.

Junio C Hamano wrote:

Not the least since it would be quite a bit of work to make it happen.

	-hpa

Junio C Hamano <junkio@cox.net> wrote:

The "master" branch in StGIT uses, in general, the latest features in the "master" branch of GIT. I have a "stable" one which is restricted to a specific GIT version (0.99.8 at the moment).

Since the configuration files use the .ini like syntax, is it OK for StGIT to use the same file, with an "[stgit]" section?

Catalin Marinas <catalin.marinas@gmail.com> writes:

I think that is a reasonable thing to do.

On Tue, 25 Oct 2005, Junio C Hamano wrote:

Absolutely. The whole thing was _designed_ to be used that way. Any C user should be able to just link against config.o without even bothering with the rest of git (the only git-specific thing there should be some naming), and any script user can either

 - parse the simple config language by hand (not really a good idea, but 
   it _is_ pretty simple)
 - just run "git-var -l" and parse the output.

ie if you want to track "[stgit]" config options, just do

	git-var -l | sed '/^stgit\./ s/^stgit.//p'

and it will pick up everything starting with "stgit." and remove that part.

What remains should be a simple list or "variable=value" pairs.

Oh - and the convention is that 

 (a) we've already done any quote expansion (although I may have to make 
     git-var quote "\n" - I didn't care enough to do so)
 (b) a boolean variable without a "=" means that it was set to "true" 
     (which is different from an _empty_ one, which has a "=" but just 
     doesn't have any value)

The (b) thing is just a special case, so that you can write

	[stgit]
		debug

and it will be the same as

	[stgit]
		debug = true

which just seems to be the sane thing to do.

		Linus

On 25/10/05, Linus Torvalds <torvalds@osdl.org> wrote:

I use Python for StGIT and it has support for parsing .ini syntax, no need to use GIT for this (unless the syntax you chose would diverge too much).

-- Catalin

On Wed, 26 Oct 2005, Catalin Marinas wrote:

The syntax differences I'm aware of:

 - the git ".ini" parser is case-insensitive in the variable names. I 
   don't know if this is true in general. I do know a lot of people use 
   MixedCase things, but I don't know if it's because they care, or 
   because they think it's so pretty.

 - the git parser accepts either ";" or "#" as comments, and anywhere on a 
   line (not just at the beginning). Again, others may or may not do the 
   same.

 - the git parser wants a "=" for the assignment. I think the Python one 
   also accepts ":". If people care, we could make the git parser allow 
   either.

 - duplicate entries. The git parser allows them, and will just pass them 
   on multiple times. In fact, I had a patch (that I threw out) that 
   depended on this, and allowed you to rewrite hostnames for git_connect 
   with something like

	[host]
		rewrite = "host.com:" "git://git.host.com/"
		rewrite = "other.org:" "rsync://rsync.other.org/"

   and the git config file parser happily just parses this as two 
   different entries for "host.rewrite"

 - quoting. This is likely the big one. The git parser thinks only the 
   regular '"' character ("rabbit ears") is a quote, and passes single- 
   ticks through unmolested. I don't have a clue what others do, if 
   anything.

In the absense of quotes, most should be trivial to handle by just being careful.

		Linus