Re: People unaware of the importance of "git gc"?

Johan Herland [off-list ref] writes:

When git-fetch and git-commit has done its job and is about to exit, it checks 
the number of loose object, and if too high tells the user something 
like "There are too many loose objects in the repo, do you want me to repack? 
(y/N)". If the user answers "n" or simply <Enter>,

I don't like commands to be interactive if they don't _need_ to be so.
It kills scripting, it makes it hard for a front-end (git gui or so)
to use the command, ...

-- 
Matthieu

On Wednesday 05 September 2007, Matthieu Moy wrote:

Johan Herland [off-list ref] writes:

quoted

When git-fetch and git-commit has done its job and is about to exit, it checks 
the number of loose object, and if too high tells the user something 
like "There are too many loose objects in the repo, do you want me to repack? 
(y/N)". If the user answers "n" or simply <Enter>,

I don't like commands to be interactive if they don't _need_ to be so.
It kills scripting, it makes it hard for a front-end (git gui or so)
to use the command, ...

Ok, so add an option or config variable to turn on/off this behaviour.

...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

Johan Herland [off-list ref] writes:

On Wednesday 05 September 2007, Matthieu Moy wrote:

quoted

Johan Herland [off-list ref] writes:

quoted

When git-fetch and git-commit has done its job and is about to exit, it checks 
the number of loose object, and if too high tells the user something 
like "There are too many loose objects in the repo, do you want me to repack? 
(y/N)". If the user answers "n" or simply <Enter>,

I don't like commands to be interactive if they don't _need_ to be so.
It kills scripting, it makes it hard for a front-end (git gui or so)
to use the command, ...

Ok, so add an option or config variable to turn on/off this behaviour.

A bad idea which one can turn optionally off remains a bad idea for
everyone that has not been bitten enough by it already to actually
look up the problem and remedy.

Make this a warning.

-- 
David Kastrup

On Wed, Sep 05, 2007 at 08:39:52AM +0000, Matthieu Moy wrote:

Johan Herland [off-list ref] writes:

quoted

When git-fetch and git-commit has done its job and is about to exit, it checks 
the number of loose object, and if too high tells the user something 
like "There are too many loose objects in the repo, do you want me to repack? 
(y/N)". If the user answers "n" or simply <Enter>,

I don't like commands to be interactive if they don't _need_ to be so.
It kills scripting, it makes it hard for a front-end (git gui or so)
to use the command, ...

  There is absolutely no problem here, as it can be avoided if the
output is not a tty. It's not _that_ hard to guess if you're currently
running in a script or in an interactive shell after all.

  Really, git commit/fetch/... whatever suggesting to repack/gc when it
believes it begins to be critical to performance is not a bad idea.
Though the risk is that the warning could be printed very often, but
that can be avoided trivially by just writing to a state file in the
.git directory that the warning was printed not so long time ago, and
that git should STFU for some more commits/time.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Pierre Habouzit [off-list ref] writes:

On Wed, Sep 05, 2007 at 08:39:52AM +0000, Matthieu Moy wrote:

quoted

Johan Herland [off-list ref] writes:

quoted

When git-fetch and git-commit has done its job and is about to exit, it checks 
the number of loose object, and if too high tells the user something 
like "There are too many loose objects in the repo, do you want me to repack? 
(y/N)". If the user answers "n" or simply <Enter>,

I don't like commands to be interactive if they don't _need_ to be so.
It kills scripting, it makes it hard for a front-end (git gui or so)
to use the command, ...

  There is absolutely no problem here, as it can be avoided if the
output is not a tty.

Which output?  stdout?  stderr?  Where is the question appearing?
What if the command has been started in the background?  What if stdin
(not stdout) is from a pipe, maybe for taking a commit message?  What
if stdin is from a pseudo-tty because the commit has been started with
an internal shell command inside of Emacs, and the command/message
will only get echoed once git-commit completes?

It's not _that_ hard to guess if you're currently running in a
script or in an interactive shell after all.

Oh, it is not hard to _guess_.  Just throw a die.  What is hard is to
_know_ 100% sure that one is doing the right thing and not breaking
any legitimate use.

-- 
David Kastrup