GIT 0.99.9

GIT 0.99.9 is found at usual places.

As I said in the 0.99.8 announcement, git already does everything I want it to do, and from here on I'd like to see us concentrate on fixes (both correctness and performance) until we hit 1.0 which should happen shortly.

Many thanks to everybody who contributed the comments, extra set of eyeballs, and code.

Done in 0.99.9 ==============

Ports ~~~~~

* Cygwin port [HPA].

* OpenBSD build [Merlyn and others].

Fixes ~~~~~

* clone request over git native protocol from a repository with
  too many refs did not work; this has been fixed.

* git-daemon got safer for kernel.org use [HPA].

* Extended SHA1 parser was not enforcing uniqueness for
  abbreviated SHA1; this has been fixed.

* http transport does not barf on funny characters in URL.

* The ref naming restrictions have been formalized and the
  coreish refuses to create funny refs; we still need to audit
  importers.  See git-check-ref-format(1).

New Features and Commands ~~~~~~~~~~~~~~~~~~~~~~~~~

* .git/config file as a per-repository configuration mechanism,
  and some commands understand it [Linus].  See
  git(7).

* The core.filemode configuration item can be used to make us a
  bit more FAT friendly.  See git(7).

* The extended SHA1 notation acquired Peel-the-onion operator
  ^{type} and ^{}.  See git-rev-parse(1).

* SVN importer [Matthias].  See git-svnimport(1).

* .git/objects/[0-9a-f]{2} directories are created on demand,
  and removed when becomes empty after prune-packed [Linus].

* Filenames output from various commands without -z option are
  quoted when they embed funny characters (TAB and LF) using
  C-style quoting within double-quotes, to match the proposed
  GNU diff/patch notation [me, but many people contributed in
  the discussion].

* git-mv is expected to be a better replacement for git-rename.
  While the latter has two parameter restriction, it acts more
  like the regular 'mv' that can move multiple things to one
  destinatino directory [Josef Weidendorfer].

* git-checkout can take filenames to revert the changes to
  them.  See git-checkout(1)

* The new program git-am is a replacement for git-applymbox that
  has saner command line options and a bit easier to use when a
  patch does not apply cleanly.

* git-ls-remote can show unwrapped onions using ^{} notation, to
  help Cogito to track tags.

* git-merge-recursive backend can merge unrelated projects.

* git-clone over native transport leaves the result packed.

* git-http-fetch issues multiple requests in parallel when
  underlying cURL library supports it [Nick and Daniel].

* git-fetch-pack and git-upload-pack try harder to figure out
  better common commits [Johannes].

* git-read-tree -u removes a directory when it makes it empty.

* git-diff-* records abbreviated SHA1 names of original and
  resulting blob; this sometimes helps to apply otherwise an
  unapplicable patch by falling back to 3-way merge.

* git-format-patch now takes series of from..to rev ranges and
  with '-m --stdout', writes them out to the standard output.
  This can be piped to 'git-am' to implement cheaper
  cherry-picking.

* git-tag takes '-u' to specify the tag signer identity [Linus].

* git-rev-list can take optional pathspecs to skip commits that
  do not touch them (--dense) [Linus].

* Comes with new and improved gitk [Paulus and Linus].

Junio C Hamano wrote:

[Lots of text deleted]

It's nice to see the TODO list get shorter for a change! Especially since the removed TODO items are not on the HAVEDONE list.

So, with 0.99.9 being the (non) "scary" release of Git, are you targeting the Git 1.0 to be the (non) "turkey" release or the "fruit cake" release? ;-)

A Large Angry SCM <gitzilla@gmail.com> writes:

Huh?  What are you talking about?

Most of the items that were on the TODO list and marked [DONE] are on the HAVEDONE list, although I rephrased many of them to be more appropriate for the release notes. The only thing that I did not list on HAVEDONE list was 'whatchanged -m' documentation. There are many documentation contributions from the list I do not mention in HAVEDONE.

I dropped from the TODO list was the "Perhaps show ^{commit}, ^{tree} instead of ^{} from ls-remote", whose benefit was dubious.

Junio C Hamano wrote:

                                    ^^^
Oops! The ``not'' wasn't supposed to be there!!!!

My typing was in error. The ``not'' should not have been there.

Junio, I think you're doing an great job with Git. Particularly, since I'm thinking that it may be mature enough to replace another SCM with a very large code base that I deal with.

Hi,

On Sat, 29 Oct 2005, A Large Angry SCM wrote:

Concur!

Add to that the fact that most, if not all, changes are made backwards compatible, i.e. git has stable for a *long* time now.

Ciao, Dscho

On Sat, 29 Oct 2005, Junio C Hamano wrote:

Congrats. I personally think this is very much worthy of a 1.0 after just giving it some time to shake out any possible last-minute bugs.

		Linus

I was reviewing the rev-list documentation and it struck me that dense/sparse command line flag do not make much sense.

Since dense is by default in effect, --dense is a no-op. One possible use of it would be to hardcode --dense on a rev-list command line in a script, like:

	git-rev-list $some_opts --dense $some_paths

to defeat user-supplied --sparse that can be in $some_opts, but for this to work the script needs to have parsed out user input into some_opts and some_paths in the first place anyway, so it can just detect and remove --sparse just as easily.

The --sparse flag does not seem to have much use either; not giving pathspec has the same effect.

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

No.

--sparse _does_ have effect, but it's subtler.

Try "--sparse" together with a pathspec. It will only do the merge follow optimization.

Now, how useful is that? It's potentially useful as a way to "linearize the history". For example, let's say that you wanted to simplify the commit history for a project, and you only cared about the history of certain files - but you do want all the other files to _exist_ in that history.

So then you could do "git-rev-list --sparse HEAD -- filelist" and you'd get the minimal history that is still relevant in those files. Any merges that touch anything else than those files will becomes just regular diffs: they'll have been linearized away.

Useful? Quite possibly not. But I felt that simplifying merges was conceptually a very different operation from then compressing a linear history.

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

Ah, I saw (paths && dense) everywhere but there indeed is one that only checks paths to call merge simplification -- I missed that part.

In message <7vd5lnztav.fsf@assigned-by-dhcp.cox.net> you wrote:

"make rpm" does not work for me:

... make -C templates install make[2]: Entering directory `/usr/local/BUILD/git-core-0.99.9/templates' : no custom templates yet find blt blt blt/branches blt/hooks blt/hooks/post-commit blt/hooks/applypatch-msg blt/hooks/commit-msg blt/hooks/post-update blt/hooks/update blt/hooks/pre-applypatch blt/hooks/pre-commit blt/info blt/info/exclude blt/description blt/remotes install -d -m755 '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/' (cd blt && tar cf - .) | \ (cd '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/' && tar xf -) tar: This does not look like a tar archive tar: Skipping to next header tar: Error exit delayed from previous errors make[2]: *** [install] Error 2 make[2]: Leaving directory `/usr/local/BUILD/git-core-0.99.9/templates' make[1]: *** [install] Error 2 make[1]: Leaving directory `/usr/local/BUILD/git-core-0.99.9' error: Bad exit status from /var/tmp/rpm-tmp.96513 (%install)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.96513 (%install)
make: *** [rpm] Error 1

Best regards,

Wolfgang Denk

Wolfgang Denk <wd@denx.de> writes:

I hate it when somebody tells me "it works for me", but I cannot help you here, sorry. I'm no rpm expert and the "make rpm" rule seems to work for me.

In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:

Which environment (Linux distribution) did you test this on? I tried Fedora Core 2 and 4, both with the same result. I get the same problem when building from the git source tree or when using the source RPM.

Best regards,

Wolfgang Denk

Wolfgang Denk <wd@denx.de> writes:

Whatever is running on kernel.org. I think I was once told they run RH-EL but I do not have that e-mail now.

In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:

OK, I found the problem. The key part is this:

[current directory: .../usr/share/git-core/templates/]
    (cd blt && tar cf - .) | \
    (cd '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/' && tar xf -)
    tar: This does not look like a tar archive
    tar: Skipping to next header
    tar: Error exit delayed from previous errors

I have CDPATH set in my shell environment, and bash outputs the pathname of the new working directory on stdout; this gets piped together with the tarball to the "tar xf -", and the second tar complains that the directory name comes unexpected. Test:

-> cd /usr/local/BUILD/git-core-0.99.9/templates -> cd blt /usr/local/BUILD/git-core-0.99.9/templates/blt ->

As a workaround I can simply unset CDPATH, and the build works fine. A more robust build script woul make sure that CDPATH is not set.

Best regards,

Wolfgang Denk

Wolfgang Denk wrote:

Try setting CDPATH, but not exporting it in your shell startup configuration.

Wolfgang Denk <wd@denx.de> writes:

I understand some people like CDPATH in their interactive shells, but I do not see a good reason to export that to random shell scripts you run from your interactive shell session.

We already have a workaround for this exact silliness in git-sh-setup. Probably we also need to do this to our build procedure, I guess. Sigh...

Junio C Hamano wrote:

No kidding. Having 'cd' output stuff to stdout is asking for a million shell scripts to be broken.

	-hpa

Btw, 
 one thing I'd like to see (maybe it already exists and I just have 
overlooked it) is some kind of simple readme or something about the 
different ways to limit the output of the various git commands.

I've several times been surprised to see people not realize that "git-whatchanged" takes a file list to limit the files it is interested in. I also suspect people don't realize that you can limit it by time and version and file list, all at the same time.

IOW, 

	git-whatchanged -p --pretty=short --since="2 weeks ago" v0.99.8..v0.99.9 Makefile

is a valid query: it basically asks for any change to the Makefile in between versions v0.99.8..v0.99.9, _and_ within the last two weeks, and asks to show it as a patch, with the shortened commit message.

Is it useful? The above exact line almost certainly isn't, but variations on the above definitely are. And I suspect a lot of people never even realized you could do something like that.

(The danger with date-based things is that something may be 4 months old, but it only got _merged_ yesterday, so it may be new to _you_. And the --since="2 weeks ago" will not show it, which can be surprising to people who expect things that are new to _them_ to be shown).

The above limiters now work with "git log" and "gitk" too (they've worked for a long time with "git-whatchanged", but only with the new git-rev-list functionality does the name-limiting work for the other commands).

It would be good to make this more well-known, because a lot of people probably end up using git not as developers, but just to follow what is going on. And then the different limiters are some of the most important parts (the date-one is likely the least important one, but limiting by version and name is _very_ important).

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

I've somewhat updated git-rev-list documentation and tried to categorize the options into commit selectors and presentation modifiers. The documentation for commands you mentioned in your message all talk about them describing only frequently used options, and refer the user to rev-list documentation. I am not sure this would be enough.

One good thing to have would be to add a section to Tutorial. Currently we cover building a small project from scratch and have the readers graduate when they learn basic commit swapping, but we do not talk much about archaeology tools.

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

I don't think people really follow the links or think very abstractly at all in the first place.

So I was thinking more of some explicit examples. I actually think every command should have an example in the man-page, and hey, here's a patch to start things off.

Of course, I'm not exactly "Mr Documentation", and I don't know that this is the prettiest way to do this, but I checked that the resulting html and man-page seems at least reasonable.

And hey, if the examples look like each other, that's just because I'm also not "Mr Imagination".

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---

I think most people understand a lot better from practice than from theory, and that an example of real usage is much more likely to make people udnerstand a command than just listing what it can do.

On Sun, 30 Oct 2005, Linus Torvalds wrote:

At some point, we might want to have a series of refs tracking changes to the user's heads over time. Then the right set of arguments could actually handle "what would I have seen on Thursday, when I hadn't pulled since Tuesday, and upstream got some changes on Wednesday that I got on Friday, and it's Saturday now." (That is, Wednesday's commits hadn't hit the local repository yet; the commit that we got to is dated Friday for local purposes, and the latest as of Thursday is dated Tuesday, which is the last time the ref file was modified.)

And we probably don't want to fetch or clone this stuff; I doubt most people want to know the history from somebody else's point of view. At least, I can't think of a use for it that wouldn't be better served by asking whoever for the hash out of their history.

	-Daniel
*This .sig left intentionally blank*

Daniel Barkalow <barkalow@iabervon.org> writes:

Hmph. If you really want something like that, I think you could add a hook support for git-fetch to implement this as automatically created lightweight tags, stashed in $GIT_DIR/fetch-history/, deriving their names from the time of the fetch; clone would grab everything below refs/ but this is deliberately placed outside that hierarchy and won't get copied. By definition, these point at commits reachable from some of your heads (unless the remote repository maintainer is stupid enough to rewind public trees ;-), so fsck-object would not see them but it should not be a problem.

On Mon, 31 Oct 2005, Junio C Hamano wrote:

Probably; I think this should also trigger on commits and such, and it would need a way for rev-list (or rev-parse?) to find the last one before a user-specified date, so that you don't have to figure out when the last change was that contributed to you seeing a particular tree on a given date.

	-Daniel
*This .sig left intentionally blank*

Linus Torvalds <torvalds@osdl.org> writes:

The current "time based limiting" is not very user friendly, so people not knowing the limit-by-time is not a surprise.

Well, it is not a valid query ;-) Nobody implemented --since yet, but you could spell it --max-age. It would not grok "2 weeks ago" though.

With the attached patch, you could at least do:

	git log --max-age='2005-10-25' v0.99.8..v0.99.9 Makefile

There are still a couple of things that bothers me.

(1) The underlying workhorse, rev-list, takes max-age and
    min-age.  While these names are logically correct, it feels
    a bit hard and counterintuitive when deciding which one to
    use in order to ask "what are the ones that happened after
    Wednesday last week?".  The query talks about the commits
    being young, so --max-age=2005-10-26 is the right query
    (i.e. "I want to discard things that are older than that
    time"), but as soon as I type "max", my mind starts
    comparing date strings, and surely 2005-10-21 is smaller
    than 2005-10-26 and I am saying 2005-10-26 is the max, which
    confuses me to think that 2005-10-21 would be included in
    the result (it would not be -- we are talking about age, so
    2005-10-21 one is older, which means its age is greater than
    specified). It takes some mental effort to do this, at least
    for me.

    I *hate* to suggest this change at this late stage of the
    game, but maybe they should be renamed or at least acquire 
    less confusing synonyms, perhaps?

	--max-age	= --min-timestamp, --since
        --min-age	= --max-timestamp, --until

(2) If I run the above --max-age query, the last commit
    displayed is this one:

        commit f3123c4ab3d3698262e59561ac084de45b10365a
        Author: Junio C Hamano <junkio@cox.net>
        Date:   Sat Oct 22 01:28:13 2005 -0700

    This is because the age limit uses commit date (which is a
    sensible thing to do) while the display shows author date.
    To an uninitiated, this takes some explanation and
    justification (i.e. counterintuitive again).

    Incidenally, I have not found a way to prettyprint the
    commit date; --pretty=raw gives that information, but in
    really raw format.  --pretty=full does not even give any
    timestamp.

    Again I *hate* to suggest this, but maybe --pretty=full
    should show both author and commit timestamp as well, like
    this?

        commit f3123c4ab3d3698262e59561ac084de45b10365a
        Author: Junio C Hamano <junkio@cox.net>
        A-Date: Sat Oct 22 01:28:13 2005 -0700
        Commit: Junio C Hamano <junkio@cox.net>
        C-Date: Wed Oct 26 12:37:49 2005 -0700

-- >8 -- cut here -- >8 --

Earlier we just did atoi to accept these parameters, which meant that the user needed to specify the raw UNIX time format to use them.

This still does not make it accept '2 weeks ago', but at least it now can take --max-age='2005-10-15', which is a start.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 rev-list.c |   19 +++++++++++++++++--
 1 files changed, 17 insertions(+), 2 deletions(-)

applies-to: 0c9683fe37dbc43713faaa15fcce14bfe5621bba 9dc13af3f916803d270d3387032eb0e91b940417

On Wed, 2 Nov 2005, Junio C Hamano wrote:

Have you tried it? 

"--since" _works_.

All the magic is in "git-rev-parse". Try it.

No. Really. _try_ it. You can do

	git log --since="September 25"

And ItJustWorks(tm).

No patches needed. Anywhere. It's worked for quite a long time too. Since commit c1babb1d65e034a058c14379eabec8eb374757ca, to be exact.

    [PATCH] Teach "git-rev-parse" about date-based cut-offs

Just use it.

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

Ahhhh.  I missed that.  Thanks.

-- >8 -- cut here -- >8 -- Document --since and --until options to rev-parse.

The usability magic were hidden in the source code without being documented, and even the maintainer did not know about them ;-).

Signed-off-by: Junio C Hamano <junkio@cox.net>
---