[ANNOUCNE] GIT 1.1.0

[ANNOUCNE] GIT 1.1.0

[Junio C Hamano]

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

Re: [ANNOUCNE] GIT 1.1.0

[Coywolf Qi Hunt]

On Sun, Jan 08, 2006 at 05:20:49PM -0800, Junio C Hamano wrote:
> 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)

Why not support debian? I see the debian directory is outdated.
-- 
Coywolf Qi Hunt

Re: [ANNOUCNE] GIT 1.1.0

[Junio C Hamano]

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

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

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

Re: [ANNOUCNE] GIT 1.1.0

[Junio C Hamano]

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

> Coywolf Qi Hunt <qiyong@fc-cn.com> writes:
>
>> Why not support debian? I see the debian directory is outdated.
>
> I think that was discussed already this year, so look in the
> list archive for the past 10 days or so please before asking.

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.

Re: [ANNOUCNE] GIT 1.1.0

[Martin Langhoff]

On 1/9/06, Junio C Hamano <junkio@cox.net> wrote:
> > I think that was discussed already this year, so look in the
> > list archive for the past 10 days or so please before asking.

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

Re: [ANNOUCNE] GIT 1.1.0

[Gerrit Pape]

On Mon, Jan 09, 2006 at 02:38:30AM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > Coywolf Qi Hunt <qiyong@fc-cn.com> writes:
> >> Why not support debian? I see the debian directory is outdated.
> >
> > I think that was discussed already this year, so look in the
> > list archive for the past 10 days or so please before asking.
> 
> 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.

Thanks.  

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

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.

Re: [ANNOUCNE] GIT 1.1.0

[lamikr]

> - "git --version" from an interim snapshot gives a more
>   descriptive version name than "1.0-GIT" (Linus).
>  
>
I installed 1.1.0 today and it shows me

$ git --version
git version 1.0.GIT

Mika

Re: [ANNOUCNE] GIT 1.1.0

[Andreas Ericsson]

lamikr wrote:
>>- "git --version" from an interim snapshot gives a more
>>  descriptive version name than "1.0-GIT" (Linus).
>> 
>>
> 
> I installed 1.1.0 today and it shows me
> 
> $ git --version
> git version 1.0.GIT
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [ANNOUCNE] GIT 1.1.0

[Junio C Hamano]

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

>> - "git --version" from an interim snapshot gives a more
>>   descriptive version name than "1.0-GIT" (Linus).
>>  
>>
> I installed 1.1.0 today and it shows me
>
> $ git --version
> git version 1.0.GIT

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.

Re: [ANNOUCNE] GIT 1.1.0

[lamikr]

>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

Re: [ANNOUCNE] GIT 1.1.0

[Andreas Ericsson]

lamikr wrote:
>>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?


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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [ANNOUCNE] GIT 1.1.0

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

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

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

Re: [ANNOUCNE] GIT 1.1.0

[Johannes Schindelin]

Hi,

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

> Andreas Ericsson <ae@op5.se> writes:
> 
> > I have no solution to this, apart from rewriting the Makefile on the
> > fly whenever a release tarball is created.
> 
> 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...

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?

---

diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 845b9dc..b65b214 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -2,6 +2,9 @@
 
 GVF=GIT-VERSION-FILE
 
+test -z "$GIT_DIR" && GIT_DIR=.git
+test -d "$GIT_DIR" || exit 0
+
 VN=$(git-describe --abbrev=4 HEAD 2>/dev/null) || VN=v1.0.GIT
 VN=$(expr "$VN" : v'\(.*\)')
 if test -r $GVF

Re: [ANNOUCNE] GIT 1.1.0

[Junio C Hamano]

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

> 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"

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.

Re: [ANNOUCNE] GIT 1.1.0

[H. Peter Anvin]

Junio C Hamano wrote:
> lamikr <lamikr@cc.jyu.fi> writes:
> 
>>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"
> 
> You need to build from a git repository for these automated
> version numbers to work, and this will *not* change post 1.1.1.
> 

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

Re: [ANNOUCNE] GIT 1.1.0

[Junio C Hamano]

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

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

Thanks.