* 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: "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: "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: 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: 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
* [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
* [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
* 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
* 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: "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: "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
* 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
* [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
* 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
* [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: 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
* 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: "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: "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: 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: 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: "git gc" doesn't seem to remove loose objects any more
From: Brandon Casey @ 2008-12-15 17:11 UTC (permalink / raw)
To: Theodore Tso; +Cc: Björn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
Theodore Tso wrote:
> 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".
repack -a -d -l
Notice the lowercase 'a'.
git-gc calls repack with uppercase 'A' which is what causes the unreachable
objects to be unpacked. Little 'a', is for people who know what they are
doing, and want git to just drop unreachable objects.
-brandon
^ permalink raw reply
* Re: [PATCH v2] git-branch: display sha1 on branch deletion
From: Brandon Casey @ 2008-12-15 17:23 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20081213063104.GA8480@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Dec 12, 2008 at 05:20:07PM -0600, Brandon Casey wrote:
>
>> Make it easier to recover from a mistaken branch deletion by displaying the
>> sha1 of the branch's tip commit.
>
> This version looks fine to me, but one nit:
>
>> - test "$(git branch -d my7 2>&1)" = "Deleted branch my7."'
>> + sha1=$(git rev-parse my7 | cut -c 1-7) &&
>> + test "$(git branch -d my7 2>&1)" = "Deleted branch my7 ($sha1)."'
>
> There is a very very small chance that this sha1 might require more
> than 7 characters to be unique (small because we have such a tiny number
> of objects in the trash repo).
Yeah I was counting on the smallness of that chance to let me be lazy and
not think about how to get the proper abbreviated sha1.
> Maybe:
>
> sha1=$(git log --pretty=format:%h -1 my7)
>
> is better (though I have to admit, if I were writing the test originally
> I would have tested the exit value of "git branch" instead of the
> message).
My feelings won't be hurt if you want to change it.
-brandon
^ permalink raw reply
* [PATCH v3] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-12-15 17:34 UTC (permalink / raw)
To: gitster, git; +Cc: jnareb, ae, j.sixt, Marcel M. Cary
In-Reply-To: <7v4p174diu.fsf@gitster.siamese.dyndns.org>
I want directories of my working tree to be linked to from various
paths on my filesystem where third-party components expect them, both
in development and production environments. A build system's install
step could solve this, but I develop scripts and web pages that don't
need to be built. Git's submodule system could solve this, but we
tend to develop, branch, and test those directories all in unison, so
one big repository feels more natural. We prefer to edit and commit
on the symlinked paths, not the canonical ones, and in that setting,
"git pull" fails to find the top-level directory of the repository
while other commands work fine.
"git pull" fails because POSIX shells have a notion of current working
directory that is different from getcwd(). The shell stores this path
in PWD. As a result, "cd ../" can be interpreted differently in a
shell script than chdir("../") in a C program. The shell interprets
"../" by essentially stripping the last textual path component from
PWD, whereas C chdir() follows the ".." link in the current directory
on the filesystem. When PWD is a symlink, these are different
destinations. As a result, Git's C commands find the correct
top-level working tree, and shell scripts do not.
Changes:
* When interpreting a relative upward (../) path in cd_to_toplevel,
prepend the cwd without symlinks, given by /bin/pwd
* Add tests for cd_to_toplevel and "git pull" in a symlinked
directory that failed before this fix, plus contrasting scenarios
that already worked
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
---
> > I also removed the "pwd -P" from the unit test.
>
> Hmm, really...?
Ouch. Removing just one occurrence won't help much, will it.
> > Do you think these test cases should run all the time here?
>
> I'd say so. Your supporting argument could be "See, push works just
> fine with this layout, but pull doesn't because it is a shell script
> that can be fooled, and this change is to fix the inconsistencies
> between them."
Ok, removed those cases from test_debug and emphasized in the first
paragraph of the commit message that other commands support this kind
of "sideways jumping."
> But whether it is inside test_debug or not, the test should check
> not just the exit status from 'git push' but also check what
> happened to the receiving repository at least to make sure it is
> pushing to the location you are expecting it to.
Ok, I did this by adding an additional file each time and checking the
same path in the other repository.
git-sh-setup.sh | 23 ++++++++++++-
t/t2300-cd-to-toplevel.sh | 37 +++++++++++++++++++++
t/t5521-pull-symlink.sh | 78 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 136 insertions(+), 2 deletions(-)
create mode 100755 t/t2300-cd-to-toplevel.sh
create mode 100755 t/t5521-pull-symlink.sh
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbdf209..f07d96b 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -85,8 +85,27 @@ cd_to_toplevel () {
cdup=$(git rev-parse --show-cdup)
if test ! -z "$cdup"
then
- cd "$cdup" || {
- echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
+ case "$cdup" in
+ /*)
+ # Not quite the same as if we did "cd -P '$cdup'" when
+ # $cdup contains ".." after symlink path components.
+ # Don't fix that case at least until Git switches to
+ # "cd -P" across the board.
+ phys="$cdup"
+ ;;
+ ..|../*|*/..|*/../*)
+ # Interpret $cdup relative to the physical, not logical, cwd.
+ # Probably /bin/pwd is more portable than passing -P to cd or pwd.
+ phys="$(/bin/pwd)/$cdup"
+ ;;
+ *)
+ # There's no "..", so no need to make things absolute.
+ phys="$cdup"
+ ;;
+ esac
+
+ cd "$phys" || {
+ echo >&2 "Cannot chdir to $phys, the toplevel of the working tree"
exit 1
}
fi
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
new file mode 100755
index 0000000..beddb4e
--- /dev/null
+++ b/t/t2300-cd-to-toplevel.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='cd_to_toplevel'
+
+. ./test-lib.sh
+
+test_cd_to_toplevel () {
+ test_expect_success "$2" '
+ (
+ cd '"'$1'"' &&
+ . git-sh-setup &&
+ cd_to_toplevel &&
+ [ "$(/bin/pwd)" = "$TOPLEVEL" ]
+ )
+ '
+}
+
+TOPLEVEL="$(/bin/pwd)/repo"
+mkdir -p repo/sub/dir
+mv .git repo/
+SUBDIRECTORY_OK=1
+
+test_cd_to_toplevel repo 'at physical root'
+
+test_cd_to_toplevel repo/sub/dir 'at physical subdir'
+
+ln -s repo symrepo
+test_cd_to_toplevel symrepo 'at symbolic root'
+
+ln -s repo/sub/dir subdir-link
+test_cd_to_toplevel subdir-link 'at symbolic subdir'
+
+cd repo
+ln -s sub/dir internal-link
+test_cd_to_toplevel internal-link 'at internal symbolic subdir'
+
+test_done
diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh
new file mode 100755
index 0000000..5672b51
--- /dev/null
+++ b/t/t5521-pull-symlink.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+
+test_description='pulling from symlinked subdir'
+
+. ./test-lib.sh
+
+# The scenario we are building:
+#
+# trash\ directory/
+# clone-repo/
+# subdir/
+# bar
+# subdir-link -> clone-repo/subdir/
+#
+# The working directory is subdir-link.
+
+mkdir subdir
+echo file >subdir/file
+git add subdir/file
+git commit -q -m file
+git clone -q . clone-repo
+ln -s clone-repo/subdir/ subdir-link
+
+
+# Demonstrate that things work if we just avoid the symlink
+#
+test_expect_success 'pulling from real subdir' '
+ (
+ echo real >subdir/file &&
+ git commit -m real subdir/file &&
+ cd clone-repo/subdir/ &&
+ git pull &&
+ test real = $(cat file)
+ )
+'
+
+# From subdir-link, pulling should work as it does from
+# clone-repo/subdir/.
+#
+# Instead, the error pull gave was:
+#
+# fatal: 'origin': unable to chdir or not a git archive
+# fatal: The remote end hung up unexpectedly
+#
+# because git would find the .git/config for the "trash directory"
+# repo, not for the clone-repo repo. The "trash directory" repo
+# had no entry for origin. Git found the wrong .git because
+# git rev-parse --show-cdup printed a path relative to
+# clone-repo/subdir/, not subdir-link/. Git rev-parse --show-cdup
+# used the correct .git, but when the git pull shell script did
+# "cd `git rev-parse --show-cdup`", it ended up in the wrong
+# directory. A POSIX shell's "cd" works a little differently
+# than chdir() in C; "cd -P" is much closer to chdir().
+#
+test_expect_success 'pulling from symlinked subdir' '
+ (
+ echo link >subdir/file &&
+ git commit -m link subdir/file &&
+ cd subdir-link/ &&
+ git pull &&
+ test link = $(cat file)
+ )
+'
+
+# Prove that the remote end really is a repo, and other commands
+# work fine in this context. It's just that "git pull" breaks.
+#
+test_expect_success 'pushing from symlinked subdir' '
+ (
+ cd subdir-link/ &&
+ echo push >file &&
+ git commit -m push ./file &&
+ git push
+ ) &&
+ test push = $(git show HEAD:subdir/file)
+'
+
+test_done
--
1.6.0.3
^ permalink raw reply related
* [PATCH] objects to be pruned immediately don't have to be loosened
From: Nicolas Pitre @ 2008-12-15 17:38 UTC (permalink / raw)
To: Theodore Tso; +Cc: Björn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3331 bytes --]
When there is no grace period before pruning unreferenced objects, it is
pointless to push those objects in their loose form just to delete them
right away.
Also be more explicit about the possibility of using "now" in the
gc.pruneexpire config variable (needed for the above behavior to
happen).
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Mon, 15 Dec 2008, 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.
>
> 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".
What about this?
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 21ea165..ca45e71 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -702,7 +702,9 @@ gc.packrefs::
gc.pruneexpire::
When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
- Override the grace period with this config variable.
+ Override the grace period with this config variable. The value
+ "now" may be used to disable this grace period and always prune
+ unreachable objects immediately.
gc.reflogexpire::
'git-reflog expire' removes reflog entries older than
diff --git a/builtin-gc.c b/builtin-gc.c
index 781df60..f8eae4a 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -188,7 +188,9 @@ static int need_to_gc(void)
* there is no need.
*/
if (too_many_packs())
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
else if (!too_many_loose_objects())
return 0;
@@ -243,7 +245,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
"run \"git gc\" manually. See "
"\"git help gc\" for more information.\n");
} else
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))
return error(FAILED_RUN, argv_pack_refs[0]);
^ permalink raw reply related
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