[ANNOUCNE] GIT 1.1.0

The latest feature release GIT 1.1.0 is available at the usual places:

	http://www.kernel.org/pub/software/scm/git/

	git-1.1.0.tar.{gz,bz2}			(tarball)
	RPMS/$arch/git-*-1.1.0-1.$arch.rpm	(RPM)

This contains all the fixes present in 1.0.8, with the following enhancements:

 - "git clone -o $name" can name a branch other than "origin" to
   be used to keep track of upstream (Johannes).

 - Easier shared repository setup (Johannes).

 - "git describe" command (Linus).

 - "git --version" from an interim snapshot gives a more
   descriptive version name than "1.0-GIT" (Linus).

 - "git whatchanged" shows abbreviated object names by default.

 - "git checkout -- paths" and "git checkout treeish paths" use
   cwd relative pathname and work from a subdirectory.

 - "git checkout [-b newbranch] branch" works from a
   subdirectory and works on the entire tree.

 - "git ls-tree" shows cwd relative pathnames by default; full
   pathnames can be obtained with --full-name, just like "git
   ls-files" (Linus and me).

 - "git send-pack" and "git push" notice when the remote end
   refuses to update a ref (e.g. hooks/update) and exits with an
   error.  This hopefully would help Cogito as well.

 - "git fetch" and "git pull" automatically follows remote tags
   while tracking branches.

 - "git ls-files --others" can be used with "--directory" option
   to omit the contents of directories without any tracked file
   but instead to show the directories themselves (Linus).  "git
   status" uses this to unclutter "Untracked files" section.

 - Optimized "git pack-redundant" (Lukas).

 - "git daemon --base-path=/pub/git" can reroot the directory
   tree exposed to the outside world, similar to DOCUMENT_ROOT
   (Pasky).

 - "git cherry" can be told not to show everything we have (Yann
   Dirson).

 - git URL can use [IPv6address/IPvFuture] literal addresses
   (Hideaki).

On Sun, Jan 08, 2006 at 05:20:49PM -0800, Junio C Hamano wrote:

Why not support debian? I see the debian directory is outdated.

Coywolf Qi Hunt <qiyong@fc-cn.com> writes:

I think that was discussed already this year, so look in the list archive for the past 10 days or so please before asking.

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

Especially, please see this thread:

    http://marc.theaimsgroup.com/?l=git&m=113576889301331 

I haven't received any patches to re-add debian/ directory from Gerrit since I removed it, and I do not expect nor wish to get one. I respect Gerrit's request not to ship debian/ directory myself.

If you want to see deb packages at kernel.org built by me, you need to convince both Gerrit and me with a workable workflow that does not add extra burden on us and avoids confusion.

A starting point might be for me to slave debian/ part from Gerrit, updating debian/changelog with only X.Y.Z-0 entries by me, and publish X.Y.Z-0 packages at kernel.org.

On 1/9/06, Junio C Hamano <junkio@cox.net> wrote:

Like, yesterday ;-)

Anyway, I have to report that I'm now a happy backports.org user for all the git-core packages on my production servers. And sid has your git-core fix too, if you happen to be feeling unstable.

Many thanks to Gerrit and whoever's done the backports.org one.

martin

On Mon, Jan 09, 2006 at 02:38:30AM -0800, Junio C Hamano wrote:

Thanks.  

I'm afraid, I can't always keep up with the git development speed. So it's quite possible that a debian/ directory in the git repository gets temporarily outdated and possibly broken, and I'm not available to update immediately.

Starting with version 1.0.8-1, this should work if you want to build Debian packages on sid or sarge from the maint or master branch (or the v1.1.1 tag) yourself:

 $ git checkout maint
 $ wget -q -O- http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.0.8-1.diff.gz |
 gunzip |patch -p1
 patching file debian/changelog
 patching file debian/control
 patching file debian/copyright
 patching file debian/rules
 patching file debian/git-core.docs
 patching file debian/git-doc.docs
 patching file debian/implicit
 patching file debian/git-core.postinst
 patching file debian/git-core.prerm
 $ chmod 755 debian/rules
 $ debchange -v 1.1.1-0.maint20060111 'git maint 20060111'
 $ dpkg-buildpackage -b -rfakeroot -uc -us
 [...]
 $ 
 
HTH, Gerrit.

I installed 1.1.0 today and it shows me

$ git --version git version 1.0.GIT

Mika

lamikr wrote:

You did not have git-describe installed prior to building 1.1.0. If you re-install right on top the one you did today the version-file will be generated correctly.

lamikr <lamikr@cc.jyu.fi> writes:

Ah, sorry, and thanks for catching this. RPM building procedure is somewhat tricky, and I failed to catch this bug. Fixed in my tree --- this calls for an early 1.1.1 release I guess.

On the other hand, if you are building from the source, what Andreas said applies, and in addition you need to fetch v1.1.0 tag before building; otherwise the versioning mechanism would not notice you are building v1.1.0.

I was not using git for fetching git sources, I have build from the git 1.1.0.tar.bz2.

Did you mean that things should work after 1.1.1 is released? I tried to fresh build and install of 1.1.0 on top of the previous 1.1.0 build but "git --version" is still displaying me "git version 1.0.GIT"

Mika

lamikr wrote:

Not unless you build from the git-repo, no.

Snapshots will fail to set the "proper" version every time, because the 
GIT-VERSION-FILE: is a forced target and even if git-describe is present 
it will find neither tags nor HEAD.

I have no solution to this, apart from rewriting the Makefile on the fly whenever a release tarball is created.

Andreas Ericsson <ae@op5.se> writes:

Well, there is always an option to update the fallback version number hardcoded in GIT-VERSION-GEN script, but that kind fo defeats the whole idea of the current setup, so...

Hi,

On Mon, 9 Jan 2006, Junio C Hamano wrote:

The whole idea of the current setup is working only if you have a git repository of git. Kind of a chicken-egg, right?

So, why not just include GIT-VERSION-FILE in the tarball, and let GIT-VERSION-GEN check if there exists .git or $GIT_DIR before trying its voodoo?

---

lamikr <lamikr@cc.jyu.fi> writes:

You need to build from a git repository for these automated version numbers to work, and this will *not* change post 1.1.1.

But with the patch I sent out earlier, you should be able to:

	$ VN=1.1.1 make

in a non-git repository (e.g. an untarred directory from a tarball). What the patch fixes is to fix it for RPM binary packages.

I expect that people building from the source do so from a git repository not from a tarball, except when bootstrapping, so hopefully this should not be too much of a problem.

Junio C Hamano wrote:

Tarballs really should work as-is... the easy way to deal with that is to have the tarball make script generate a version file which isn't part of the git tree.

I'll send a patch under a separate cover.

	-hpa

"H. Peter Anvin" <hpa@zytor.com> writes:

Thanks.