login
Search
The latest feature release GIT 1.5.4 is available at the usual
places:http://www.kernel.org/pub/software/scm/git/
git-1.5.4.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.4.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.4-1.$arch.rpm (RPM)It has been an unusually long cycle. 5 months since the last
feature release 1.5.3 was really a bit too long.But I hope it was worth waiting for. Thanks everybody for
working hard to improve it.Changes since v1.5.3:
1595 non-merge commits
165 contributors
684 files changed, 70435 insertions, 28984 deletions----------------------------------------------------------------
GIT v1.5.4 Release Notes
========================Removal
-------* "git svnimport" was removed in favor of "git svn". It is still there
in the source tree (contrib/examples) but unsupported.* As git-commit and git-status have been rewritten, "git runstatus"
helper script lost all its users and has been removed.Temporarily disabled
--------------------* "git http-push" is known not to work well with cURL library older
than 7.16, and we had reports of repository corruption. It is
disabled on such platforms for now. Unfortunately, 1.5.3.8 shares
the same issue. In other words, this does not mean you will be
fine if you stick to an older git release. For now, please do not
use http-push from older git with cURL older than 7.16 if you
value your data. A proper fix will hopefully materialize in
later versions.Deprecation notices
-------------------* From v1.6.0, git will by default install dashed form of commands
(e.g. "git-commit") outside of users' normal $PATH, and will install
only selected commands ("git" itself, and "gitk") in $PATH. This
implies:- Using dashed forms of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially...
Congratulation to all Git developers and special thanks to Junio Hamano
whose dedication and efforts cannot be overestimated. GIT 1.5.4 may not
appear a big step in terms of version numbers, but it is really a big
step in making GIT even much more user friendly. Thanks to everyone who
contributed to this release.Dmitry
-
The msysgit setup is available at:
http://code.google.com/p/msysgit/downloads/
Steffen
-
Why do I have to accept the GPL to install msysgit?
Only the "NO WARRANTY ..." should be required, GPL is only required for
distribution (and you could make that information available at install).--=20
Luciano Rocha <luciano@eurotux.com>
Eurotux Inform=E1tica, S.A. <http://www.eurotux.com/>
Section 1 of the GPL requires to "give any other recipients of the
Program a copy of this License along with the Program." AFAIK, showing
the License during installation is the traditional way to do so on
Windows. Please, note that the GPL clearly states that distribution is
possible "provided that you conspicuously and appropriately publish on
each copy an appropriate copyright notice and disclaimer of warranty."
IANAL, but it appears to me that if an installer that does not follow
the traditional way (for the target system) of publishing the copyright
notice, may be found in violation of the later requirement, and thus
any such distribution may deem as unlawful.So, if you think about creating your own installer for Git, don't forget
to consult to your lawyer...Dmitry
-
Hi,
Because that's the only license you have to use git.
Get over it, or use another SCM,
Dscho "who hates license wars"-
I think his point is that you don't need to "accept" anything to be
allowed to use GPLed software. Presenting the GPL as a click-through
licence on installation implies that you should read it carefully to
see what limits are imposed on you, when in fact the GPL explicitly
allows you to "run the program, for any purpose" (http://www.gnu.org/philosophy/free-sw.htmlNo war for you!
Eyvind Bernhardsen
-
I like and use GPL, but I won't force my users to accept the GPL in
I'm not battling over licenses.
--=20
Luciano Rocha <luciano@eurotux.com>
Eurotux Inform=E1tica, S.A. <http://www.eurotux.com/>
What are they forced into if they indeed only want to _use_ Git?
They nevertheless must be made aware of the rules they have to follow in
case the idea of redistributing it crosses their mind.Nicolas
-
No, because redistributing software is always illegal unless explicitly
permitted. The GPL explicitly permits it, so they have to find that
piece of license, read it, determine "oh this is ok then" and then go
ahead and email it to their friends.Seriously though, the only thing I expect nobody would want to is
that some company starts distributing git as their own scm, under a
different license and probably closed-source too. EFF can provide
lawyer help for such cases. Such a company would obviously read the
license and realise that it's impossible for them to do so.--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
The msys git installer forces me to accept the GNU GPL in order to
proceed.Of course, I can use another installer, or compile my own set of
I don't dispute that, only that I can't continue with the install unless
I click on "I Accept" to the GNU GPL.--=20
Luciano Rocha <luciano@eurotux.com>
Eurotux Inform=E1tica, S.A. <http://www.eurotux.com/>
Simple question: Do you accept it or not?
Steffen
-
Then, simply changing the button text from "I accept" to "Continue"
should be OK?Nicolas
-
It has two radio-buttons with:
* "I accept the agreement"
* "I do not accept the agreement"The latter one is the one selected by default, and until the user
selects the "I accept", the "Next>" button is greyed-out.What I would suggest would be to remove both radio-buttons, and just leave
the "Next>" button active.--=20
Luciano Rocha <luciano@eurotux.com>
Eurotux Inform=E1tica, S.A. <http://www.eurotux.com/>
Hi,
I consider this bike-shedding, git@vger.kernel.org being the wrong mailing
list to discuss this (and as a matter of fact, the msysgit list is also
not the correct forum for discussing such legal/personal issues), and
besides, the msysgit installer will not be changed in this respect.Hth,
Dscho-
I don't care much about that. I only installed the msysgit to have a
binary copy on my pen for using on friends' computers.I only thought it an unnecessary step, and w/o it the barrier-to-entry
would decrease slightly, as some people are put off by EULA.I never expect this level of hostility and I apologize if my question
sounded as offensive.I respect the msysgit author/packager, and I thank him for his work.
--=20
Luciano Rocha <luciano@eurotux.com>
Eurotux Inform=E1tica, S.A. <http://www.eurotux.com/>
Hi,
The fine points on why installing it onto your computer is not a
distribution are just lost on me.Besides, if you do not like that our installer shows the GPL, just go and
make your own (but be sure to shell out money to your lawyer of choice to
confirm that the GPL allows you to do that).The Git installer of msysGit will always show the GPL, and have the user
accept it.'nuff said,
Dscho
-
I may be missing the details because I do not do Windows myself,
but if you are discussing the "end user binary distribution"
one, then I think:* It is a mistake if you do not to show GPL, as you are
redistributing GPL code in a binary form and you need to tell
the end user his rights (e.g. he can request source for it,
the source is found at a well known location, etc.)* The restriction on redistribution of modified program would
probably not apply (unless the receiver hacks binary) to most
casual users, so making the label say "I Accept" feels a bit
silly (but still is technically correct). As Nico suggested,
"Continue" may be fine here, as long as the message already
says "this program is distributed under this license you are
looking at".I recall you had another installer that gives the full
development environment for hack on "git" with a clone of the
git repository. I do not know if you still offer that
installer, but "I Accept" would be very appropriate for that
one.-
Hi,
Yes, the full installer does not (yet) ask for acceptance of the GPL,
basically because I am too lazy, and also because I expect developers to
actually read the notices in the copyright section in the source code,
should they modify the source.The reasoning for showing the GPL in the Git installer I cannot explain,
because I was not part of it. However, I am very much in favour, for two
reasons:- the end users should really know that the software is licensed in a
pretty free way. Most of the users will have read about "the GPL", and
know what it says without reading it. Others may see it for the first
time, and be astonished that such a license exists, and actually covers
a useful program.- _every_ serious Windows program comes with a click-through license. We
just don't want to be left behind.- even if it would be not necessary to accept the license (which I am not
at all sure about, but do not care enough to learn about it, either), I
am not amused by somebody I do not know of, and who did not share
anything with me that I know of, asking me to remove that license
dialog.If you are not okay with accepting a tit-for-tat license, well... I'll
not give you "tat".So there is really nothing that I can think of, which would change my mind
about that "issue".Ciao,
Dscho-
I think you need to grow a thicker skin.
It does not matter if the person is somebody you know or you
have shared with. I'd grant you that Luciano could have been
more diplomatic when he started his message, but I'd agree that
it is silly to refuse to install an end user program unless the
end user agrees to GPL that governs how its sources can and
cannot be used, especially if the installer does not even
install the sources to the software.In other words, consider his message as a bug report to the
installer.I think removing the license dialog is a bad idea. You need to
tell the end-user about his rights, and one of the things is
that he can get source to git under the terms of GPLv2. The bug
is not about showing the license, but is about refusing toThe tit-for-tat in GPLv2 which we use is about "I gave you my
source. If you are going to work on my source and distribute
the result, you must promise me that I have the access to that
modified source of yours. Otherwise you cannot work on it and
distribute the result."Showing the GPL (which says it does not cover the mere use of
the software) and then asking if the user accepts is merely
about:"If and only if you are going to modify and distribute
it, you must abide by the rules. Do you understand?"The valid answers to the question would include "I understand",
"I do understand it, I do not like it, but I am not going to
modify and distribute it anyway", and even "I do not understand
it, but I just want to use it". In any case, refusing to
install unless the user says "I agree" feels silly.If I were writing the installer, I would say in the dialog, "git
is distributed under GPL so you have the usual rights any GPLed
software comes with", optionally show the GPL, and have a single
"Continue" button.-
Actually, the GPL is applied to the binary form too, and it
prescribes how the program can be redistributed. There is no
restriction on how the user can run the program, but we still
must give to the user a copy of GPL in the appropriate way.
Besides, the user should acknowledge that he or she is warned
the program is provided "AS IS" without warranty of any kind.
If the user cannot accept that, he or she should not run the
program.So, the current Git installer fully adheres to GPL requirements
and installs Git in the traditional for Windows way. I don't
see anything here that can be considered as bug.Dmitry
-
Just out of curiosity - does this mean that MacPorts (a fink-like
package manager for OS X) ought to display the license while
installing? Or does that somehow not apply here?
-
Unfortunately, I don't know much about OS X and the packet manager
you mentioned, but from common sense, I would say you should place
the copyright notice at the place where users traditionally can find
it when install other programs on that platform...Dmitry
-
Well, the rule in the license is "provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice and
disclaimer of warranty".What exactly that means is not something people generally agree about.
What some consider "conspicuous", others consider very much "rude and
inappropriate", so "conspicuously and appropriately" is simply something
that people have to find a balance for.In general, your common sense interpretation is probably the best legal
one too: place the copyright notice about as conspicuously as the user
would be expect it to be placed.On traditional UNIX platforms (including Linux), that tends to be "make it
a README file or perhaps note it in the man-pages". On OS X and Windows,
what is considered appropriate is probably different.There is definitely no *requirement* of annoying pop-up click-throughs. In
fact, I would say that something like that would be wholly in-appropriate
and not at all in the spirit of the GPL on UNIX, where people expect
installation to not be an interactive process.[ Related side note: but at the same time, if a developer actually starts
adding those kinds of pop-ups, it's sometimes arguably against the GPL
to remove them!See 2(c), which says that you have to announce the license when an
interactive program is run *if* the announcement was there originally!So I actually would encourage people who do GPL'd programs to never add
those kinds of annoying interactive license notices, because they can be
hard to remove legally! ]In short: it's a cultural issue which way you want to go, but some care
should be taken. I come from a Unix background, so I find graphical
installs be really really annoying, and if I see a popup, I just *hate*
it. I'd consider it obnoxious and irritating as hell. But I suspect that
Windows people really do expect it.Linus
-
Yeah. Why not just rather than the whole ok/cancel discussion, go with a
single button saying "good for me!" and be done with it.IOW, the license thing should be considered *informational* rather than a
choice. Because to a user, that's exactly what the GPL is.Linus
-
Ok, if there are no further objections, we'll do that.
Sebastian,
can we easily modify the license dialog with Inno Setup?
The license should be displayed and a single click should
be sufficient to "continue".Steffen
-
Hi,
It looks like "LicenseFile" is a special variable in InnoSetup, and it is
not _that_ easy to change it to an "I am okay with it; I read it" text.
Maybe something like the release notes would be good ("Source: ... Flags:
isreadme")?In any case, I think this discussion has outlived its usefulness: there
are _many_ _more_ pressing issues with msysGit.Having said that, I am really amazed that we seem to finally have picked
up some Windows experts... So my hopes are high for a catch-up with
git.git that will lead to an msysGit-from-git.git soon!For example, the git-svn issue seems resolved now (thanks Simon, Christian
and Mike -- I call them the "S-C-M" gang). If we can squeeze better
performance out of it, all the better.git-cheetah also appears to gather way nicely: it seems that the only
obstacle is my own laziness (and admittedly, lack of time) to review the
changes and push them!Hoist the anchors,
Dscho-
Actually, the modification was trivial, I'm now using "InfoBeforeFile"
instead of "LicenseFile". I've pushed Steffen the change.--
Sebastian
-
I pushed the commit to msysgit.git onto branch work/innosetup:
http://repo.or.cz/w/msysgit.git?a=commitdiff;h=f66b8578722
I'll test it later and will include it in the next release if
nobody raises further objections.Steffen
-
I beg your pardon? I never asked you such thing. My first e-mail was,
verbatim:
-- begin --
Why do I have to accept the GPL to install msysgit?Only the "NO WARRANTY ..." should be required, GPL is only required for
distribution (and you could make that information available at install).
-- end --Any next e-mail in reply to this thread, from me, were only suggestions
and reasonings for *not requiring acceptance*, not for removing theI never said I was. I mean, would I had sent a patch to this list if I
I was asking for the reasons for the installer being like it is, not for
you to change your mind.--=20
Luciano Rocha <luciano@eurotux.com>
Eurotux Inform=E1tica, S.A. <http://www.eurotux.com/>
Hi,
I am sorry: I misunderstood.
Two reasons: we stay on the safe side (because no lawyer could now
possible say that we forgot to present the license), and we want to give
the Git installer some "professional" look-and-feel ;-)Please ignore my comments that offended you.
Ciao,
Dscho-
It is not unreasonable, I suppose, to display the license text in the
installer program, though I think it is sufficient to provide the
license in a simple LICENSE file, and it is hard to imagine anyone
actually wanting to read the license text while installing git.I think it is not a good idea for a nice free software program like git
to show license text in a click-wrap way, as that will only give
credence to click-wrap licenses.As far as the "professional" look and feel, rather than make git seem
more like the usual proprietary program (if you wanted to go that route,
perhaps you should bundle a root kit/"copy protection
mechanism"/adware/spyware like companies will often do :) ), I'd suggest
making it seem much _better_ than the usual proprietary program: the
user can look at the opportunity to install a program without having to
"agree" to onerous terms as a breath of fresh air.As has been mentioned, installing and running the program is permitted
by fair use, and thus assuming he already has a copy of the software,
legally there is no need for the user to agree to any additional terms
before using the software. The traditional EULA attempts to use
technical means to prevent the user from exercising his fair use rights;
in particular, it attempts to force the user to agree to certain terms
for essentially no compensation, as he already has fair use permission
to use the software anyway. Naturally, such use of technical means is
completely antithetical to the idea of free software.--
Jeremy Maitin-Shepard
-
I agree.
Steffen
-
Congratulations to everybody who contributed to this release, and
special thanks to you Junio for coordinating it all (and contributing
a large hunk of the code yourself).Cheers,
Wincent-
Thank *you* for doing superb job maintaining git.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2-
Hmm...
There are supplimentary tools, such as 'git-dch' and
'git-buildpackage' which kind of supplied quasi-seamless extention to
git family of tools, are they going to be affected in some way?regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
-
Hi,
When I was idly googling around for traces of VCS and popularity,
noticed that Git is actually pretty popular. Googling for 'gitweb'
and 'viewcvs' and other comparative web-frontend variants floating in
the cyberspace I get these number of hits (in rough estimate) :10000000 CVS
1000000 SVN
100000 Git
10000 Mercurial / Darcs
1000 BzrThis is crude, and I'm sure someone else will come up with a better
estimate. The point is, when there are so many users, people don't
read the lists or the changelog, but rely on manuals, and be surprisedI was wondering why I use the git-xxx format so much (in muscle, and
in scripts). And realized I have the following reasons:1. That's the form documented in the manual pages (generated from asciidoc)
2. That's the name manual pages are in.
3. Linus said it's better (3 years ago), and I thought so too.
(Situation has changed, bash has better completion for 'git'
commands, so that's no longer valid)4. There was a GNU Interactive Tools with the same name 'git', so it
was better to avoid confusion then. (This is still the case with
Debian, where the sysadmin can choose whether to make 'git' (GNU
Interactive Tools) the default, or our beloved git.5. There are many documentations floating around.
6. I'm used to it.
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
-
http://www.google.com/trends?q=3Dsvn%2C+git%2C+mercurial%2C+bzr%2C+darcs&=
ctab=3D0&geo=3Dall&date=3Dall&sort=3D0Yes, but your aliases are not usable through git-foo, only git foo is.
So for consistency reasons, non dashed versions are better.And one could in the future have builtin commands without the
corresponding git-foo and git-bar either. I'm thinking
git-revert/git-cherry-pick that use _exactly_ the same code and code
objects, hence having the two binary is somehow a waste of space.
git-log variants are the same, and so on. I'm not saying this _will_ be
done, TTBOMK it has not even been discussed, but that may happen at some
point.--=20
=C2=B7O=C2=B7 Pierre Habouzit
=C2=B7=C2=B7O madcoder@debia=
n.org
OOO http://www.madism.org
Debian's popularity contest gives an idea too:
$ wget 'http://popcon.debian.org/by_inst'
$ head -11 by_inst
#Format
#
#<name> is the package name;
#<inst> is the number of people who installed this package;
#<vote> is the number of people who use this package regularly;
#<old> is the number of people who installed, but don't use this package
# regularly;
#<recent> is the number of people who upgraded this package recently;
#<no-files> is the number of people whose entry didn't contain enough
# information (atime and ctime were 0).
#rank name inst vote old recent no-files (maintainer)
$ grep -e ' cvs ' -e ' subversion ' -e ' monotone ' -e ' tla ' -e ' mercurial ' -e ' bzr ' -e ' git-core ' -e ' darcs ' by_inst
890 cvs 22659 4326 12754 5576 3 (Steve Mcintyre)
940 subversion 18888 7630 9693 1560 5 (Peter Samuelson)
2423 git-core 3720 1858 992 870 0 (Gerrit Pape)
3480 mercurial 1778 410 914 454 0 (Vincent Danjean)
3989 darcs 1344 300 936 108 0 (Isaac Jones)
4232 bzr 1198 278 372 548 0 (Debian Bazaar Maintainers)
4500 tla 1067 158 830 79 0 (Adam Majer)
7363 monotone 417 96 277 44 0 (Debian Maintainers For Monotone)That's not far from the first estimation above, except that Debian
users seem to have abandonned CVS a bit quicker than the rest of the
world. Git is still far behind SVN, but also by far the most popular
of free distributed VCS, modulo the fact that 78.42% of statistics are
biaised ;-).--
Matthieu
-
That's very interesting. When I did a count a month or so ago of the
number of projects using git, mercurial and bzr as self reported on
each of the project's wiki's, what I found then was:git 115 (source: http://git.or.cz/gitwiki/GitProjects)
hg 89 (source: http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial)
bzr 48 (source: http://bazaar-vcs.org/WhoUsesBzr)Of course, there's no guarantee that each of the Wiki maintainers were
as diligent about putting references to all of the projects, but to
the extent that there are people in each user community who are
interested in advocacy of their favoriate SCM, I would have expected
at least some baseline amount of effort in keeping their wiki's
uptodate. So it's not interesting as another data point...- Ted
-
Unfortunately the only problem with this trend chart is that if you
take the baseline of git and mercurial starting in the time period
between April 2004 and 2005 (i.e., before development of those two
systems started), git's and mercurial's usage hasn't actually grown by
that much. The problem being of course that git and mercurial are
words that can be used in other contexts, which is somewhat less
likely with svn and bzr, which makes it harder to draw good
conclusions.- Ted
-
Hi,
That woul be surprising. Git was not invented until early April 2005. At
the moment I still wait (impatiently, because then my current contract
ends) for April 2008.The important thing to realise is that time is such a wonderful dimension
to be exposed to: not only do you live (experience things that you did not
know before), but also other people live and learn.IOW even Linus realised that the git-xxx format is not _that_ good. Which
is why -- as you should have realised if you did not subscribe 5 minutes
ago -- we do not recommend git-xxx at all, but insist on "git xxx".Hth,
Dscho-
I didn't realize that.
Git doesn't give any warnings, and manpages give the dashed examples
only.Although I was subscribed to git-list from day 1, I must admit that
these days I don't read this list too closely (hence being caught in
surprise at this point).I assume things started with the following commit; but really, can we
please start with some deprecation notice before really moving it
around in user-visible location.commit 36e5e70e0f40cf7ca4351b8159d68f8560a2805f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat Jun 30 11:49:17 2007 -0700Start deprecating "git-command" in favor of "git command"
I realize that a lot of people use the "git-xyzzy" format, and we have
various historical reasons for it, but I also think that most people have
long since started thinking of the git command as a single command with
various subcommands, and we've long had the documentation talk about it
that way.Slowly migrating away from the git-xyzzy format would allow us to
eventually no longer install hundreds of binaries (even if most of them
are symlinks or hardlinks) in users $PATH, and the _original_ reasons for
it (implementation issues and bash completion) are really long long gone.Using "git xyzzy" also has some fundamental advantages, like the ability
to specify things like paging ("git -p xyzzy") and making the whole notion
of aliases act like other git commands (which they already do, but they do
*not* have a "git-xyzzy" form!)Anyway, while actually removing the "git-xyzzy" things is not practical
right now, we can certainly start slowly to deprecate it internally inside
git itself - in the shell scripts we use, and the test vectors.This patch adds a "remove-dashes" makefile target, which does that. It
isn't particularly efficient or smart, but it *does* successfully rewrite
a lot of our shell scripts to use the "git xyzzy" form for...
Hi,
Please realize that you make it hard on _everybody else_ than you to
follow who said what by egoistically deleting things that are important.That deprecation notice was the one you originally replied to. So your
request has been granted before you even asked for it.But I suspect that you did not understand what I said: if you install a
git script (that is not part of the "official" Git), it will probably be
in the PATH, and you will not have a problem.Hth,
Dscho-
Hi,
At Sun, 3 Feb 2008 03:24:20 +0000 (GMT),
There are two parts to the problem
1. Custom scripts installed in PATH
-> this is not a problem2. Custom scripts calling git tools with dash notation. (git-xxx).
-> they need to be modified and fixed.I was initially worried about (1), but I realize now that it's a
no-op. Now, I am worried about (2), and I realize I have quite a few
scripts to fix.regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
-
Hi,
Exactly, they need to be modified and fixed. Which was why Junio wrote
that part of his message, to warn you and everybody that you will need to
fix your scripts. Of course, you need not be in a hurry, this will not
affect you in the next few weeks.Ciao,
Dscho-
Hi,
If you have some general purpose scripts that you can put under the GPL,
then we can perhaps integrate and fix them for you and everyone else.Thanks in advance,
Christian.
-
Hi,
AFAIU this only affects the programs that git installs. Of course, git
will search in that location first, but then in the rest of PATH.Ciao,
Dscho-
