From: Junio C Hamano <hidden> Date: 2008-02-02 04:35:10
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 is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.
- Using dashed forms from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.
- Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.
Users are strongly encouraged to adjust their habits and scripts now
to prepare for this change.
* The post-receive hook was introduced in March 2007 to supersede
the post-update hook, primarily to overcome the command line length
limitation of the latter. Use of post-update hook will be deprecated
in future versions of git, starting from v1.6.0.
* "git lost-found" was deprecated in favor of "git fsck"'s --lost-found
option, and will be removed in the future.
* "git peek-remote" is deprecated, as "git ls-remote" was written in C
and works for all transports; "git peek-remote" will be removed in
the future.
* "git repo-config" which was an old name for "git config" command
has been supported without being advertised for a long time. The
next feature release will remove it.
* From v1.6.0, the repack.usedeltabaseoffset config option will default
to true, which will give denser packfiles (i.e. more efficient storage).
The downside is that git older than version 1.4.4 will not be able
to directly use a repository packed using this setting.
* From v1.6.0, the pack.indexversion config option will default to 2,
which is slightly more efficient, and makes repacking more immune to
data corruptions. Git older than version 1.5.2 may revert to version 1
of the pack index with a manual "git index-pack" to be able to directly
access corresponding pack files.
Updates since v1.5.3
--------------------
* Comes with much improved gitk, with i18n.
* Comes with git-gui 0.9.2 with i18n.
* gitk is now merged as a subdirectory of git.git project, in
preparation for its i18n.
* progress displays from many commands are a lot nicer to the eye.
Transfer commands show throughput data.
* many commands that pay attention to per-directory .gitignore now do
so lazily, which makes the usual case go much faster.
* Output processing for '--pretty=format:<user format>' has been
optimized.
* Rename detection of diff family while detecting exact matches has
been greatly optimized.
* Rename detection of diff family tries to make more natural looking
pairing. Earlier, if multiple identical rename sources were
found in the preimage, the source used was picked pretty much at random.
* Value "true" for color.diff and color.status configuration used to
mean "always" (even when the output is not going to a terminal).
This has been corrected to mean the same thing as "auto".
* "git diff" Porcelain now respects diff.external configuration, which
is another way to specify GIT_EXTERNAL_DIFF.
* "git diff" can be told to use different prefixes other than
"a/" and "b/" e.g. "git diff --src-prefix=l/ --dst-prefix=k/".
* "git diff" sometimes did not quote paths with funny
characters properly.
* "git log" (and any revision traversal commands) misbehaved
when --diff-filter is given but was not asked to actually
produce diff.
* HTTP proxy can be specified per remote repository using
remote.*.httpproxy configuration, or global http.proxy configuration
variable.
* Various Perforce importer updates.
* Example update and post-receive hooks have been improved.
* Any command that wants to take a commit object name can now use
":/string" syntax to name a commit.
* "git reset" is now built-in and its output can be squelched with -q.
* "git reset --hard" does not make any sense in a bare
repository, but did not error out; fixed.
* "git send-email" can optionally talk over ssmtp and use SMTP-AUTH.
* "git rebase" learned --whitespace option.
* In "git rebase", when you decide not to replay a particular change
after the command stopped with a conflict, you can say "git rebase
--skip" without first running "git reset --hard", as the command now
runs it for you.
* "git rebase --interactive" mode can now work on detached HEAD.
* Other minor to serious bugs in "git rebase -i" have been fixed.
* "git rebase" now detaches head during its operation, so after a
successful "git rebase" operation, the reflog entry branch@{1} for
the current branch points at the commit before the rebase was
started.
* "git rebase -i" also triggers rerere to help your repeated merges.
* "git merge" can call the "post-merge" hook.
* "git pack-objects" can optionally run deltification with multiple
threads.
* "git archive" can optionally substitute keywords in files marked with
export-subst attribute.
* "git cherry-pick" made a misguided attempt to repeat the original
command line in the generated log message, when told to cherry-pick a
commit by naming a tag that points at it. It does not anymore.
* "git for-each-ref" learned %(xxxdate:<date-format>) syntax to show the
various date fields in different formats.
* "git gc --auto" is a low-impact way to automatically run a variant of
"git repack" that does not lose unreferenced objects (read: safer
than the usual one) after the user accumulates too many loose
objects.
* "git clean" has been rewritten in C.
* You need to explicitly set clean.requireForce to "false" to allow
"git clean" without -f to do any damage (lack of the configuration
variable used to mean "do not require -f option to lose untracked
files", but we now use the safer default).
* The kinds of whitespace errors "git diff" and "git apply" notice (and
fix) can be controlled via 'core.whitespace' configuration variable
and 'whitespace' attribute in .gitattributes file.
* "git push" learned --dry-run option to show what would happen if a
push is run.
* "git push" does not update a tracking ref on the local side when the
remote refused to update the corresponding ref.
* "git push" learned --mirror option. This is to push the local refs
one-to-one to the remote, and deletes refs from the remote that do
not exist anymore in the repository on the pushing side.
* "git push" can remove a corrupt ref at the remote site with the usual
":ref" refspec.
* "git remote" knows --mirror mode. This is to set up configuration to
push into a remote repository to store local branch heads to the same
branch on the remote side, and remove branch heads locally removed
from local repository at the same time. Suitable for pushing into a
back-up repository.
* "git remote" learned "rm" subcommand.
* "git cvsserver" can be run via "git shell". Also, "cvs" is
recognized as a synonym for "git cvsserver", so that CVS users
can be switched to git just by changing their login shell.
* "git cvsserver" acts more like receive-pack by running post-receive
and post-update hooks.
* "git am" and "git rebase" are far less verbose.
* "git pull" learned to pass --[no-]ff option to underlying "git
merge".
* "git pull --rebase" is a different way to integrate what you fetched
into your current branch.
* "git fast-export" produces data-stream that can be fed to fast-import
to reproduce the history recorded in a git repository.
* "git add -i" takes pathspecs to limit the set of files to work on.
* "git add -p" is a short-hand to go directly to the selective patch
subcommand in the interactive command loop and to exit when done.
* "git add -i" UI has been colorized. The interactive prompt
and menu can be colored by setting color.interactive
configuration. The diff output (including the hunk picker)
are colored with color.diff configuration.
* "git commit --allow-empty" allows you to create a single-parent
commit that records the same tree as its parent, overriding the usual
safety valve.
* "git commit --amend" can amend a merge that does not change the tree
from its first parent.
* "git commit" used to unconditionally strip comment lines that
began with '#' and removed excess blank lines. This behavior has
been made configurable.
* "git commit" has been rewritten in C.
* "git stash random-text" does not create a new stash anymore. It was
a UI mistake. Use "git stash save random-text", or "git stash"
(without extra args) for that.
* "git stash clear extra-text" does not clear the whole stash
anymore. It is tempting to expect "git stash clear stash@{2}"
to drop only a single named stash entry, and it is rude to
discard everything when that is asked (but not provided).
* "git prune --expire <time>" can exempt young loose objects from
getting pruned.
* "git branch --contains <commit>" can list branches that are
descendants of a given commit.
* "git log" learned --early-output option to help interactive GUI
implementations.
* "git bisect" learned "skip" action to mark untestable commits.
* "git bisect visualize" learned a shorter synonym "git bisect view".
* "git bisect visualize" runs "git log" in a non-windowed
environments. It also can be told what command to run (e.g. "git
bisect visualize tig").
* "git format-patch" learned "format.numbered" configuration variable
to automatically turn --numbered option on when more than one commits
are formatted.
* "git ls-files" learned "--exclude-standard" to use the canned set of
exclude files.
* "git tag -a -f existing" begins the editor session using the existing
annotation message.
* "git tag -m one -m bar" (multiple -m options) behaves similarly to
"git commit"; the parameters to -m options are formatted as separate
paragraphs.
* The format "git show" outputs an annotated tag has been updated to
include "Tagger: " and "Date: " lines from the tag itself. Strictly
speaking this is a backward incompatible change, but this is a
reasonable usability fix and people's scripts shouldn't have been
relying on the exact output from "git show" Porcelain anyway.
* "git cvsimport" did not notice errors from underlying "cvsps"
and produced a corrupt import silently.
* "git cvsexportcommit" learned -w option to specify and switch to the
CVS working directory.
* "git checkout" from a subdirectory learned to use "../path" to allow
checking out a path outside the current directory without cd'ing up.
* "git checkout" from and to detached HEAD leaves a bit more
information in the reflog.
* "git send-email --dry-run" shows full headers for easier diagnosis.
* "git merge-ours" is now built-in.
* "git svn" learned "info" and "show-externals" subcommands.
* "git svn" run from a subdirectory failed to read settings from the
.git/config.
* "git svn" learned --use-log-author option, which picks up more
descriptive name from From: and Signed-off-by: lines in the commit
message.
* "git svn" wasted way too much disk to record revision mappings
between svn and git; a new representation that is much more compact
for this information has been introduced to correct this.
* "git svn" left temporary index files it used without cleaning them
up; this was corrected.
* "git status" from a subdirectory now shows relative paths, which
makes copy-and-pasting for git-checkout/git-add/git-rm easier. The
traditional behavior to show the full path relative to the top of
the work tree can be had by setting status.relativepaths
configuration variable to false.
* "git blame" kept text for each annotated revision in core needlessly;
this has been corrected.
* "git shortlog" learned to default to HEAD when the standard input is
a terminal and the user did not give any revision parameter.
* "git shortlog" learned "-e" option to show e-mail addresses as well as
authors' names.
* "git help" learned "-w" option to show documentation in browsers.
* In addition there are quite a few internal clean-ups. Notably:
- many fork/exec have been replaced with run-command API,
brought from the msysgit effort.
- introduction and more use of the option parser API.
- enhancement and more use of the strbuf API.
* Makefile tweaks to support HP-UX is in.
Fixes since v1.5.3
------------------
All of the fixes in v1.5.3 maintenance series are included in
this release, unless otherwise noted.
These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance
series.
* The way "git diff --check" behaves is much more consistent with the way
"git apply --whitespace=warn" works.
* "git svn" talking with the SVN over HTTP will correctly quote branch
and project names.
* "git config" did not work correctly on platforms that define
REG_NOMATCH to an even number.
* Recent versions of AsciiDoc 8 has a change to break our
documentation; a workaround has been implemented.
* "git diff --color-words" colored context lines in a wrong color.
- 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 is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:09
Hi,
On Sat, 2 Feb 2008, Junichi Uekawa wrote:
quoted
- 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 is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.
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?
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
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 Bzr
This 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 surprised
with this change.
quoted
- 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 is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.
I 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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:09
Hi,
On Sun, 3 Feb 2008, Junichi Uekawa wrote:
I was wondering why I use the git-xxx format so much (in muscle, and
in scripts). And realized I have the following reasons:
[1 and 2]
3. Linus said it's better (3 years ago), and I thought so too.
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
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".
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 [off-list ref]
Date: Sat Jun 30 11:49:17 2007 -0700
Start 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 all built-in
commands.
(For non-builtins, the "git xyzzy" format implies an extra execve(), so
this script leaves those alone).
So apply this patch, and then run
make remove-dashes
make test
git commit -a
to generate a much larger patch that actually starts this transformation.
(The only half-way subtle thing about this is that it also fixes up
git-filter-branch.sh for the new world order by adding quoting around
the use of "git-commit-tree" as an argument. It doesn't need it in that
format, but when changed into "git commit-tree" it is no longer a single
word, and the quoting maintains the old behaviour).
NOTE! This does not yet mean that you can actually stop installing the
"git-xyzzy" binaries for the builtins. There are some remaining places
that want to use the old form, this just removes the most obvious ones
that can easily be done automatically.
Signed-off-by: Linus Torvalds [off-list ref]
Signed-off-by: Junio C Hamano [off-list ref]
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:09
Hi,
On Sun, 3 Feb 2008, Junichi Uekawa wrote:
Hi,
Who said that:
quoted
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.
Please realize that you make it hard on _everybody else_ than you to
follow who said what by egoistically deleting things that are important.
Such as who said what.
quoted
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".
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.
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),
Johannes Schindelin wrote:
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.
There are two parts to the problem
1. Custom scripts installed in PATH
-> this is not a problem
2. 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
From: Christian Couder <hidden> Date: 2016-06-15 22:44:09
Hi,
Le dimanche 3 février 2008, Junichi Uekawa a écrit :
There are two parts to the problem
1. Custom scripts installed in PATH
-> this is not a problem
2. 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.
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.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:09
Hi,
On Sun, 3 Feb 2008, Junichi Uekawa wrote:
2. Custom scripts calling git tools with dash notation. (git-xxx).
-> they need to be modified and fixed.
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
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:44:09
On Sun, Feb 03, 2008 at 01:00:57AM +0000, Junichi Uekawa wrote:
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 Bzr
This 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 surprised
with this change.
I 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.
Yes, 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.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
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
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.
The latest feature release GIT 1.5.4 is available at the usual
places:
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
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).
--
Luciano Rocha [off-list ref]
Eurotux Informática, S.A. <http://www.eurotux.com/>
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:11
Hi,
On Thu, 7 Feb 2008, Luciano Rocha wrote:
On Thu, Feb 07, 2008 at 12:55:58PM +0000, Johannes Schindelin wrote:
quoted
On Thu, 7 Feb 2008, Luciano Rocha wrote:
quoted
Why do I have to accept the GPL to install msysgit?
Because that's the only license you have to use git.
Again, GPL governs distribution, not use.
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
From: David Kastrup <hidden> Date: 2016-06-15 22:44:11
Johannes Schindelin [off-list ref] writes:
Hi,
On Thu, 7 Feb 2008, Luciano Rocha wrote:
quoted
On Thu, Feb 07, 2008 at 12:55:58PM +0000, Johannes Schindelin wrote:
quoted
On Thu, 7 Feb 2008, Luciano Rocha wrote:
quoted
Why do I have to accept the GPL to install msysgit?
Because that's the only license you have to use git.
Again, GPL governs distribution, not use.
The fine points on why installing it onto your computer is not a
distribution are just lost on me.
The GPLv3 might explain it better.
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.
What happens if the user does not accept it? The license explicitly
states
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, [...]
Obviously, one can't run the program without installing it. The license
also states:
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
Again, only modification and distribution are affected by
non-acceptance. Talking about unrestricted running of the program would
be utterly non-sensical if you were not allowed to install it.
Of course, you can read this in the GPL FAQ if you want to. There was a
similar problem for the Windows installer of Emacs IIRC (the underlying
program does not even consider the possibility of not agreeing to a
license) and there were proposals of changing the button texts to "This
is great" and something else. I don't know what the people converged on
finally, not using Windows myself.
--
David Kastrup
Why do I have to accept the GPL to install msysgit?
Because that's the only license you have to use git.
Uh no. The right to use git is "fair use": if you have acquired a copy
of a copyrighted work through a legal channel, you have prima facie a
certain set of rights. Conventional software "licenses" try to make you
give up many of these rights which is why the recipient needs to agree
to those licenses (which are actually contracts rather than licenses).
But the GPL just grants additional rights, so no agreement is necessary
for fair use. From the GPL 2.1 (please read the first sentence in
particular):
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
--
David Kastrup
From: Jari Aalto <hidden> Date: 2016-06-15 22:44:11
* Thu 2008-02-07 Johannes Schindelin [off-list ref]
* Message-Id: alpine.LSU.1.00.0802071255110.8543@racer.site
quoted
Why do I have to accept the GPL to install msysgit?
Because that's the only license you have to use git.
I don't quite understand.
- When you install a GPL program in Linux (trough package manager).
It gets installed.
- When git is installed Under Windows / Cygwin, it gets installed.
... and if the git is installed trough windows installer, you need
to *accept* the install?
I really don't follow why there is need to force Windows type EULA
questions through the end users' throat in that particular case, when it
is not done in other cases.
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
On Fri, Feb 01, 2008 at 08:34:24PM -0800, Junio C Hamano wrote:
The latest feature release GIT 1.5.4 is available at the usual
places:
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