Linus Torvalds [off-list ref] writes:
I personally repack everything way more often than is necessary, and I had
kind of assumed that people did it that way, but I was apparently wrong.
Comments?
I am as old timer as you are so I am not qualified to add much
variety to the discussion, but I agree that excessive cruft is
something we should warn the user about.
I personally was _extremely_ annoyed by git-cvsimport
occassionary deciding to repack whenever it finds more than
certain number of loose objects, not because it is a big import,
but because I happened to start the command to start a very
small import after doing my own development for a while to
accumulate loose objects, and I really hate automatic repacking
for any operation (or tool that thinks it knows better than I do
in general).
Perhaps _exiting_ "git-commit" and "git-fetch" before doing
anything, when the repository has more than 5000 loose objects
with a LOUD bang that instructs an immediate repack would be
good?
I really do not like the idea of automatically running a repack
after first interrupting the original command and then resuming.
For one thing it would make a horribly difficult situation to
debug if anything goes wrong. You cannot reproduce such a
situation easily.
Hi!
On Wed, Sep 05, 2007 at 00:30:35 -0700, Junio C Hamano wrote:
Perhaps _exiting_ "git-commit" and "git-fetch" before doing
anything, when the repository has more than 5000 loose objects
with a LOUD bang that instructs an immediate repack would be
good?
This may break automation. I run git-gc monthly via cron, but that
doesn't guarantee I won't get 5000 loose objects before that. And I
agree that automatic run is annoying. Perhaps simple BIG FAT WARNING
is the best after all.
--
Tomash Brechko
On Wednesday 05 September 2007, Junio C Hamano wrote:
Linus Torvalds [off-list ref] writes:
quoted
I personally repack everything way more often than is necessary, and I had
kind of assumed that people did it that way, but I was apparently wrong.
Comments?
I am as old timer as you are so I am not qualified to add much
variety to the discussion, but I agree that excessive cruft is
something we should warn the user about.
I personally was _extremely_ annoyed by git-cvsimport
occassionary deciding to repack whenever it finds more than
certain number of loose objects, not because it is a big import,
but because I happened to start the command to start a very
small import after doing my own development for a while to
accumulate loose objects, and I really hate automatic repacking
for any operation (or tool that thinks it knows better than I do
in general).
Perhaps _exiting_ "git-commit" and "git-fetch" before doing
anything, when the repository has more than 5000 loose objects
with a LOUD bang that instructs an immediate repack would be
good?
I really do not like the idea of automatically running a repack
after first interrupting the original command and then resuming.
For one thing it would make a horribly difficult situation to
debug if anything goes wrong. You cannot reproduce such a
situation easily.
What about some sort of middle ground:
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>, it exits immediately
without doing anything, but if the user answers "y", or if there is no
response, say, within a minute (i.e. the user went to lunch), the repack is
initiated. (Of course, the user should be told that a Ctrl-C will abort the
repack and not be harmful in any way.)
If the user answers "n" (or aborts the repack), the question will keep popping
up on the next git-{commit,fetch} to remind/annoy the user until a repack is
done.
...Johan
--
Johan Herland, [off-list ref]
www.herland.net
El 5/9/2007, a las 9:30, Junio C Hamano escribió:
Perhaps _exiting_ "git-commit" and "git-fetch" before doing
anything, when the repository has more than 5000 loose objects
with a LOUD bang that instructs an immediate repack would be
good?
I really do not like the idea of automatically running a repack
after first interrupting the original command and then resuming.
For one thing it would make a horribly difficult situation to
debug if anything goes wrong. You cannot reproduce such a
situation easily.
I would strongly oppose any *automatic* repacking and strongly
support any *advisory* recommandation to repack when the loose object
count exceeds a certain threshold. I don't think *exiting* a command
in such cases is a good idea; worse than automatic repacking this
would be *forced* manual repacking, which isn't very user-friendly.
Cheers,
Wincent