* Re: "git gc" doesn't seem to remove loose objects any more
From: Jakub Narebski @ 2008-12-15 17:07 UTC (permalink / raw)
To: Theodore Tso; +Cc: Björn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Björn Steinbrink wrote:
> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
> > so that git prune can drop them. And git gc invokes git prune so that
> > only unreachable objects older than 2 weeks are dropped.
>
> To be even more explicit, "git gc" will **unpack** objects that have
> become unreachable and were currently in packs. As a result, the
> amount of disk space used by a git repository can actually go **up**
> dramatically after a "git gc" operation, which could be surprising for
> someone who is running close to full on their filesystem, deletes a
> number of branches from a tracking repository, and then does a "git
> gc" may get a very unpleasant surprise.
>
> A really good repository which shows this is linux-next, since it is
> constantly getting rewound, and old branches are reserved via a tag
> such as next-20081204. If you update the your local copy of the
> linux-next repository every day, you will accumulate a large number of
> these old branch tags. If you then delete a whole series of them, and
> run git-gc, the operation will take quite a while, and the number of
> blocks and inodes used will grow significantly. They will disappear
> after a "git prune", but when I do this housekeeping operation, I've
> often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-
> just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
> option to "git gc".
There was an idea to have "git gc --prune" run "git prune"
unconditionally, i.e. without grace period for dangling loose objects.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: hooks/post-update execs git-update-server-info
From: Jakub Narebski @ 2008-12-15 17:06 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <gi600m$tts$2@ger.gmane.org>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> shouldn't .git/hooks/post-update contain "exec git
> update-server-info" (note the space not hyphen) instead of
> "exec git-update-server-info"?
>
> Either I am horribly confused or HTTP pulls have not been
> working on post 1.6 gits and no one has noticed till now :-)
If I understand correctly hooks run with GIT_EXEC_PATH prepended to
PATH, so everything should work; and it has to work to not force users
to upgrade their (perhaps customized) hooks after upgrading git.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Johan Herland @ 2008-12-15 16:59 UTC (permalink / raw)
To: git
Cc: Mark Brown, Theodore Tso, Bj?rn Steinbrink, Mikael Magnusson,
Bruce Stephens
In-Reply-To: <20081215161212.GE31145@sirena.org.uk>
On Monday 15 December 2008, Mark Brown wrote:
> On Mon, Dec 15, 2008 at 10:56:10AM -0500, Theodore Tso wrote:
> > On Mon, Dec 15, 2008 at 03:08:34PM +0100, Bj?rn Steinbrink wrote:
> > > To clarify that a bit more: git gc keeps unreachable objects
> > > unpacked, so that git prune can drop them. And git gc invokes git
> > > prune so that only unreachable objects older than 2 weeks are
> > > dropped.
> >
> > To be even more explicit, "git gc" will **unpack** objects that
> > have become unreachable and were currently in packs. As a result,
> > the amount of disk space used by a git repository can actually go
> > **up** dramatically after a "git gc" operation, which could be
> > surprising for someone who is running close to full on their
> > filesystem, deletes a number of branches from a tracking
> > repository, and then does a "git gc" may get a very unpleasant
> > surprise.
>
> It can also cause things like the "please repack" warning in git gui
> to go off. This is especially unhelpful since they tend to tell you
> to go and do a gc to resolve the problem.
Instead of exploding all unreachable objects into loose objects, does it
make sense to repack them into a separate pack? AFAICS, that would
solve both the disk usage problem and the git-gui-"please repack"
problem. Also, it might make git-prune's job much easier, since
unreachable objects are now located in a single pack only?
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Mikael Magnusson @ 2008-12-15 16:59 UTC (permalink / raw)
To: Mark Brown; +Cc: Theodore Tso, Bj?rn Steinbrink, Bruce Stephens, git
In-Reply-To: <20081215161212.GE31145@sirena.org.uk>
2008/12/15 Mark Brown <broonie@sirena.org.uk>:
> On Mon, Dec 15, 2008 at 10:56:10AM -0500, Theodore Tso wrote:
>> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Bj?rn Steinbrink wrote:
>
>> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
>> > so that git prune can drop them. And git gc invokes git prune so that
>> > only unreachable objects older than 2 weeks are dropped.
>
>> To be even more explicit, "git gc" will **unpack** objects that have
>> become unreachable and were currently in packs. As a result, the
>> amount of disk space used by a git repository can actually go **up**
>> dramatically after a "git gc" operation, which could be surprising for
>> someone who is running close to full on their filesystem, deletes a
>> number of branches from a tracking repository, and then does a "git
>> gc" may get a very unpleasant surprise.
>
> It can also cause things like the "please repack" warning in git gui to
> go off. This is especially unhelpful since they tend to tell you to go
> and do a gc to resolve the problem.
A thought that occurs to me is to add some sort of flag to git count-objects
that prints the number of objects older than some interval in a separate field.
That way git gui would give less (maybe no) false alarms.
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Brandon Casey @ 2008-12-15 16:51 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Markus Heidelberg, gitster, git
In-Reply-To: <20081214111213.GA6499@coredump.intra.peff.net>
Jeff King wrote:
> On Sun, Dec 14, 2008 at 11:38:17AM +0100, Johannes Schindelin wrote:
>
>>> - __gitcomp "--prune --aggressive"
>>> + __gitcomp "--aggressive"
>> git gc --prune is deprecated? That's news to me.
>
> Check out 9e7d501 (builtin-gc.c: deprecate --prune, it now really has no
> effect, 2008-05-09).
>
> Which annoyingly has no discussion about _why_ it no longer has an
> effect. But I suspect it has something to do with 25ee973 (gc: call
> "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
I think the nail in the coffin for --prune was a37cce3b, which preceded
9e7d501. I guess the commit message for 9e7d501 made sense with a37cce3b
as a reference. There was another commit around the same time which
claimed that --prune was deprecated even though it still provided some
functionality, hence the "...really has no effect" part.
I definitely remember that Johannes implemented the gc.pruneExpire
functionality, so his "That's news to me" made me laugh. Thanks for
the chuckle Johannes. :)
-brandon
^ permalink raw reply
* Re: Interactive rebase encoding
From: Johannes Schindelin @ 2008-12-15 16:56 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812150821g4a032af0u31425fd7f4c0fd9@mail.gmail.com>
Hi,
On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
> On Mon, Dec 15, 2008 at 6:54 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > Indeed, I cannot think of any scenario where it might make sense to
> > have a different encoding in git rebase -i than in git log.
>
> For IDE, it might make sense to force UTF-8 encoding instead of using
> currently configured logoutputencoding.
I consider rebase -i to be porcelain, and as such not suitable to be used
as a backend for an IDE. Help the git-sequencer effort if you want a
plumbing.
Ciao,
Dscho
^ permalink raw reply
* [Q] Interactive rebase and editor failure
From: Constantine Plotnikov @ 2008-12-15 16:37 UTC (permalink / raw)
To: git
The git rebase -i detects situation if the editor exits with non-zero
exit code and displays error in such case.
However in this case for some reason, the rebase operation is not
aborted. What is the reason behind this logic? Is it the bug or
feature?
Constantine
^ permalink raw reply
* Re: Interactive rebase encoding
From: Constantine Plotnikov @ 2008-12-15 16:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812151652400.30769@pacific.mpi-cbg.de>
On Mon, Dec 15, 2008 at 6:54 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
>
>> The interactive rebase command builds a text file and passes it to
>> editor specified as environment variable or as configuration parameter.
>> However the man page for rebase operation says nothing about which
>> encoding will be used for that file. Apparently i18n.logoutputencoding
>> is used.
>
> As rebase -i does nothing else than piping the output of git log into a
> file (at least this is the first step), I thought it would be obvious that
> it uses the output encoding preferred by the user.
Yes. That was my first hypothesis, but I had to check it through small
experiment and source code examination. And if consider the bug
described in the thread
http://kerneltrap.org/mailarchive/git/2008/11/11/4063184, the
hypothesis might have been incorrect.
>
> Indeed, I cannot think of any scenario where it might make sense to have a
> different encoding in git rebase -i than in git log.
>
For IDE, it might make sense to force UTF-8 encoding instead of using
currently configured logoutputencoding. Currently the extra call to
git config is needed to check expected encoding of the file before
data could be shown to the user. Also user specified encoding might
fail to display some characters in commit messages that was encoded
using other encodings, forcing UTF-8 would have also fixed this
problem as well.
BTW for IDEs an option that causes non-abbreviated commit hashes would
have been useful as well.
Constantine
^ permalink raw reply
* [TortoiseGit]: Anyone seen this challenge?
From: Tim Visher @ 2008-12-15 16:20 UTC (permalink / raw)
To: git
Anyone aware of this challenge?
http://github.com/blog/256-tortoisegit-challenge
They've noted the existence of the google code project.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* hooks/post-update execs git-update-server-info
From: Sitaram Chamarty @ 2008-12-15 16:18 UTC (permalink / raw)
To: git
shouldn't .git/hooks/post-update contain "exec git
update-server-info" (note the space not hyphen) instead of
"exec git-update-server-info"?
Either I am horribly confused or HTTP pulls have not been
working on post 1.6 gits and no one has noticed till now :-)
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Mark Brown @ 2008-12-15 16:12 UTC (permalink / raw)
To: Theodore Tso; +Cc: Bj?rn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
On Mon, Dec 15, 2008 at 10:56:10AM -0500, Theodore Tso wrote:
> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Bj?rn Steinbrink wrote:
> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
> > so that git prune can drop them. And git gc invokes git prune so that
> > only unreachable objects older than 2 weeks are dropped.
> To be even more explicit, "git gc" will **unpack** objects that have
> become unreachable and were currently in packs. As a result, the
> amount of disk space used by a git repository can actually go **up**
> dramatically after a "git gc" operation, which could be surprising for
> someone who is running close to full on their filesystem, deletes a
> number of branches from a tracking repository, and then does a "git
> gc" may get a very unpleasant surprise.
It can also cause things like the "please repack" warning in git gui to
go off. This is especially unhelpful since they tend to tell you to go
and do a gc to resolve the problem.
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Theodore Tso @ 2008-12-15 15:56 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215140834.GA3684@atjola.homenet>
On Mon, Dec 15, 2008 at 03:08:34PM +0100, Björn Steinbrink wrote:
> To clarify that a bit more: git gc keeps unreachable objects unpacked,
> so that git prune can drop them. And git gc invokes git prune so that
> only unreachable objects older than 2 weeks are dropped.
To be even more explicit, "git gc" will **unpack** objects that have
become unreachable and were currently in packs. As a result, the
amount of disk space used by a git repository can actually go **up**
dramatically after a "git gc" operation, which could be surprising for
someone who is running close to full on their filesystem, deletes a
number of branches from a tracking repository, and then does a "git
gc" may get a very unpleasant surprise.
A really good repository which shows this is linux-next, since it is
constantly getting rewound, and old branches are reserved via a tag
such as next-20081204. If you update the your local copy of the
linux-next repository every day, you will accumulate a large number of
these old branch tags. If you then delete a whole series of them, and
run git-gc, the operation will take quite a while, and the number of
blocks and inodes used will grow significantly. They will disappear
after a "git prune", but when I do this housekeeping operation, I've
often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-
just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
option to "git gc".
- Ted
^ permalink raw reply
* Re: Interactive rebase encoding
From: Johannes Schindelin @ 2008-12-15 15:54 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812150442n48609eadl4f3e47fcc715e643@mail.gmail.com>
Hi,
On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
> The interactive rebase command builds a text file and passes it to
> editor specified as environment variable or as configuration parameter.
> However the man page for rebase operation says nothing about which
> encoding will be used for that file. Apparently i18n.logoutputencoding
> is used.
As rebase -i does nothing else than piping the output of git log into a
file (at least this is the first step), I thought it would be obvious that
it uses the output encoding preferred by the user.
Indeed, I cannot think of any scenario where it might make sense to have a
different encoding in git rebase -i than in git log.
Ciao,
Dscho
^ permalink raw reply
* Re: Interactive rebase encoding
From: Miklos Vajna @ 2008-12-15 15:13 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812150442n48609eadl4f3e47fcc715e643@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
On Mon, Dec 15, 2008 at 03:42:08PM +0300, Constantine Plotnikov <constantine.plotnikov@gmail.com> wrote:
> The interactive rebase command builds a text file and passes it to
> editor specified as environment variable or as configuration
> parameter. However the man page for rebase operation says nothing
> about which encoding will be used for that file. Apparently
> i18n.logoutputencoding is used. I think that the man page for rebase
> operation should explicitly specify it.
Care to send a patch?
> Also it might make sense to use explicit encoding parameter for
> interactive rebase operation.
Do you have a use-case where having a different encoding for log output
and rebase -i todo list makes sense?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] gitweb: unify boolean feature subroutines
From: Matt Kraai @ 2008-12-15 14:51 UTC (permalink / raw)
To: git, gitster; +Cc: Matt Kraai
In-Reply-To: <1229352709-4663-1-git-send-email-kraai@ftbfs.org>
The boolean feature subroutines were identical except for the name of
the configuration option, so make that a parameter and unify them.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
gitweb/gitweb.perl | 35 ++++++-----------------------------
1 files changed, 6 insertions(+), 29 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 145e712..827e5c5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -203,7 +203,7 @@ our %feature = (
# $feature{'blame'}{'override'} = 1;
# and in project config gitweb.blame = 0|1;
'blame' => {
- 'sub' => \&feature_blame,
+ 'sub' => sub { feature_bool('blame', @_) },
'override' => 0,
'default' => [0]},
@@ -241,7 +241,7 @@ our %feature = (
# $feature{'grep'}{'override'} = 1;
# and in project config gitweb.grep = 0|1;
'grep' => {
- 'sub' => \&feature_grep,
+ 'sub' => sub { feature_bool('grep', @_) },
'override' => 0,
'default' => [1]},
@@ -255,7 +255,7 @@ our %feature = (
# $feature{'pickaxe'}{'override'} = 1;
# and in project config gitweb.pickaxe = 0|1;
'pickaxe' => {
- 'sub' => \&feature_pickaxe,
+ 'sub' => sub { feature_bool('pickaxe', @_) },
'override' => 0,
'default' => [1]},
@@ -363,8 +363,9 @@ sub gitweb_check_feature {
}
-sub feature_blame {
- my ($val) = git_get_project_config('blame', '--bool');
+sub feature_bool {
+ my $key = shift;
+ my ($val) = git_get_project_config($key, '--bool');
if ($val eq 'true') {
return (1);
@@ -387,30 +388,6 @@ sub feature_snapshot {
return @fmts;
}
-sub feature_grep {
- my ($val) = git_get_project_config('grep', '--bool');
-
- if ($val eq 'true') {
- return (1);
- } elsif ($val eq 'false') {
- return (0);
- }
-
- return ($_[0]);
-}
-
-sub feature_pickaxe {
- my ($val) = git_get_project_config('pickaxe', '--bool');
-
- if ($val eq 'true') {
- return (1);
- } elsif ($val eq 'false') {
- return (0);
- }
-
- return ($_[0]);
-}
-
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitweb: make feature_blame return a list
From: Matt Kraai @ 2008-12-15 14:51 UTC (permalink / raw)
To: git, gitster; +Cc: Matt Kraai
The feature defaults are expected to be a list, but feature_blame was
returning a scalar. This change makes it consistent with the other
boolean feature subroutines.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
gitweb/gitweb.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..145e712 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -367,12 +367,12 @@ sub feature_blame {
my ($val) = git_get_project_config('blame', '--bool');
if ($val eq 'true') {
- return 1;
+ return (1);
} elsif ($val eq 'false') {
- return 0;
+ return (0);
}
- return $_[0];
+ return ($_[0]);
}
sub feature_snapshot {
--
1.5.6.5
^ permalink raw reply related
* Re: Followup: management of OO files - warning about "rezip" approach
From: Peter Krefting @ 2008-12-15 14:41 UTC (permalink / raw)
To: Sergio Callegari; +Cc: Git Mailing List
In-Reply-To: <loom.20081214T123442-862@post.gmane.org>
Sergio Callegari:
> E.g. patch the rezip script so that
>
> PROFILE_UNZIP_ODF_UNCOMPRESS='-b -qq'
> PROFILE_ZIP_ODF_UNCOMPRESS='-q -r -D -0 -X'
> PROFILE_UNZIP_ODF_COMPRESS='-b -qq'
> PROFILE_ZIP_ODF_COMPRESS='-q -r -D -6 -X'
Yeah, that is exactly what I ended up doing.
I've been running the rezip script for quite a long time now,
versioning a spreadsheet that I update by adding stuff to up to several
times a week. Using this approach has shrunk the compressed .git
directory by about 90 % (before I started using rezip, it was about 9
megabytes, with rezip and 30 % more commits, it is now 1 megabyte).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Li Frank @ 2008-12-15 14:19 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <200812151456.27750.jnareb@gmail.com>
It is correct! Thanks
Best regards
Frank Li
2008/12/15 Jakub Narebski <jnareb@gmail.com>:
> On Sun, 14 Dec 2008, Li Frank wrote:
>
>>
>> 2008/12/14 Jakub Narebski <jnareb@gmail.com>:
>>> "李智" <lznuaa@gmail.com> writes:
>>>
>>>> TortoiseGit is porting from TortoiseSVN. It is explore extension.
>>>> This version just finish a minimum set of TortoiseSVN porting
>>>
>>> How it differs from GitCheetah project?
>> GitCheetah just show git-gui &git-bash at context menu!
>>
>> TortoiseGit is full porting from TortoiseSVN. Overlay icon can show
>> modified file, add file and conflicted file whith different icon.
>>
>> TortoiseGit can commit change, show log, checkout ... at Context menu!
>> It is full git fontend.
>
>>> [...]
>>>> Project Home Page at:
>>>> http://code.google.com/p/tortoisegit/
>>>>
>>>> Source code at
>>>> http://repo.or.cz/w/TortoiseGit.git
>>>>
>>>> It need msysgit 1.6.0.2.
>>>
>>> Do you feel it is mature enough to be added to git wiki page
>>> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>>> just above "Git Extensions" entry? Would you do it, or should
>>> I do this?
>>
>> TortoiseGit is in very early stage. I just implement min set feature
>> and not mature . I hope there are more and more people involve this
>> project and make it mature as TortoiseSVN.
>
> I have added information about TortoiseGit to git wiki at
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-803ff1eef7a32fd1d8fe86713de343af18605047
>
> Please correct it if the information there (copy below) is wrong.
> Feel free to extend this short info.
>
> Hopefully this way more people would find your project, and be able
> to contribute to it.
>
>
> === TortoiseGit ===
>
> TortoiseGit[1] (gitweb[2]) by Li Frank is a port of TortoiseSVN[3]
> to Git. It is Microsoft Windows shell (Explorer) extension, written
> in C++. TortoiseGit is in very early stages of development,
> implementing currently only minimal set of features.
>
> [1] http://code.google.com/p/tortoisegit/
> [2] http://repo.or.cz/w/TortoiseGit.git
> [3] http://tortoisesvn.tigris.org/
>
> --
> Jakub Narebski
> Poland
>
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Björn Steinbrink @ 2008-12-15 14:08 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Bruce Stephens, git
In-Reply-To: <237967ef0812150538n671c22b8gaf7a7b5dcaf68433@mail.gmail.com>
On 2008.12.15 14:38:56 +0100, Mikael Magnusson wrote:
> 2008/12/15 Bruce Stephens <bruce.stephens@isode.com>:
> > I couldn't see a test for this, but perhaps I'm just missing it?
> >
> > brs% git count-objects
> > 161 objects, 1552 kilobytes
> > brs% git gc
> > Counting objects: 80621, done.
> > Compressing objects: 100% (22372/22372), done.
> > Writing objects: 100% (80621/80621), done.
> > Total 80621 (delta 57160), reused 80305 (delta 56884)
> > brs% git count-objects
> > 207 objects, 2048 kilobytes
> >
> >
> > And I see lots of directories under .git/objects which confirms
> > things.
> >
> > I don't think I've changed any relevant configuration.
> >
> > This is with 8befc50c49e8a271fd3cd7fb34258fe88d1dfcad (also whatever
> > version I used before, erm, probably
> > de0db422782ddaf7754ac5b03fdc6dc5de1a9ae4), and possibly earlier
> > versions---I've just started noticing now that the number of loose
> > objects has started causing git gui to complain.
> >
> > (Hmm, I note that git gui reports a larger number of loose objects
> > than git count-objects. Ah, OK, it really is just an approximation,
> > so no surprise.)
>
> IIRC git gc only removes loose objects older than two weeks, if you
> really want to remove them now, run git prune. But make sure no other
> git process can be active when you run it, or it could possibly step
> on something.
To clarify that a bit more: git gc keeps unreachable objects unpacked,
so that git prune can drop them. And git gc invokes git prune so that
only unreachable objects older than 2 weeks are dropped.
Björn
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Bruce Stephens @ 2008-12-15 14:08 UTC (permalink / raw)
To: git
In-Reply-To: <237967ef0812150538n671c22b8gaf7a7b5dcaf68433@mail.gmail.com>
"Mikael Magnusson" <mikachu@gmail.com> writes:
[...]
> IIRC git gc only removes loose objects older than two weeks, if you
> really want to remove them now, run git prune. But make sure no other
> git process can be active when you run it, or it could possibly step
> on something.
OK, that makes sense. Obviously I misunderstood this. That doesn't
explain why the number of objects might increase after "git gc", but
perhaps that's for a good reason too.
Surely "git gui"'s warning is unhelpful, then: it warns I have more
than 2000 loose objects (in another checkout), offers to compress my
database, and I end up with an unchanged repository (which it still
complains about)? Is this warning just redundant now that we've got
"git gc --auto"?
^ permalink raw reply
* Re: [RFCv4 1/3] gitweb: add patch view
From: Jakub Narebski @ 2008-12-15 13:58 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0812150548w526a8c0eu13ec95785e0ab824@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Mon, Dec 15, 2008 at 2:17 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> + my $patch_max;
>>> + if ($format eq 'patch') {
>>> + $patch_max = gitweb_check_feature('patches');
>>> + die_error(403, "Patch view not allowed") unless $patch_max;
>>> + }
>>> +
>>
>> Hmmm... gitweb_check_feature
>
> You're right, it's an abuse. I'll make it gitweb_get_feature()[0]
Or better
+ ($patch_max) = gitweb_get_feature('patches');
[...]
> As soon as you finish the patchset review I'll have a new version
> taking into consideration all the other suggestions and remarks I
> snipped from this reply.
Thank you very much for keeping this patch series alive.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Jakub Narebski @ 2008-12-15 13:56 UTC (permalink / raw)
To: Li Frank; +Cc: git
In-Reply-To: <1976ea660812140529k1499b410u4437645be0dc7dfc@mail.gmail.com>
On Sun, 14 Dec 2008, Li Frank wrote:
>
> 2008/12/14 Jakub Narebski <jnareb@gmail.com>:
>> "李智" <lznuaa@gmail.com> writes:
>>
>>> TortoiseGit is porting from TortoiseSVN. It is explore extension.
>>> This version just finish a minimum set of TortoiseSVN porting
>>
>> How it differs from GitCheetah project?
> GitCheetah just show git-gui &git-bash at context menu!
>
> TortoiseGit is full porting from TortoiseSVN. Overlay icon can show
> modified file, add file and conflicted file whith different icon.
>
> TortoiseGit can commit change, show log, checkout ... at Context menu!
> It is full git fontend.
>> [...]
>>> Project Home Page at:
>>> http://code.google.com/p/tortoisegit/
>>>
>>> Source code at
>>> http://repo.or.cz/w/TortoiseGit.git
>>>
>>> It need msysgit 1.6.0.2.
>>
>> Do you feel it is mature enough to be added to git wiki page
>> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>> just above "Git Extensions" entry? Would you do it, or should
>> I do this?
>
> TortoiseGit is in very early stage. I just implement min set feature
> and not mature . I hope there are more and more people involve this
> project and make it mature as TortoiseSVN.
I have added information about TortoiseGit to git wiki at
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-803ff1eef7a32fd1d8fe86713de343af18605047
Please correct it if the information there (copy below) is wrong.
Feel free to extend this short info.
Hopefully this way more people would find your project, and be able
to contribute to it.
=== TortoiseGit ===
TortoiseGit[1] (gitweb[2]) by Li Frank is a port of TortoiseSVN[3]
to Git. It is Microsoft Windows shell (Explorer) extension, written
in C++. TortoiseGit is in very early stages of development,
implementing currently only minimal set of features.
[1] http://code.google.com/p/tortoisegit/
[2] http://repo.or.cz/w/TortoiseGit.git
[3] http://tortoisesvn.tigris.org/
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFCv4 1/3] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-15 13:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200812151417.16372.jnareb@gmail.com>
On Mon, Dec 15, 2008 at 2:17 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> + my $patch_max;
>> + if ($format eq 'patch') {
>> + $patch_max = gitweb_check_feature('patches');
>> + die_error(403, "Patch view not allowed") unless $patch_max;
>> + }
>> +
>
> Hmmm... gitweb_check_feature
You're right, it's an abuse. I'll make it gitweb_get_feature()[0]
> I am wondering if we could somehow mark (encode) either $hash_parent
> or number of patches in proposed filename... but I don't think it is
> worth it.
Including hash_parent if defined is quite possible. I'm not sure it's
really worth it considering that the typical usage would be to publish
a patchset for a particular feature (in which case the hash/branch
name would be enough).
>> + } elsif ($format eq 'patch') {
>> + local $/ = undef;
>> + print <$fd>;
>> + close $fd
>> + or print "Reading git-format-patch failed\n";
>
> Nice, although... I'd prefer for Perl expert to say if it is better
> to dump file as a whole in such way (it might be quite large), or
> to do it line by line, i.e. without "local $/ = undef;", or using
> "print while <$fd>;" also without "local $/ = undef;".
I'm just sticking to whatever the existing code does :-)
As soon as you finish the patchset review I'll have a new version
taking into consideration all the other suggestions and remarks I
snipped from this reply.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Mikael Magnusson @ 2008-12-15 13:38 UTC (permalink / raw)
To: Bruce Stephens; +Cc: git
In-Reply-To: <808wqhzjl9.fsf@tiny.isode.net>
2008/12/15 Bruce Stephens <bruce.stephens@isode.com>:
> I couldn't see a test for this, but perhaps I'm just missing it?
>
> brs% git count-objects
> 161 objects, 1552 kilobytes
> brs% git gc
> Counting objects: 80621, done.
> Compressing objects: 100% (22372/22372), done.
> Writing objects: 100% (80621/80621), done.
> Total 80621 (delta 57160), reused 80305 (delta 56884)
> brs% git count-objects
> 207 objects, 2048 kilobytes
>
>
> And I see lots of directories under .git/objects which confirms
> things.
>
> I don't think I've changed any relevant configuration.
>
> This is with 8befc50c49e8a271fd3cd7fb34258fe88d1dfcad (also whatever
> version I used before, erm, probably
> de0db422782ddaf7754ac5b03fdc6dc5de1a9ae4), and possibly earlier
> versions---I've just started noticing now that the number of loose
> objects has started causing git gui to complain.
>
> (Hmm, I note that git gui reports a larger number of loose objects
> than git count-objects. Ah, OK, it really is just an approximation,
> so no surprise.)
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
IIRC git gc only removes loose objects older than two weeks, if you
really want to remove them now, run git prune. But make sure no other
git process can be active when you run it, or it could possibly step
on something.
--
Mikael Magnusson
^ permalink raw reply
* Re: [RFCv4 1/3] gitweb: add patch view
From: Jakub Narebski @ 2008-12-15 13:17 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1228575755-13432-2-git-send-email-giuseppe.bilotta@gmail.com>
On Sat, 6 Dec 2008, Giuseppe Bilotta wrote:
> The output of commitdiff_plain is not intended for git-am:
> * when given a range of commits, commitdiff_plain publishes a single
> patch with the message from the first commit, instead of a patchset
> * the hand-built email format replicates the commit summary both as
> email subject and as first line of the email itself, resulting in
> a duplication if the output is used with git-am.
>
> We thus create a new view that can be fed to git-am directly, allowing
> patch exchange via gitweb. The new view exposes the output of git
> format-patch directly, limiting it to a single patch in the case of a
> single commit.
>
> A configurable upper limit is imposed on the number of commits which
> will be included in a patchset, to prevent DoS attacks on the server.
> Setting the limit to 0 will disable the patch view, setting it to a
> negative number will remove the limit.
It would be good to have in commit mesage what is the default upper
limit (or if we decide to have this feature turned off by default,
proposed limit to choose when enabling this feature).
Does limit of 16 patches have any numbers behind it? We use page size
of 100 commits for 'shortlog', 'log' and 'history' views, but for
those views we don't need to generate patches (which is slower). From
a few tests "git log -100" is faster than "git format-patch -100 --stdout"
about 30 times in warm cache case, and about 1.7 times in cold cache
case.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Other than that minor detail I like this patch
> ---
> gitweb/gitweb.perl | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 64 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 95988fb..71d5af4 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -329,6 +329,14 @@ our %feature = (
> 'ctags' => {
> 'override' => 0,
> 'default' => [0]},
> +
> + # The maximum number of patches in a patchset generated in patch
> + # view. Set this to 0 or undef to disable patch view, or to a
> + # negative number to remove any limit.
I think it would be nice to have standard boilerplate explanation how
to change it, and how to override it, with the addition on how to
disable it from repository config, because it is not very obvious.
Something like:
+ # To disable system wide have in $GITWEB_CONFIG
+ # $feature{'patches'}{'default'} = [];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'patches'}{'override'} = 1;
+ # and in project config, maximum number of patches in a patchset
+ # or 0 to disable. Example: gitweb.patches = 0
> + 'patches' => {
> + 'sub' => \&feature_patches,
> + 'override' => 0,
> + 'default' => [16]},
> );
>
> sub gitweb_get_feature {
> @@ -410,6 +418,19 @@ sub feature_pickaxe {
> return ($_[0]);
> }
>
> +sub feature_patches {
> + my @val = (git_get_project_config('patches', '--int'));
> +
> + # if @val is empty, the config is not (properly)
> + # overriding the feature, so we return the default,
> + # otherwise we pick the override
Very similar feature_snapshot subroutine doesn't have such comment.
I don't think it is necessary, and its wording might cause confusion.
> + if (@val) {
> + return @val;
> + }
> +
> + return ($_[0]);
> +}
> +
Nice.
> # checking HEAD file with -e is fragile if the repository was
> # initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
> # and then pruned.
> @@ -503,6 +524,7 @@ our %actions = (
> "heads" => \&git_heads,
> "history" => \&git_history,
> "log" => \&git_log,
> + "patch" => \&git_patch,
> "rss" => \&git_rss,
> "atom" => \&git_atom,
> "search" => \&git_search,
> @@ -5386,6 +5408,13 @@ sub git_blobdiff_plain {
>
> sub git_commitdiff {
> my $format = shift || 'html';
> +
> + my $patch_max;
> + if ($format eq 'patch') {
> + $patch_max = gitweb_check_feature('patches');
> + die_error(403, "Patch view not allowed") unless $patch_max;
> + }
> +
Hmmm... gitweb_check_feature
> $hash ||= $hash_base || "HEAD";
> my %co = parse_commit($hash)
> or die_error(404, "Unknown commit object");
> @@ -5483,7 +5512,23 @@ sub git_commitdiff {
> open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
> '-p', $hash_parent_param, $hash, "--"
> or die_error(500, "Open git-diff-tree failed");
> -
> + } elsif ($format eq 'patch') {
> + # For commit ranges, we limit the output to the number of
> + # patches specified in the 'patches' feature.
> + # For single commits, we limit the output to a single patch,
> + # diverging from the git format-patch default.
I think it would be more clear to use
+ # diverging from the git-format-patch default.
> + my @commit_spec = ();
> + if ($hash_parent) {
> + if ($patch_max > 0) {
> + push @commit_spec, "-$patch_max";
> + }
> + push @commit_spec, '-n', "$hash_parent..$hash";
> + } else {
> + push @commit_spec, '-1', '--root', $hash;
> + }
Nice solution. I like it.
> + open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
> + '--stdout', @commit_spec
> + or die_error(500, "Open git-format-patch failed");
> } else {
> die_error(400, "Unknown commitdiff format");
> }
> @@ -5532,6 +5577,14 @@ sub git_commitdiff {
> print to_utf8($line) . "\n";
> }
> print "---\n\n";
> + } elsif ($format eq 'patch') {
> + my $filename = basename($project) . "-$hash.patch";
I am wondering if we could somehow mark (encode) either $hash_parent
or number of patches in proposed filename... but I don't think it is
worth it.
> +
> + print $cgi->header(
> + -type => 'text/plain',
> + -charset => 'utf-8',
> + -expires => $expires,
> + -content_disposition => 'inline; filename="' . "$filename" . '"');
> }
>
> # write patch
> @@ -5553,6 +5606,11 @@ sub git_commitdiff {
> print <$fd>;
> close $fd
> or print "Reading git-diff-tree failed\n";
> + } elsif ($format eq 'patch') {
> + local $/ = undef;
> + print <$fd>;
> + close $fd
> + or print "Reading git-format-patch failed\n";
Nice, although... I'd prefer for Perl expert to say if it is better
to dump file as a whole in such way (it might be quite large), or
to do it line by line, i.e. without "local $/ = undef;", or using
"print while <$fd>;" also without "local $/ = undef;".
> }
> }
>
> @@ -5560,6 +5618,11 @@ sub git_commitdiff_plain {
> git_commitdiff('plain');
> }
>
> +# format-patch-style patches
> +sub git_patch {
> + git_commitdiff('patch');
> +}
> +
Nice.
> sub git_history {
> if (!defined $hash_base) {
> $hash_base = git_get_head_hash($project);
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox