# [ANNOUNCE] GIT 0.99.7b 9 messages from 2005-09-23 to 2005-09-24. Participants: Junio C Hamano, walt, H. Peter Anvin, Joel Becker, Petr Baudis. Thread: https://gitlist.dev/t/1919 ## Junio C Hamano, 2005-09-23 06:18 Subject: [ANNOUNCE] GIT 0.99.7b Message-ID: <7voe6ki9x7.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7voe6ki9x7.fsf%40assigned-by-dhcp.cox.net ``` GIT 0.99.7b Contains the following post-0.99.7a fixes: - Commit walker performance fix, mostly during walking commits in a downloaded packfile, thanks to Sergey Vlasov. - Squelch unnecessarily alarming error message from fetch and clone over rsync transport, when remote repository does not borrow anything from other repositories. I've seen enough people got annoyed/worried/alarmed after seeing this one on both git and linux-kernel list. - Documentation was not rebuilt before installation, noticed by Randal L Schwartz. - Fetching of objects over http transport got a bit safer. Tarballs, RPMs and Debs are available at http://kernel.org/pub/software/scm/git/ Or, if you use git already: {http,rsync}://kernel.org/pub/scm/git/git.git/ ``` ## walt, 2005-09-23 13:11 Subject: Re: [ANNOUNCE] GIT 0.99.7b Message-ID: URL: https://gitlist.dev/e/dh0uur%24h4g%241%40sea.gmane.org In-Reply-To: <7voe6ki9x7.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > GIT 0.99.7b [...] > Or, if you use git already: > > {http,rsync}://kernel.org/pub/scm/git/git.git/ I did it that way and now I see this: $git --version git version 0.99.7 This is a bit confusing. Did I upgrade or downgrade? Maybe the version string should contain the same kind of hexadecimal string that Linus is appending to his kernel version? ``` ## H. Peter Anvin, 2005-09-23 19:44 Subject: Re: [ANNOUNCE] GIT 0.99.7b Message-ID: <43345B11.4000009@zytor.com> URL: https://gitlist.dev/e/43345B11.4000009%40zytor.com In-Reply-To: ``` walt wrote: > Junio C Hamano wrote: > >> GIT 0.99.7b > > [...] > >> Or, if you use git already: >> >> {http,rsync}://kernel.org/pub/scm/git/git.git/ > > > I did it that way and now I see this: > > $git --version > git version 0.99.7 > > This is a bit confusing. Did I upgrade or downgrade? > Maybe the version string should contain the same kind > of hexadecimal string that Linus is appending to his > kernel version? > Or just call it 0.99.7.1 and .2 or 0.99.8 and .9. -hpa ``` ## Junio C Hamano, 2005-09-23 20:46 Subject: Re: [ANNOUNCE] GIT 0.99.7b Message-ID: <7v8xxnbjhl.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xxnbjhl.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` walt writes: > Junio C Hamano wrote: >> GIT 0.99.7b > [...] >> Or, if you use git already: >> {http,rsync}://kernel.org/pub/scm/git/git.git/ > > I did it that way and now I see this: If you fetched v0.99.7b tag and built it, hopefully it should say 0.99.7b otherwise you found a big bug. If you pulled from "master" branch, then --version would still say 0.99.7; I agree it is confusing. On the other hand, I do not think we would want to increment the version string with every little changes, so... ``` ## Joel Becker, 2005-09-23 20:52 Subject: Re: [ANNOUNCE] GIT 0.99.7b Message-ID: <20050923205242.GY27375@ca-server1.us.oracle.com> URL: https://gitlist.dev/e/20050923205242.GY27375%40ca-server1.us.oracle.com In-Reply-To: <7v8xxnbjhl.fsf@assigned-by-dhcp.cox.net> ``` On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote: > If you pulled from "master" branch, then --version would still > say 0.99.7; I agree it is confusing. On the other hand, I do > not think we would want to increment the version string with > every little changes, so... Every little change, no. But ANNOUNCEd releases should be considered 'major' from this point of view. I don't think a little extra version number incrementing is too big a deal. Joel -- Life's Little Instruction Book #451 "Don't be afraid to say, 'I'm sorry.'" Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 ``` ## Petr Baudis, 2005-09-23 20:54 Subject: Re: [ANNOUNCE] GIT 0.99.7b Message-ID: <20050923205436.GF10255@pasky.or.cz> URL: https://gitlist.dev/e/20050923205436.GF10255%40pasky.or.cz In-Reply-To: <7v8xxnbjhl.fsf@assigned-by-dhcp.cox.net> ``` Dear diary, on Fri, Sep 23, 2005 at 10:46:14PM CEST, I got a letter where Junio C Hamano told me that... > If you pulled from "master" branch, then --version would still > say 0.99.7; I agree it is confusing. On the other hand, I do > not think we would want to increment the version string with > every little changes, so... In ELinks, we pseudo-bump the version number from v1.2.3 to v1.2.3.CVS (now v1.2.3.GIT) right after the release. In Cogito, we append the commit ID current at the time of build to cg-version output (if it was built from GIT-tracked working directory). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Petr Baudis, 2005-09-23 20:55 Subject: Re: [ANNOUNCE] GIT 0.99.7b Message-ID: <20050923205558.GG10255@pasky.or.cz> URL: https://gitlist.dev/e/20050923205558.GG10255%40pasky.or.cz In-Reply-To: <20050923205242.GY27375@ca-server1.us.oracle.com> ``` Dear diary, on Fri, Sep 23, 2005 at 10:52:42PM CEST, I got a letter where Joel Becker told me that... > On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote: > > If you pulled from "master" branch, then --version would still > > say 0.99.7; I agree it is confusing. On the other hand, I do > > not think we would want to increment the version string with > > every little changes, so... > > Every little change, no. But ANNOUNCEd releases should be > considered 'major' from this point of view. I don't think a little > extra version number incrementing is too big a deal. The point is that the bugfix releases aren't tagged on the master branch but on the maint branch. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Junio C Hamano, 2005-09-23 21:45 Subject: Re: [ANNOUNCE] GIT 0.99.7b Message-ID: <7v4q8ba260.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v4q8ba260.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20050923205242.GY27375@ca-server1.us.oracle.com> ``` Joel Becker writes: > On Fri, Sep 23, 2005 at 01:46:14PM -0700, Junio C Hamano wrote: >> If you pulled from "master" branch, then --version would still >> say 0.99.7; I agree it is confusing. On the other hand, I do >> not think we would want to increment the version string with >> every little changes, so... > > Every little change, no. But ANNOUNCEd releases should be > considered 'major' from this point of view. I don't think a little > extra version number incrementing is too big a deal. Yes, 'maint' has the GIT_VERSION bumped in the Makefile (0.99.7a, 0.99.7b) and that is propagated to 'git --version'. What I was having trouble was what to do with the stuff we put in the 'master' between 0.99.7 and 0.99.8. 'maint' was *forked* from 0.99.7, not just tagging some midpoint in 'master' line for obvious reasons, so the 'git --version' on the 'master' side does not have much to do with what happens on the 'maint' side. We could say, immediately after 0.99.7 is released, bump the GIT_VERSION in the 'master' branch to 0.99.8-pre or something like that. We need to pick something that sorts after '0.99.7a', '0.99.7b', etc. and before '0.99.8'. Somebody needs to come up with what is appropriate for version number ordering scheme employed by binary packaged distributions. I know 0.99.8-pre does not sort before 0.99.8 on Debian. Probably '0.99.7zzz'? ``` ## Junio C Hamano, 2005-09-24 21:59 Subject: Re: [ANNOUNCE] GIT 0.99.7b Message-ID: <7v64squnyu.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v64squnyu.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20050923205436.GF10255@pasky.or.cz> ``` Petr Baudis writes: > Dear diary, on Fri, Sep 23, 2005 at 10:46:14PM CEST, I got a letter > where Junio C Hamano told me that... >> If you pulled from "master" branch, then --version would still >> say 0.99.7; I agree it is confusing. On the other hand, I do >> not think we would want to increment the version string with >> every little changes, so... > > In ELinks, we pseudo-bump the version number from v1.2.3 to v1.2.3.CVS > (now v1.2.3.GIT) right after the release. That's a nice way of doing it. Maybe I should follow suit. ```