[ANNOUNCE] GIT 1.5.4

[ANNOUNCE] GIT 1.5.4

[Junio C Hamano]

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.

Re: [ANNOUNCE] GIT 1.5.4

[Junichi Uekawa]

Hi,

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

Re: [ANNOUNCE] GIT 1.5.4

[しらいしななこ]

Quoting Junio C Hamano <gitster@pobox.com>:

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

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

Re: [ANNOUNCE] GIT 1.5.4

[Wincent Colaiuta]

El 2/2/2008, a las 5:34, Junio C Hamano escribió:

> 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

Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

Hi,

On Sat, 2 Feb 2008, Junichi Uekawa wrote:

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

Re: [ANNOUNCE] GIT 1.5.4

[Steffen Prohaska]

On Feb 2, 2008, at 5:34 AM, Junio C Hamano wrote:

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

The msysgit setup is available at:

   http://code.google.com/p/msysgit/downloads/

	Steffen

Re: [ANNOUNCE] GIT 1.5.4

[Junichi Uekawa]

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.


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

Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

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

Re: [ANNOUNCE] GIT 1.5.4

[Junichi Uekawa]

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

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 -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 <torvalds@linux-foundation.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>




regards,
	junichi
-- 
dancer@{debian.org,netfort.gr.jp}   Debian Project

Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

Hi,

On Sun, 3 Feb 2008, Junichi Uekawa wrote:

> Hi,
> 

Who said that:

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

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

Re: [ANNOUNCE] GIT 1.5.4

[Junichi Uekawa]

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

Re: [ANNOUNCE] GIT 1.5.4

[Christian Couder]

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.

Re: [ANNOUNCE] GIT 1.5.4

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]

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.

  http://www.google.com/trends?q=svn%2C+git%2C+mercurial%2C+bzr%2C+darcs&ctab=0&geo=all&date=all&sort=0

  :)

> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

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

Re: [ANNOUNCE] GIT 1.5.4

[Theodore Tso]

On Sun, Feb 03, 2008 at 11:38:04AM +0100, Pierre Habouzit wrote:
>   http://www.google.com/trends?q=svn%2C+git%2C+mercurial%2C+bzr%2C+darcs&ctab=0&geo=all&date=all&sort=0
> 
>   :)

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

Re: [ANNOUNCE] GIT 1.5.4

[Matthieu Moy]

Pierre Habouzit <madcoder@debian.org> writes:

> 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.
>
>   http://www.google.com/trends?q=svn%2C+git%2C+mercurial%2C+bzr%2C+darcs&ctab=0&geo=all&date=all&sort=0

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

Re: [ANNOUNCE] GIT 1.5.4 (git popularity)

[Jakub Narebski]

Matthieu Moy wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>> On Sun, Feb 03, 2008 at 01:00:57AM +0000, Junichi Uekawa wrote:
>>> 
>>> 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.
>>
>>   http://www.google.com/trends?q=svn%2C+git%2C+mercurial%2C+bzr%2C+darcs&ctab=0&geo=all&date=all&sort=0
> 
> Debian's popularity contest gives an idea too

And Ohloh stack count gives yet another idea.  Both Debian popularity
counter and number of Ohloh stacks are mentioned in GitSurvey2007[*1*],
around question about used SCMs.  Google Trends above not yet, and
perhaps will not because it is even more skewed than mentioned results,
perhaps even more than result of Git _User's_ Survey 2007.

[*1*] http://git.or.cz/gitwiki/GitSurvey2007#head-4ed59e7615e2dc4f4baa8fa0beccde52c93789f8
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [ANNOUNCE] GIT 1.5.4

[Dmitry Potapov]

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

Re: [ANNOUNCE] GIT 1.5.4

[Theodore Tso]

On Sun, Feb 03, 2008 at 04:08:55PM +0100, Matthieu Moy wrote:
> Debian's popularity contest gives an idea too:
> 
> #rank name                            inst  vote   old recent no-files (maintainer)
> 2423  git-core                        3720  1858   992   870     0 (Gerrit Pape)                   
> 3480  mercurial                       1778   410   914   454     0 (Vincent Danjean)               
> 4232  bzr                             1198   278   372   548     0 (Debian Bazaar Maintainers)     

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

Re: [ANNOUNCE] GIT 1.5.4

[Jari Aalto]

* Sun 2008-02-03 Theodore Tso <tytso@mit.edu> gmane.comp.version-control.git
* Message-Id: 20080203192758.GD18392@mit.edu
> On Sun, Feb 03, 2008 at 04:08:55PM +0100, Matthieu Moy wrote:
>
> 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)
>

Debian project is also using these:

    Hg      http://git.debian.org
    Bzr     http://bzr.debian.org
    Git     http//hg.debian.org
    Darcs   http://darcs.debian.org

Jari

References:

    http://wiki.debian.org/Alioth/Hg
    http://wiki.debian.org/Alioth/Bzr
    http://wiki.debian.org/Alioth/Git
    http://wiki.debian.org/Alioth/Darcs

-- 
Welcome to FOSS revolution: we fix and modify until it shines

Re: [ANNOUNCE] GIT 1.5.4

[Luciano Rocha]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Sat, Feb 02, 2008 at 11:42:11PM +0100, Steffen Prohaska wrote:
> 
>  On Feb 2, 2008, at 5:34 AM, Junio C Hamano wrote:
> 
> > The latest feature release GIT 1.5.4 is available at the usual
> > places:
> 
>  The msysgit setup is available at:
> 
>    http://code.google.com/p/msysgit/downloads/
> 

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 <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

Hi,

On Thu, 7 Feb 2008, Luciano Rocha wrote:

> On Sat, Feb 02, 2008 at 11:42:11PM +0100, Steffen Prohaska wrote:
> > 
> >  On Feb 2, 2008, at 5:34 AM, Junio C Hamano wrote:
> > 
> > > The latest feature release GIT 1.5.4 is available at the usual
> > > places:
> > 
> >  The msysgit setup is available at:
> > 
> >    http://code.google.com/p/msysgit/downloads/
> > 
> 
> Why do I have to accept the GPL to install msysgit?

Because that's the only license you have to use git.

Get over it, or use another SCM,
Dscho "who hates license wars"

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Luciano Rocha]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On Thu, Feb 07, 2008 at 12:55:58PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 7 Feb 2008, Luciano Rocha wrote:
> 
> > On Sat, Feb 02, 2008 at 11:42:11PM +0100, Steffen Prohaska wrote:
> > > 
> > >  On Feb 2, 2008, at 5:34 AM, Junio C Hamano wrote:
> > > 
> > > > The latest feature release GIT 1.5.4 is available at the usual
> > > > places:
> > > 
> > >  The msysgit setup is available at:
> > > 
> > >    http://code.google.com/p/msysgit/downloads/
> > > 
> > 
> > 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.

> Get over it, or use another SCM,

I like and use GPL, but I won't force my users to accept the GPL in
order to use programs released under it.

> Dscho "who hates license wars"

I'm not battling over licenses.

-- 
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] GIT 1.5.4

[Eyvind Bernhardsen]

On 7. feb.. 2008, at 13.55, Johannes Schindelin wrote:

> Hi,
>
> On Thu, 7 Feb 2008, Luciano Rocha wrote:
>
>> Why do I have to accept the GPL to install msysgit?
>
> Because that's the only license you have to use git.

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

> Get over it, or use another SCM,
> Dscho "who hates license wars"

No war for you!

Eyvind Bernhardsen

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[David Kastrup]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Thu, 7 Feb 2008, Luciano Rocha wrote:
>
>> On Sat, Feb 02, 2008 at 11:42:11PM +0100, Steffen Prohaska wrote:
>> > 
>> >  On Feb 2, 2008, at 5:34 AM, Junio C Hamano wrote:
>> > 
>> > > The latest feature release GIT 1.5.4 is available at the usual
>> > > places:
>> > 
>> >  The msysgit setup is available at:
>> > 
>> >    http://code.google.com/p/msysgit/downloads/
>> > 
>> 
>> 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

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

Hi,

On Thu, 7 Feb 2008, Luciano Rocha wrote:

> On Thu, Feb 07, 2008 at 12:55:58PM +0000, Johannes Schindelin wrote:
> 
> > On Thu, 7 Feb 2008, Luciano Rocha wrote:
> > 
> > > 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

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[David Kastrup]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Thu, 7 Feb 2008, Luciano Rocha wrote:
>
>> On Thu, Feb 07, 2008 at 12:55:58PM +0000, Johannes Schindelin wrote:
>> 
>> > On Thu, 7 Feb 2008, Luciano Rocha wrote:
>> > 
>> > > 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

Re: [ANNOUNCE] GIT 1.5.4

[Steffen Prohaska]

On Feb 7, 2008, at 2:28 PM, Johannes Schindelin wrote:

> The Git installer of msysGit will always show the GPL, and have the  
> user
> accept it.

I agree.

	Steffen

Re: [ANNOUNCE] GIT 1.5.4

[Michael Poole]

David Kastrup writes:

> Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> writes:
>
>> On Thu, 7 Feb 2008, Luciano Rocha wrote:
>>
>>> On Sat, Feb 02, 2008 at 11:42:11PM +0100, Steffen Prohaska wrote:
>>> > 
>>> >  On Feb 2, 2008, at 5:34 AM, Junio C Hamano wrote:
>>> > 
>>> > > The latest feature release GIT 1.5.4 is available at the usual
>>> > > places:
>>> > 
>>> >  The msysgit setup is available at:
>>> > 
>>> >    http://code.google.com/p/msysgit/downloads/
>>> > 
>>> 
>>> 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).

The concept of "fair use" of copyrighted works does not exist (per se)
in Europe, Japan, or a number of other countries.  The USA may be the
only place to have that doctrine.

British courts, for instance, have held that copying a program into
RAM for the purposes of executing it is a right reserved under
copyright law.  In the US, 17 USC 117(c) and (d) were added after a
court held (in MAI Sys. Corp. v. Peak Computer) that a computer repair
company violated copyright of software that automatically started on a
computer it was asked to repair -- by simply allowing the computer to
boot and execute that program automatically.

As the GPL itself notes, you are not required to accept it, but
nothing else grants you the right to perform actions reserved to
copyright holders with respect to the work.  Asking end users to
accept the GPL has good effect in countries besides the US, and has no
obvious harm in the US.

Michael Poole

Re: [ANNOUNCE] GIT 1.5.4

[David Kastrup]

Michael Poole <mdpoole-IZmAEv5cUt1AfugRpC6u6w@public.gmane.org> writes:

> British courts, for instance, have held that copying a program into
> RAM for the purposes of executing it is a right reserved under
> copyright law.  In the US, 17 USC 117(c) and (d) were added after a
> court held (in MAI Sys. Corp. v. Peak Computer) that a computer repair
> company violated copyright of software that automatically started on a
> computer it was asked to repair -- by simply allowing the computer to
> boot and execute that program automatically.
>
> As the GPL itself notes, you are not required to accept it, but
> nothing else grants you the right to perform actions reserved to
> copyright holders with respect to the work.

I think that most countries will grant some right to the purchaser of a
physical copy of copyrighted material.  For example, I doubt there are
countries where it is prohibited to read a book you have bought (via a
channel authorized by the copyright holder) when it contains no explicit
license granting you the right to read it.

-- 
David Kastrup

Re: [ANNOUNCE] GIT 1.5.4

[Nicolas Pitre]

On Thu, 7 Feb 2008, Luciano Rocha wrote:

> On Thu, Feb 07, 2008 at 12:55:58PM +0000, Johannes Schindelin wrote:
> > Hi,
> > 
> > On Thu, 7 Feb 2008, Luciano Rocha wrote:
> > 
> > > 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.
> 
> > Get over it, or use another SCM,
> 
> I like and use GPL, but I won't force my users to accept the GPL in
> order to use programs released under it.

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

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Luciano Rocha]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

On Thu, Feb 07, 2008 at 09:53:05AM -0500, Nicolas Pitre wrote:
> On Thu, 7 Feb 2008, Luciano Rocha wrote:
> 
> > On Thu, Feb 07, 2008 at 12:55:58PM +0000, Johannes Schindelin wrote:
> > > Hi,
> > > 
> > > On Thu, 7 Feb 2008, Luciano Rocha wrote:
> > > 
> > > > 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.
> > 
> > > Get over it, or use another SCM,
> > 
> > I like and use GPL, but I won't force my users to accept the GPL in
> > order to use programs released under it.
> 
> What are they forced into if they indeed only want to _use_ Git?

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
binaries. I just wanted to bring that case to attention, nothing else.

> They nevertheless must be made aware of the rules they have to follow in 
> case the idea of redistributing it crosses their mind.

I don't dispute that, only that I can't continue with the install unless
I click on "I Accept" to the GNU GPL.

-- 
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] GIT 1.5.4

[Michael Poole]

David Kastrup writes:

> I think that most countries will grant some right to the purchaser of a
> physical copy of copyrighted material.  For example, I doubt there are
> countries where it is prohibited to read a book you have bought (via a
> channel authorized by the copyright holder) when it contains no explicit
> license granting you the right to read it.

I see two serious dis-analogies here:

How many users of msysgit purchase a physical copy of it?  (I suspect
this is a relevant difference in the US due to its commerce codes, and
maybe in other common law countries; it probably is not so important
in civil law countries, where exchange of consideration is not a
requirement to form a contract.)

Reading a literary work is typically not a reserved right, either;
while it seems good to treat executing a computer program in the same
way as reading a book, all copyright regimes that I know of give
consideration to the copy that is made to RAM for most computers.  (I
will ignore the implications for devices that have execute-in-place
non-volatile memory -- I am not a lawyer, and those devices are
probably too new to be addressed by courts yet.)

Michael Poole

[Also- The git list did not receive my previous mail and probably will
not receive this one either.  vger.kernel.org issues a bogus bounce,
shown in part below.  I apologize for hijacking the thread this way,
but mail to postmaster-at-vger bounces for the same reason.

Error in "rcvdfrom" envelope address:

	75.145.205-121-BusName-sterling.va.richmond.hfc.comcastbusiness.net!^Q
	^								    ^-illegal control character
	 \-Extraneous program text

.. where my mail host does not use that name for any reason; vger
seems to be doing a DNS PTR lookup, then mangling the response.]

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Jakub Narebski]

Luciano Rocha wrote:
> On Thu, Feb 07, 2008 at 09:53:05AM -0500, Nicolas Pitre wrote:
>> On Thu, 7 Feb 2008, Luciano Rocha wrote: 

>>> I like and use GPL, but I won't force my users to accept the GPL in
>>> order to use programs released under it.
>> 
>> What are they forced into if they indeed only want to _use_ Git?
> 
> 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
> binaries. I just wanted to bring that case to attention, nothing else.
> 
>> They nevertheless must be made aware of the rules they have to follow in 
>> case the idea of redistributing it crosses their mind.
> 
> I don't dispute that, only that I can't continue with the install unless
> I click on "I Accept" to the GNU GPL.

So, would you prefer to be presented with GNU GPL with two buttons:
"That's great" and "Oh, f**k", instead of "I Accept" and "Cancel",
both of which would allow to install msysGit? ;-ppppppp

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [ANNOUNCE] GIT 1.5.4

[David Kastrup]

Michael Poole <mdpoole-IZmAEv5cUt1AfugRpC6u6w@public.gmane.org> writes:

> David Kastrup writes:
>
>> I think that most countries will grant some right to the purchaser of
>> a physical copy of copyrighted material.  For example, I doubt there
>> are countries where it is prohibited to read a book you have bought
>> (via a channel authorized by the copyright holder) when it contains
>> no explicit license granting you the right to read it.
>
> I see two serious dis-analogies here:
>
> How many users of msysgit purchase a physical copy of it?

"Acquire an authorized copy" is the relevant phrase here.  And that will
be the case for pretty much every user.

> 	75.145.205-121-BusName-sterling.va.richmond.hfc.comcastbusiness.net!^Q
> 	^								    ^-illegal control character
> 	 \-Extraneous program text
>
> .. where my mail host does not use that name for any reason; vger
> seems to be doing a DNS PTR lookup, then mangling the response.]

It may be that your version of Emacs is injecting C-d characters after
column 255 in a line.

-- 
David Kastrup

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[David Kastrup]

Jakub Narebski <jnareb@gmail.com> writes:

> Luciano Rocha wrote:
>> On Thu, Feb 07, 2008 at 09:53:05AM -0500, Nicolas Pitre wrote:
>>> On Thu, 7 Feb 2008, Luciano Rocha wrote: 
>
>>>> I like and use GPL, but I won't force my users to accept the GPL in
>>>> order to use programs released under it.
>>> 
>>> What are they forced into if they indeed only want to _use_ Git?
>> 
>> 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
>> binaries. I just wanted to bring that case to attention, nothing else.
>> 
>>> They nevertheless must be made aware of the rules they have to follow in 
>>> case the idea of redistributing it crosses their mind.
>> 
>> I don't dispute that, only that I can't continue with the install unless
>> I click on "I Accept" to the GNU GPL.
>
> So, would you prefer to be presented with GNU GPL with two buttons:
> "That's great" and "Oh, f**k", instead of "I Accept" and "Cancel",
> both of which would allow to install msysGit? ;-ppppppp

"That's great" and "I don't mind" would probably be more appropriate.
If the installer will have one button abort, the easiest solution would
be probably to offer

"Continue" "Abort"

That shows what will happen when clicking the respective button without
insinuating legal repercussions.

-- 
David Kastrup

Re: [ANNOUNCE] GIT 1.5.4

[Nicolas Pitre]

On Thu, 7 Feb 2008, Luciano Rocha wrote:

> On Thu, Feb 07, 2008 at 09:53:05AM -0500, Nicolas Pitre wrote:
> > What are they forced into if they indeed only want to _use_ Git?
> 
> 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
> binaries. I just wanted to bring that case to attention, nothing else.
> 
> > They nevertheless must be made aware of the rules they have to follow in 
> > case the idea of redistributing it crosses their mind.
> 
> I don't dispute that, only that I can't continue with the install unless
> I click on "I Accept" to the GNU GPL.

Then, simply changing the button text from "I accept" to "Continue" 
should be OK?


Nicolas

Re: [ANNOUNCE] GIT 1.5.4

[David Kastrup]

Nicolas Pitre <nico-mo2vmkxb4K0@public.gmane.org> writes:

> On Thu, 7 Feb 2008, Luciano Rocha wrote:
>
>> On Thu, Feb 07, 2008 at 09:53:05AM -0500, Nicolas Pitre wrote:
>> > What are they forced into if they indeed only want to _use_ Git?
>> 
>> 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
>> binaries. I just wanted to bring that case to attention, nothing else.
>> 
>> > They nevertheless must be made aware of the rules they have to follow in 
>> > case the idea of redistributing it crosses their mind.
>> 
>> I don't dispute that, only that I can't continue with the install unless
>> I click on "I Accept" to the GNU GPL.
>
> Then, simply changing the button text from "I accept" to "Continue" 
> should be OK?

Another rather neutral option would be the choice "Abort"/"Install".

-- 
David Kastrup

Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

Hi,

On Thu, 7 Feb 2008, Nicolas Pitre wrote:

> Then, simply changing the button text from "I accept" to "Continue" 
> should be OK?

I consider this bike-shedding, git-u79uwXL29TY76Z2rM5mHXA@public.gmane.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

Re: [ANNOUNCE] GIT 1.5.4

[Steffen Prohaska]

On Feb 7, 2008, at 4:59 PM, Luciano Rocha wrote:

>> They nevertheless must be made aware of the rules they have to  
>> follow in
>> case the idea of redistributing it crosses their mind.
>
> I don't dispute that, only that I can't continue with the install  
> unless
> I click on "I Accept" to the GNU GPL.

Simple question: Do you accept it or not?

	Steffen

Re: [ANNOUNCE] GIT 1.5.4

[David Kastrup]

Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:

> On Feb 7, 2008, at 4:59 PM, Luciano Rocha wrote:
>
>>> They nevertheless must be made aware of the rules they have to
>>> follow in
>>> case the idea of redistributing it crosses their mind.
>>
>> I don't dispute that, only that I can't continue with the install
>> unless
>> I click on "I Accept" to the GNU GPL.
>
> Simple question: Do you accept it or not?

It's not related to whether GPLed software is permitted to be installed
or not.  You could also ask "Do you like green eggs and ham?".  Where is
the point?

-- 
David Kastrup

Re: [ANNOUNCE] GIT 1.5.4

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> writes:

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

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.

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Jari Aalto]

* Thu 2008-02-07 Johannes Schindelin <Johannes.Schindelin@gmx.de>
* Message-Id: alpine.LSU.1.00.0802071255110.8543@racer.site
>> 
>> 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

Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

Hi,

On Thu, 7 Feb 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> writes:
> 
> > 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.
> 
> 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.

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

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Luciano Rocha]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

On Thu, Feb 07, 2008 at 11:35:40AM -0500, Nicolas Pitre wrote:
> On Thu, 7 Feb 2008, Luciano Rocha wrote:
> 
> > On Thu, Feb 07, 2008 at 09:53:05AM -0500, Nicolas Pitre wrote:
> > > What are they forced into if they indeed only want to _use_ Git?
> > 
> > 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
> > binaries. I just wanted to bring that case to attention, nothing else.
> > 
> > > They nevertheless must be made aware of the rules they have to follow in 
> > > case the idea of redistributing it crosses their mind.
> > 
> > I don't dispute that, only that I can't continue with the install unless
> > I click on "I Accept" to the GNU GPL.
> 
> Then, simply changing the button text from "I accept" to "Continue" 
> should be OK?

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.

-- 
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] GIT 1.5.4

[Luciano Rocha]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

On Thu, Feb 07, 2008 at 04:53:43PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 7 Feb 2008, Nicolas Pitre wrote:
> 
> > Then, simply changing the button text from "I accept" to "Continue" 
> > should be OK?
> 
> I consider this bike-shedding, git-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.

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.

-- 
Luciano Rocha <luciano-YWehAnL2kLNBDgjK7y7TUQ@public.gmane.org>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] GIT 1.5.4

[Luciano Rocha]

[-- Attachment #1: Type: text/plain, Size: 3897 bytes --]

On Thu, Feb 07, 2008 at 06:40:28PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 7 Feb 2008, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> writes:
> > 
> > > 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.
> > 
> > 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.
> 
> 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.

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



>   If you are not okay with accepting a tit-for-tat license, well... I'll 
>   not give you "tat".

I never said I was. I mean, would I had sent a patch to this list if I
wasn't OK with the license?

> So there is really nothing that I can think of, which would change my mind 
> about that "issue".

I was asking for the reasons for the installer being like it is, not for
you to change your mind.

-- 
Luciano Rocha <luciano-YWehAnL2kLNBDgjK7y7TUQ@public.gmane.org>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

Hi,

On Thu, 7 Feb 2008, Luciano Rocha wrote:

> I was asking for the reasons for the installer being like it is, not for 
> you to change your mind.

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

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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

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 to
install unless the end user agrees with it.

>   If you are not okay with accepting a tit-for-tat license, well... I'll 
>   not give you "tat".

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

Re: [ANNOUNCE] GIT 1.5.4

[Dmitry Potapov]

On Thu, Feb 07, 2008 at 12:31:09PM +0000, Luciano Rocha wrote:
> 
> 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).
> 

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

Re: [ANNOUNCE] GIT 1.5.4

[Linus Torvalds]

On Thu, 7 Feb 2008, Junio C Hamano wrote:
> 
> 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 to
> install unless the end user agrees with it.

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

Re: [ANNOUNCE] GIT 1.5.4

[Dmitry Potapov]

On Thu, Feb 07, 2008 at 11:42:59AM -0800, Junio C Hamano wrote:
> 
> 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.

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

Re: [ANNOUNCE] GIT 1.5.4

[Steffen Prohaska]

On Feb 7, 2008, at 8:59 PM, Linus Torvalds wrote:
>
> On Thu, 7 Feb 2008, Junio C Hamano wrote:
>>
>> 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 to
>> install unless the end user agrees with it.
>
> 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.

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

Re: [ANNOUNCE] GIT 1.5.4

[Jeremy Maitin-Shepard]

Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> writes:

> Hi,
> On Thu, 7 Feb 2008, Luciano Rocha wrote:

>> I was asking for the reasons for the installer being like it is, not for 
>> you to change your mind.

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

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

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Jonathan del Strother]

On Feb 7, 2008 8:23 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Thu, Feb 07, 2008 at 11:42:59AM -0800, Junio C Hamano wrote:
> >
> > 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.
>
> 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.
>

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?

Re: [ANNOUNCE] GIT 1.5.4

[Dmitry Potapov]

On Thu, Feb 07, 2008 at 09:49:45PM +0000, Jonathan del Strother wrote:
> 
> 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

Re: [ANNOUNCE] GIT 1.5.4

[Jari Aalto]

* Thu 2008-02-07 Johannes Schindelin-Mmb7MZpHnFY <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org>
* Message-Id: alpine.LSU.1.00.0802071831520.8543-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org
> The reasoning for showing the GPL in the Git installer..in favour, for two 
> reasons:
>
> - the end users should really know that the software is licensed in a 
>   pretty free way.

No they don't. The git binary is free in its distributable form and
needs therefore no such "EULA to be clicked".

Git is distributed everywhere else without "press the button to
bypass/accept/whatever reading the GPL". Let's not make some platform,
and a specific version of it, an exception.

FYI, Windows / Cygwin, version does not require user to click past such
"EULA".

> - _every_ serious Windows program comes with a click-through license.  We 
>   just don't want to be left behind.

No they don't. Have a look at vast number of Freeware software out there
www.nonags.com, tucows etc. They do not at all require such measures.

And yes, Freeware is serious software for Windows users.

> - even if it would be not necessary to accept the license (which I am not 
>   at all sure about

Redhat, The big company, has allowed the hosted Cygwin project to
distribute GPL software for ages under Windows. And their lawyers *have*
certainly checked that Cygwin installer does not need user to click "GPL
EULA" to have Cygwin installed.

That pretty much proves that there is no need for "read LICENCE to
install" button to be present.

Jari

-- 
Welcome to FOSS revolution: we fix and modify until it shines

Re: [ANNOUNCE] GIT 1.5.4

[Linus Torvalds]

On Fri, 8 Feb 2008, Dmitry Potapov wrote:
> 
> 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...

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

Re: [msysGit] Re: [ANNOUNCE] GIT 1.5.4

[Johannes Schindelin]

Hi,

On Thu, 7 Feb 2008, Steffen Prohaska wrote:

> On Feb 7, 2008, at 8:59 PM, Linus Torvalds wrote:
> > 
> > On Thu, 7 Feb 2008, Junio C Hamano wrote:
> > > 
> > > 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 to install unless the end 
> > > user agrees with it.
> > 
> > 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.
> 
> 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".

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

Re: [ANNOUNCE] GIT 1.5.4

[Schuberth, Sebastian]

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

Actually, the modification was trivial, I'm now using "InfoBeforeFile"
instead of "LicenseFile". I've pushed Steffen the change.

-- 
Sebastian

Re: [ANNOUNCE] GIT 1.5.4

[Steffen Prohaska]

On Feb 8, 2008, at 10:22 AM, Schuberth, Sebastian wrote:

>
>>> 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".
>>
>> 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.
>
> Actually, the modification was trivial, I'm now using "InfoBeforeFile"
> instead of "LicenseFile". I've pushed Steffen the change.

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

Re: [ANNOUNCE] GIT 1.5.4

[Andreas Ericsson]

Nicolas Pitre wrote:
> On Thu, 7 Feb 2008, Luciano Rocha wrote:
> 
>> On Thu, Feb 07, 2008 at 12:55:58PM +0000, Johannes Schindelin wrote:
>>> Hi,
>>>
>>> On Thu, 7 Feb 2008, Luciano Rocha wrote:
>>>
>>>> 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.
>>
>>> Get over it, or use another SCM,
>> I like and use GPL, but I won't force my users to accept the GPL in
>> order to use programs released under it.
> 
> 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.
> 

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-n0Zl8IkGad4@public.gmane.org
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231