* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Shawn Pearce @ 2006-09-02 17:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vodty1swz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I think the better thing to do here is to not repack objects which
> > are already contained in very large packs. Just leave them be.
>
> I've been thinking about updating rev-list so that repack
> can be used to organize packs into zero or more "archive packs"
> and one "active pack".
>
> repack without -a essentially boils down to:
>
> rev-list --objects --all --unpacked |
> pack-objects $new_pack
>
> which picks up all live loose objects and create a new pack.
>
> If rev-list had an extention that lets you say
>
> rev-list --objects --all --unpacked=$active_pack |
> pack-objects $new_pack
Hmm. Seems very reasonable actually. :-)
How do we pick the "active pack" in git-repack.sh?
How about "--include-pack=$active_pack" instead of
"--unpacked=$active_pack"? The latter just reads really funny to me.
--
Shawn.
--
VGER BF report: S 0.9993
^ permalink raw reply
* Re: Mozilla .git tree
From: Shawn Pearce @ 2006-09-02 17:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveo6zfx0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Using a 28 byte index entry instead of a 32 byte index entry means
> > the Mozilla historical pack index will only be 52.4 MiB rather than
> > the slightly larger 59.9 MiB.
>
> Yup, that was one consideration. One small worry is we will be
> placing u64 at 4-byte alignment by using 28-byte entries but I
> think that is Ok.
On some systems (SPARC?) that's definately an issue. Other systems
(x86) obviously don't have that problem.
If you code the decode function as treating that 64 bit value as
two 32 bit values in network byte order and combine them together
after ntohl() then this shouldn't be a problem. Though big-endian
systems which can take a u64 on a 4-byte alignment just fine would
pay a small performance penalty that they don't need to pay.
--
Shawn.
--
VGER BF report: S 0.998672
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-09-03 9:27 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550609022126j1a79c750vb3aeea01cda10bac@mail.gmail.com>
Marco Costalba wrote:
> On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> By the way, do the diff between arbitrary revisions (say, between two
>> branches/two refs) and between arbitrary versions of the same file would be
>> useful to have in gitweb?
>>
>
> A nice tool, lot of ideas to steal ;-)
>
> http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1
FishEye? I haven't took the full tour, but the tool seems somewhat
CVS centric, i.e. per file history, file description,...
But for example "breadcrumbs" idea for the file path (each segment of path
being link to given (sub)directory) is a nice one. Although if I remember
correctly the pathname (for files only) is currently hack to have somewhere
link to "head" version of current file in plain format.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: U 0.910123
^ permalink raw reply
* Re: Mozilla .git tree
From: Shawn Pearce @ 2006-09-03 3:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejuuyon7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> >> > Sure the scheme you outlined allows a 64 bit difference but
> >> > uncompressed objects already can't be larger than 2**32-1...
> >>
> >> Where do we have that limitation?
> >
> > sha1_file.c uses "unsigned long" a lot to deal with size of an
> > object, deflated. iirc unsigned long is only 32 bits even in many
> > 64 bit architectures. Or am I wrong?
>
> Of course 4G .idx (\377tOc) patch would update them to u64.
> What is the problem?
None then. I must have missed that.
Besides this issue is moot as you are removing it from the .idx.
Sorry for the noise. :-)
--
Shawn.
--
VGER BF report: S 0.999999
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Marco Costalba @ 2006-09-03 11:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ede765$b9u$2@sea.gmane.org>
On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >>
> >> By the way, do the diff between arbitrary revisions (say, between two
> >> branches/two refs) and between arbitrary versions of the same file would be
> >> useful to have in gitweb?
> >>
> >
> > A nice tool, lot of ideas to steal ;-)
> >
> > http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1
>
> FishEye? I haven't took the full tour, but the tool seems somewhat
> CVS centric, i.e. per file history, file description,...
>
> But for example "breadcrumbs" idea for the file path (each segment of path
> being link to given (sub)directory) is a nice one. Although if I remember
> correctly the pathname (for files only) is currently hack to have somewhere
> link to "head" version of current file in plain format.
> --
Also the UI for diff between arbitrary revisions could be interesting.
--
VGER BF report: U 0.791104
^ permalink raw reply
* Dropping Git.pm (at least Git.xs)?
From: Junio C Hamano @ 2006-09-03 11:34 UTC (permalink / raw)
To: pasky; +Cc: git
I was reviewing the "next" tonight and ended up reverting a few
patches that came from Git.pm topic that touched fairly core
part of the system.
Parts of environment.c and sha1_file.c are fairly old code that
has "we start in one repository, do our work and exit" mentality
pretty much ingrained. The reverted one was meant to minimally
work it around to allow switching between repositories.
The intention is good, but I felt keeping such hack without
thinking about what the semantics of switching repositories
should mean would harm eventual libification.
In the ideal world in admittably not so immediate future, I
would rather have a honestly libified git that encapsulates
git_dir, git_object_dir, git_index_file, etc. into a structure
("struct git_repository" perhaps) and passes a pointer to it to
functions like has_sha1_file(), get_sha1() and friends.
Probably to keep the changes manageable, we would start from one
instance of "struct git" that is the default, and existing
interfaces would become thin wrappers that pass the pointer to
that default one to the updated functions that are repo aware.
One great promise Git.pm topic showed, at least from my point of
view, was consolidation of core-wrapper functions various script
had. In the hindsight, I should have pushed for that
consolidation a lot stronger while rejecting Git.xs (I
underestimated that Git.xs would introduce such portability
issues). After all, existing Perl scripts did things without
having to use any .xs.
Since there is no serious user of Git.pm exists, especially
git-mv and git-fmt-merge-msg are now not in Perl anymore, I do
not think we are in great hurry to have Git.xs yet. I would
expect that the most major customer of Git.xs to be gitweb
eventually, but to support it in persistent environment (read:
mod_perl) we would need to have multi-repo infrastructure in
place. And I do not think we want a hacky one.
What bothered me most was that has_sha1_file() issue; I think it
is Ok for read_sha1_file() to return object contents from a
repository that is not the current repository even after the
eventual libification that each invocation of a function is told
in which repository to operate. After all, we depend on object
name being a reliable handle to its contents, and if the caller
has a name of the object that is not in the current repository
and wants to get its contents, and if the system happens to know
the answer (even when it shouldn't have known -- the reason it
knows is only because the process happens to have switched to
that other repository in the past), not failing the request and
give the contents is acceptable. It could even be considered a
feature and would be handy when writing cross repository (albeit
limited to local repositories) diff/merge tools, for example.
But has_sha1_file() is different. It is used to check if it
exists in the current repository when the caller knows the
object name (and presumably its contents), so that the caller
can base its decision on what to do next based on the result.
It really should care what repository it is operating in.
The approach taken by the patch I reverted were minimal patch to
allow switching, which was OK for get_object() purposes, and did
not even attempt to define what the semantics of has_sha1_file()
and read_sha1_file() should be.
I think being able to switch repositories in a single process is
important needs to be designed, not hacked in. I am sure there
certainly are other things that needs more thought (e.g. how
should grafts work across repositories), but I think nobody
knows what they are because we haven't thought about the issues
yet.
A few sentences to conclude this message.
- I think the clean-up promise of Git.pm is great (e.g.
safe_qx should be part of it not in git-svn alone).
- I think Git.xs was a bit premature and raised the hurdle of
cleaning up and consolidating various core-wrappers from
existing Perl scripts into Git.pm and have them use Git.pm.
It would be nice if we can drop this part for now, and do a
bit more Perl-level clean-up first.
- I think "repository" abstraction, if we are going to have
one, should be designed from the core level if we are going
to have it accessible from Git.xs. Unfortunately I am not
ready to invest great time and effort for core level
libification at this moment.
--
VGER BF report: U 0.516772
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Marco Costalba @ 2006-09-03 12:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <44fac1ee.308dbbaf.574b.08a5@mx.gmail.com>
>
> By the way, do you known any common Perl modules for generating PNG
> (graphs)?
>
No, I don't. sorry. Anyway, from my experience with qgit I can say
that one thing is to produce a revision graph, another thing is to
produce a _fast_ and (perhaps more important) no memory hogger
revision graph.
Both qgit and gitk implement heavy optimizations and a lot of tricks
to make that happen. IMHO this is almost mandatory with long and
complex histories like Linux tree. I'm not sure a generic graph
builder is up to the task.
More, gitweb is designed to be used by many people at the same time,
while qgit and gitk are for personal use only, and this adds burden
from the performance/resources point of view.
Marco
--
VGER BF report: U 0.807973
^ permalink raw reply
* Re: Dropping Git.pm (at least Git.xs)?
From: Dennis Stosberg @ 2006-09-03 15:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: pasky, git
In-Reply-To: <7vodtxuqt4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> In the ideal world in admittably not so immediate future, I
> would rather have a honestly libified git that encapsulates
[...]
> - I think the clean-up promise of Git.pm is great (e.g.
> safe_qx should be part of it not in git-svn alone).
>
> - I think Git.xs was a bit premature and raised the hurdle of
> cleaning up and consolidating various core-wrappers from
> existing Perl scripts into Git.pm and have them use Git.pm.
> It would be nice if we can drop this part for now, and do a
> bit more Perl-level clean-up first.
Having perl bindings to git internals and sometime in the future to a
libified git is a great thing. It will allow people to do interesting
things, quickly trying concepts without having to write any C code.
And I expect that gitweb can be sped up remarkably by using Git.pm (no
forking, parsing of command output often not necessary, easy caching of
frequently cached data across calls, etc)
So I think there are valid uses for Git.pm.
On the other hand there are the problems Junio mentioned. And the
portability issues wit Git.pm:
- Git has to be built with the same compiler perl was built with,
which is a problem on many Solaris machines.
- We need to generate position-independent code on some archs, but
have no proper way to determine on which systems it is really
necessary.
- It completely breaks cross-compiling.
And the gain is negligible at the moment: There are only two users
left: git-annotate and git-send-email. The first one has already
been superseded by git-blame and the second one can easily be
converted back.
I think Git.pm would be a good candidate for the contrib section if
there is someone who keeps it up-to-date through the coming changes.
The only thing that would have to be kept in the main Makefile is the
option to generate position-independent code, defaulting to off.
Regards,
Dennis
--
VGER BF report: U 0.957499
^ permalink raw reply
* Re: [PATCH 2/2] Look for a commit's parents in the standard way.
From: Yann Dirson @ 2006-09-03 19:36 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0608200343t517ec29dw2b6b49d9d69dbad5@mail.gmail.com>
On Sun, Aug 20, 2006 at 11:43:22AM +0100, Catalin Marinas wrote:
> On 14/08/06, Yann Dirson <ydirson@altern.org> wrote:
> >This has the direct effect of taking info/grafts into account, since
> >ignoring it only causes confusion.
>
> I don't know the difference but is there any between parsing the
> commit file and using git-rev-list --parents?
Yes, git-rev-list at least takes info/grafts into account.
> >+ self.__parents = split(_output_lines('git-rev-list --parents
> >--max-count=1 %s' % id_hash)[0])[1:]
>
> Instead of using the split() method, you could call
> _output_lines('git-rev-list --parents --max-count=1 %s' %
> id_hash)[0].split()[1:]. Maybe that's why they might deprecate the
> global split method.
Ah, OK.
Best regards,
--
Yann.
--
VGER BF report: U 0.500235
^ permalink raw reply
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Junio C Hamano @ 2006-09-03 21:00 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, git
In-Reply-To: <20060902175408.GD27826@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> If rev-list had an extention that lets you say
>>
>> rev-list --objects --all --unpacked=$active_pack |
>> pack-objects $new_pack
>
> Hmm. Seems very reasonable actually. :-)
>
> How do we pick the "active pack" in git-repack.sh?
I was hoping that will be a Porcelain policy issue I do not have
to decide ;-).
You could introduce repack.active in .git/config that points at
the latest active, make git-repack to notice and update when it
updates it.
We could also just use .git/objects/pack/pack-active.{pack,idx}
files. This needs some surgery to get rid of packed_git.sha1[],
sha1_pack_name() and friends and have them only require .pack
and .idx are linked by their basename only as was discussed in a
separate thread to make it dumb-transport friendly.
--
VGER BF report: U 0.658122
^ permalink raw reply
* vger bogofilter help.
From: Junio C Hamano @ 2006-09-03 21:11 UTC (permalink / raw)
To: git
I got a few complaints/wonders/request-for-helps from the people
on this list who got their messages bounced by bogofilter at
vger. I got an earlier message of mine bounced too ;-). I am
not involved in running vger mailing list in any way (I am not
even a subscriber). Please send the bounce message you got in
full to <postmaster@vger.kernel.org>.
The announcement was sent only to the kernel list so people who
do not follow it but still on one of the mailing lists at vger
would not know what to do, which was not very nice, so here is a
reproduction of the announce.
From: Matti Aarnio <matti.aarnio@zmailer.org>
Subject: Bogofilter at VGER..
Date: Fri, 1 Sep 2006 15:51:53 +0300
Message-ID: <20060901125153.GC16047@mea-ext.zmailer.org>
To: linux-kernel@vger.kernel.org
Hello,
We are considering of taking Bogofilter into use at VGER.
So far we are using it in TEST mode - to teach it about
SPAM and HAM.
I have added some new "cute" email addresses to VGER to
receive any spams that spammers wish to send to us..
See the bottom link at vger's web front page.
You can feed SPAM to bogofilter-spam@vger.kernel.org,
but do not feed there any HAM. Not that it would
really affect statistics in any effective way.
IF we take it into use, it will start rejecting messages
at SMTP input phase, so if it rejects legitimate message,
you should get a bounce from your email provider's system.
(Or from zeus.kernel.org, which is vger's backup MX.)
In such case, send the bounce with some explanations to
<postmaster@vger.kernel.org> -- emails to that address
are explicitely excluded from all filtering!
Regards,
Matti Aarnio -- one of <postmaster@vger.kernel.org>
--
VGER BF report: U 0.500024
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-09-03 12:38 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550609030518o5e78bb05w4df4235a4931c2dd@mail.gmail.com>
Marco Costalba wrote:
>>
>> By the way, do you known any common Perl modules for generating PNG
>> (graphs)?
>>
>
> No, I don't. sorry. Anyway, from my experience with qgit I can say
> that one thing is to produce a revision graph, another thing is to
> produce a _fast_ and (perhaps more important) no memory hogger
> revision graph.
>
> Both qgit and gitk implement heavy optimizations and a lot of tricks
> to make that happen. IMHO this is almost mandatory with long and
> complex histories like Linux tree. I'm not sure a generic graph
> builder is up to the task.
>
> More, gitweb is designed to be used by many people at the same time,
> while qgit and gitk are for personal use only, and this adds burden
> from the performance/resources point of view.
Well, I guess even if/when gitweb acquires history graph support, it would
be paged like history/shortlog is, i.e. at most 100 commits to graph.
P.S. To those wondering why thread got broken, and why the parent post is
lost: vger bogofilter.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: S 0.992982
^ permalink raw reply
* Re: Mozilla version control requirements and git
From: Jon Smirl @ 2006-09-03 13:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ede6in$b9u$1@sea.gmane.org>
On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Jon Smirl wrote:
>
> >> Oh, and "partial tree pulls for localisers". Perhaps git-cvsserver can
> >> help there? Localisers can just use TortoiseCVS and get a checkout of
> >> the language pack subdir.
> >
> > Partial repo pulls and an issue to. The mozilla repo has much more
> > than a browser in it, it also has a large mail/news program. A partial
> > repo pull may not be what is needed for git, instead git needs a
> > partial repo checkout.
>
> Or better support for subprojects.
>
> I think you can fake subproject support using separate repositories
> for subprojects, in the directory matching the one in the whole project,
> and the project repository, where we pull/push subprojects into.
You can't really fake it. Many of the projects in Mozilla are
dependent on each other. If you break them up into separate
repositories you lose the ability to do a cross project commit. This
is common when you are changing an interface between the subprojects.
Would it make sense for git to treat a tree of projects like you
describe as a single entity? So a commit would transparently commit to
all of the subprojects. Maybe the commit entry's sha1 could be set up
so that it would be identical in all subprojects. That would let you
string them back together.
> --
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
>
>
>
> --
> VGER BF report: U 0.877495
> -
> 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
>
--
Jon Smirl
jonsmirl@gmail.com
--
VGER BF report: S 0.995201
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-09-03 11:24 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550609030410h11469715m88e0b5fba09f2440@mail.gmail.com>
Marco Costalba wrote:
> On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Marco Costalba wrote:
>>
>>> On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>
>>>> By the way, do the diff between arbitrary revisions (say, between two
>>>> branches/two refs) and between arbitrary versions of the same file
>>>> would be useful to have in gitweb?
>>>>
>>>
>>> A nice tool, lot of ideas to steal ;-)
>>>
>>>http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1
>>
>> FishEye? I haven't took the full tour, but the tool seems somewhat
>> CVS centric, i.e. per file history, file description,...
>>
>> But for example "breadcrumbs" idea for the file path (each segment
>> of path being link to given (sub)directory) is a nice one. Although
>> if I remember correctly the pathname (for files only) is currently
>> hack to have somewhere link to "head" version of current file in
>> plain format.
>
> Also the UI for diff between arbitrary revisions could be interesting.
There is problem with git encouraging multiple branches and nonlinear
history. While it would be fairly easy either to add Wiki-like (e.g.
http://git.or.cz/gitwiki/ or http://en.wikipedia.org) radio-boxes to mark
revisions to compare, or add pull down menu to select revision (useless
with longer history) of a given file (we have diff-to-current in file
history, by the way), the true power of selecting revisions to compare
would be when we would have graphical history visualizer built in, similar
to gitk and qgit.
By the way, do you known any common Perl modules for generating PNG
(graphs)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: S 0.995678
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-09-03 11:52 UTC (permalink / raw)
To: git, Marco Costalba
Marco Costalba wrote:
> On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Marco Costalba wrote:
>>
>>> On 9/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>
>>>> By the way, do the diff between arbitrary revisions (say, between two
>>>> branches/two refs) and between arbitrary versions of the same file
>>>> would be useful to have in gitweb?
>>>>
>>>
>>> A nice tool, lot of ideas to steal ;-)
>>>
>>>http://www.cenqua.com/fisheye/demo/viewrep/ant/src/main/org/apache/tools/ant/?FETOUR=A1
>>
>> FishEye? I haven't took the full tour, but the tool seems somewhat
>> CVS centric, i.e. per file history, file description,...
>>
>> But for example "breadcrumbs" idea for the file path (each segment
>> of path being link to given (sub)directory) is a nice one. Although
>> if I remember correctly the pathname (for files only) is currently
>> hack to have somewhere link to "head" version of current file in
>> plain format.
>
> Also the UI for diff between arbitrary revisions could be interesting.
There is problem with git encouraging multiple branches and nonlinear
history. While it would be fairly easy either to add Wiki-like (e.g.
http://git.or.cz/gitwiki/ or http://en.wikipedia.org) radio-boxes to mark
revisions to compare, or add pull down menu to select revision (useless
with longer history) of a given file (we have diff-to-current in file
history, by the way), the true power of selecting revisions to compare
would be when we would have graphical history visualizer built in, similar
to gitk and qgit.
By the way, do you known any common Perl modules for generating PNG
(graphs)?
P.S. This message seems to hit VGER BOGOfilter... ehhh...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: S 0.999997
^ permalink raw reply
* Re: Mozilla version control requirements and git
From: Jakub Narebski @ 2006-09-03 15:42 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910609030646k6c722068m30f0e05fccc9c3c5@mail.gmail.com>
On 03-09-2006 15:46, Jon Smirl wrote:
> On 9/3/06, Jakub Narebski <jnareb@gmail.com> wrote:
> > Jon Smirl wrote:
> >
> > >> Oh, and "partial tree pulls for localisers". Perhaps git-cvsserver can
> > >> help there? Localisers can just use TortoiseCVS and get a checkout of
> > >> the language pack subdir.
> > >
> > > Partial repo pulls and an issue to. The mozilla repo has much more
> > > than a browser in it, it also has a large mail/news program. A partial
> > > repo pull may not be what is needed for git, instead git needs a
> > > partial repo checkout.
> >
> > Or better support for subprojects.
> >
> > I think you can fake subproject support using separate repositories
> > for subprojects, in the directory matching the one in the whole project,
> > and the project repository, where we pull/push subprojects into.
>
> You can't really fake it. Many of the projects in Mozilla are
> dependent on each other. If you break them up into separate
> repositories you lose the ability to do a cross project commit. This
> is common when you are changing an interface between the subprojects.
>
> Would it make sense for git to treat a tree of projects like you
> describe as a single entity? So a commit would transparently commit to
> all of the subprojects. Maybe the commit entry's sha1 could be set up
> so that it would be identical in all subprojects. That would let you
> string them back together.
Scratch that. You can fake subproject support using something similar
to the way Junio works with TODO branch. Namely, separate repositories
for subprojects, each as if it would start from it's own directory
(although you can manage without that, it only would be slightly harder
to set it up), and main repository working directory composed from
subproject repositories checked out to correct place. Add to this
ingnoring object database (i.e. .git repositories), and you have whole
repository... where you can do whole repository commits to.
E.g. the following directory structure
main-project/
main-project/.git
main-project/subproject/
main-project/subproject/.git
main-project/subproject/...subproject files...
where second .git is in .gitignore or info/excludes, but the subrpoject/
directory itself isn't.
If this is not enough, check out ideas in Subpro.txt in the 'todo' branch
in git repository. It adds additional 'bind' header... the implementation
(search for 'gitlink') were if I remember correctly never fully implemented
and is not in git, although parts of it like git-read-tree and
git-write-tree --prefix option made it.
http://www.kernel.org/git/?p=git/git.git;a=blob;f=Subpro.txt;hb=todo
As commit id depends on the contents, including _parents_ and _tree_,
it is I think impossible to set commit entry sha1 to be identical.
P.S. I just hope that it would pass VGER filter. I don't have much luck
with it lately...
--
Jakub Narebski
Poland
--
VGER BF report: S 0.994192
^ permalink raw reply
* Re: Mozilla version control requirements and git
From: Martin Langhoff @ 2006-09-03 21:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jakub Narebski, git
In-Reply-To: <9e4733910609030646k6c722068m30f0e05fccc9c3c5@mail.gmail.com>
On 9/4/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> You can't really fake it. Many of the projects in Mozilla are
> dependent on each other. If you break them up into separate
> repositories you lose the ability to do a cross project commit. This
> is common when you are changing an interface between the subprojects.
In many projects this is handled by having tags and generally
versioning modules and interfaces. Being independent gives the
subprojects/modules a lot more freedom to work/branch on wild
tangents, and the versioned interfaces mean that -- with the
contraints of the versioned interfaces -- you can mix and match
branches/releases of the different subprojects.
In short, I'd definitely break those up :-)
cheers,
martin
--
VGER BF report: U 0.513231
^ permalink raw reply
* Re: vger bogofilter help.
From: Jakub Narebski @ 2006-09-03 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmdgu036.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I got a few complaints/wonders/request-for-helps from the people
> on this list who got their messages bounced by bogofilter at
> vger. I got an earlier message of mine bounced too ;-). I am
> not involved in running vger mailing list in any way (I am not
> even a subscriber). Please send the bounce message you got in
> full to <postmaster@vger.kernel.org>.
It seems that at least some of the bounced messages were put into
freeze. The three messages I send which bounced (and one resend)
made it into list.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: U 0.941894
^ permalink raw reply
* [PATCH] gitweb: Change the name of diff to parent link in "commit" view to "diff
From: Jakub Narebski @ 2006-09-03 21:43 UTC (permalink / raw)
To: git
Change the name of diff to parent (current commit to one of parents)
link in "commit" view (git_commit subroutine) from "commitdiff" to
"diff". Let's leave "commitdiff" for equivalent of git-show, or
git-diff-tree with one revision, i.e. diff for a given commit to its
parent (parents).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
One of the cases when commit message is larger than diff itself ;-)
Against 'master'.
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 57ffa25..2b40aa1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2781,7 +2781,7 @@ sub git_commit {
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"commit", hash=>$par)}, "commit") .
" | " .
- $cgi->a({-href => href(action=>"commitdiff", hash=>$hash, hash_parent=>$par)}, "commitdiff") .
+ $cgi->a({-href => href(action=>"commitdiff", hash=>$hash, hash_parent=>$par)}, "diff") .
"</td>" .
"</tr>\n";
}
--
1.4.1.1
--
VGER BF report: U 0.508278
^ permalink raw reply related
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Junio C Hamano @ 2006-09-03 21:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609021138500.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 1 Sep 2006, Junio C Hamano wrote:
>>
>> But "git repack -a -d", which you now consider almost being
>> free, in the recent kernel repository counts 300k objects, and
>> reuses 298k objects or so. That means we expand and recompress
>> that many objects, totalling 120MB.
>
> Sure. Do we have data for how expensive that is (ie did you apply the
> patch and time it)?
Quite bad. For the kernel archive of today (I usually am nearly
fully packed):
$ /usr/bin/time ~/git-master/bin/git-pack-objects p1 </var/tmp/1
Generating pack...
Done counting 301361 objects.
Deltifying 301361 objects.
100% (301361/301361) done
Writing 301361 objects.
100% (301361/301361) done
a13dc6646622537d29af92b4cfc6d49b82e77e49
Total 301361, written 301361 (delta 238935), reused 300995 (delta 238663)
3.58user 0.84system 0:04.44elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+62727minor)pagefaults 0swaps
$ /usr/bin/time ../git.junio/git-pack-objects p2 </var/tmp/1
Generating pack...
Done counting 301361 objects.
Deltifying 301361 objects.
100% (301361/301361) done
Writing 301361 objects.
100% (301361/301361) done
a13dc6646622537d29af92b4cfc6d49b82e77e49
Total 301361, written 301361 (delta 238935), reused 300995 (delta 238663)
57.84user 3.39system 1:01.36elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1022768minor)pagefaults 0swaps
By the way, the one in "next" has a thinko I just noticed.
-- >8 --
[PATCH] pack-objects: fix thinko in revalidate code
When revalidating an entry from an existing pack entry->size and
entry->type are not necessarily the size of the final object
when the entry is deltified, but for base objects they must
match.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-pack-objects.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 11cc3c8..5e42387 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -247,12 +247,13 @@ static int revalidate_one(struct object_
void *data, char *type, unsigned long size)
{
int err;
- if (!data)
- return -1;
- if (size != entry->size)
- return -1;
- err = check_sha1_signature(entry->sha1, data, size,
- type_names[entry->type]);
+ if ((!data) ||
+ ((entry->type != OBJ_DELTA) &&
+ ( (size != entry->size) ||
+ strcmp(type_names[entry->type], type))))
+ err = -1;
+ else
+ err = check_sha1_signature(entry->sha1, data, size, type);
free(data);
return err;
}
--
1.4.2.g99d7d
--
VGER BF report: U 0.528006
^ permalink raw reply related
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Linus Torvalds @ 2006-09-03 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslj8tydc.fsf@assigned-by-dhcp.cox.net>
On Sun, 3 Sep 2006, Junio C Hamano wrote:
>
> Quite bad. For the kernel archive of today (I usually am nearly
> fully packed):
Ok. Is it less painful if it just checks the zlib CRC (and that the SHA1
_exists_ for a delta - although I guess we check that indirectly by just
accepting the delta in the first place)? That combination should still be
a fairly strong check, of course.
Then we could have something like
[repack]
check=[none|weak|default|strong]
where the "none" check would be to just copy the data as-is, the "weak"
(aka "default") would check just the CRC, and the strong one would unpack
the whole object and check the SHA1..
Linus
--
VGER BF report: U 0.5
^ permalink raw reply
* [PATCH] Update GIT_TRACE documentation.
From: Christian Couder @ 2006-09-03 15:32 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git.txt | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 76b41c8..744c38d 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -634,9 +634,18 @@ other
This environment variable overrides `$PAGER`.
'GIT_TRACE'::
- If this variable is set git will print `trace:` messages on
+ If this variable is set to "1", "2" or "true" (comparison
+ is case insensitive), git will print `trace:` messages on
stderr telling about alias expansion, built-in command
execution and external command execution.
+ If this variable is set to an integer value greater than 1
+ and lower than 10 (strictly) then git will interpret this
+ value as an open file descriptor and will try to write the
+ trace messages into this file descriptor.
+ Alternatively, if this variable is set to an absolute path
+ (starting with a '/' character), git will interpret this
+ as a file path and will try to write the trace messages
+ into it.
Discussion[[Discussion]]
------------------------
--
1.4.2.g0f2c-dirty
--
VGER BF report: S 0.99915
^ permalink raw reply related
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Linus Torvalds @ 2006-09-03 22:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609031456520.27779@g5.osdl.org>
On Sun, 3 Sep 2006, Linus Torvalds wrote:
>
> Ok. Is it less painful if it just checks the zlib CRC (and that the SHA1
> _exists_ for a delta - although I guess we check that indirectly by just
> accepting the delta in the first place)? That combination should still be
> a fairly strong check, of course.
Thinking some more about it, doing the stupid "apply full delta chain and
check the final SHA1" is horribly inefficient, because if you have a repo
that packs well, you'd expect to have a lot of things with a 10-deep delta
chain.
And doing it the silly way means that you'll do each object independently,
ie for a 10-deep chain you'd unpack the base object ten times, and apply
the first delta 9 times, the second one 8 times etc etc. And each time
you'd deflate everything, since we don't keep a cache of actual object
contents.
So I'd expect that with full SHA1 checking, you'd end up doing ~45
deflates for the ten-object chain, instead of doing just 10.
So it should hopefully be _much_ cheaper to just check the zlib CRC, not
because the "apply delta" and "calculate sha1" are necessarily all that
expensive, but because the unoptimized chain-unpacking is doing so much
unnecessary work.
Linus
--
VGER BF report: U 0.5
^ permalink raw reply
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Junio C Hamano @ 2006-09-03 22:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609031456520.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 3 Sep 2006, Junio C Hamano wrote:
>>
>> Quite bad. For the kernel archive of today (I usually am nearly
>> fully packed):
>
> Ok. Is it less painful if it just checks the zlib CRC...
I haven't checked myself but somebody said that zlib CRC is of
preimage so we would need to incur inflate cost anyway if that
is the case. But I think it may be a reasonable comproise to
assume that an existing delta that inflates properly would apply
to its base object, and if we can assume that we do not have to
check the inflated xdelta data. Oops, not really, there is no
check other than the pack overall SHA-1 checksum that protects
the 20-byte base object name recorded in the pack.
> ... and that the SHA1
> _exists_ for a delta - although I guess we check that indirectly by just
> accepting the delta in the first place)? That combination should still be
> a fairly strong check, of course.
Another thing the current check is _not_ doing is for this
pathological case:
- .idx table says the pack entry is N bytes
- unpack_entry_gently() used in the revalidate code uses the
usual codepath that says "here is the start of the pack
entry; inflate using as much data as you need"; .idx is
somehow wrong and it needed N+M bytes where 0 < M.
- we copy out N bytes because we belive .idx.
--
VGER BF report: U 0.626721
^ permalink raw reply
* Bogofilter is my emails
From: Shawn Pearce @ 2006-09-03 4:02 UTC (permalink / raw)
To: git
Bogofilter ate two messages today that I tried to send to this
mailing list. At least I got back bounce messages from it.
I'm not quite sure how to fix either message to get them to the list.
Neither email was a patch so I'm not going to try resending them
but I'm certainly a little curious as to how my email writing style
twice tripped bogofilter's spam switch.
--
Shawn.
--
VGER BF report: S 1
^ 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