0.99.9 on Saturday next week.

0.99.9 on Saturday next week.

[Junio C Hamano]

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.

Re: 0.99.9 on Saturday next week.

[H. Peter Anvin]

Junio C Hamano wrote:
> 
> 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.
> 

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

	-hpa

Re: 0.99.9 on Saturday next week.

[Catalin Marinas]

Junio C Hamano <junkio@cox.net> wrote:
> 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.

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

>  - Configuration files (Linus).

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

-- 
Catalin

Re: 0.99.9 on Saturday next week.

[Junio C Hamano]

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

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

I think that is a reasonable thing to do.

Re: 0.99.9 on Saturday next week.

[Linus Torvalds]

On Tue, 25 Oct 2005, Junio C Hamano wrote:
>
> Catalin Marinas <catalin.marinas@gmail.com> writes:
> 
> >>  - Configuration files (Linus).
> >
> > Since the configuration files use the .ini like syntax, is it OK for
> > StGIT to use the same file, with an "[stgit]" section?
> 
> I think that is a reasonable thing to do.

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

Re: 0.99.9 on Saturday next week.

[Catalin Marinas]

On 25/10/05, Linus Torvalds <torvalds@osdl.org> wrote:
> On Tue, 25 Oct 2005, Junio C Hamano wrote:
> > Catalin Marinas <catalin.marinas@gmail.com> writes:
> > > Since the configuration files use the .ini like syntax, is it OK for
> > > StGIT to use the same file, with an "[stgit]" section?
> >
> > I think that is a reasonable thing to do.
>
> 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

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

Re: 0.99.9 on Saturday next week.

[Linus Torvalds]

On Wed, 26 Oct 2005, Catalin Marinas 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).

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