* 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 version control requirements and git
From: Jakub Narebski @ 2006-09-03 9:17 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910609022029q9cb9ba9m87cbc37e8d6f4ad7@mail.gmail.com>
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.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: U 0.877495
^ permalink raw reply
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Junio C Hamano @ 2006-09-03 0:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609021720500.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I have to say, that adding another pack-objects-specific flag to rev-list
> doesn't necessarily strike me as very nice.
>
> It might be much better to just teach "git pack-objects" to walk the
> object list by hand. The whole "git-rev-list | git-pack-objects" approach
> made more sense back when git-rev-list was the _only_ think listing
> objects, but now that we've librarized the whole object listing thing,
> maybe it's time to avoid the pipeline and just do it inside the packer
> logic.
>...
> Hmm? Comments?
Yes it all makes perfect sense, though I am a bit too tired to
assess how much work it would involve right now.
--
VGER BF report: S 0.993177
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Marco Costalba @ 2006-09-03 4:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edcm1v$24k$1@sea.gmane.org>
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
--
VGER BF report: U 0.510515
^ permalink raw reply
* Re: Mozilla version control requirements and git
From: Jon Smirl @ 2006-09-03 3:29 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90609021819v6d427f0eh69bc13b30ef6b692@mail.gmail.com>
On 9/2/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 9/3/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > The Mozilla people have a web page describing what they are looking
> > for in a new version control system. How does git stack up?
>
> Hi Jon,
>
> you've been playing with GIT quite a bit by now, so I guess you know
> the answer ;-) Is there anything in particular you are wondering
> about?
Shallow clones are a big problem. We have Mozilla down to 450MB is
git, but that is still gigantic for anyone doing an initial check out,
especially if they don't have good broadband. It is over 10x the data
that CVS brings down. Even without doing shallow clones git still
needs to be modified to restart an interrupted pack transfer.
>
> The one item that sticks out for me as not there is ACLs, but access
> controls can be implemented in hooks for direct pushes. Maintain an
> .htaccess-like file and have a perl script to check it on pushes to
> the repo.
I don't see ACLs as that big an issue. If you convert to model where
everyone has their own repo and you just push changesets at each
other, ACLs are much less important. You need ACLs when 2,000 people
have commit privs.
>
> 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.
--
Jon Smirl
jonsmirl@gmail.com
--
VGER BF report: U 0.827771
^ permalink raw reply
* Re: Mozilla version control requirements and git
From: Martin Langhoff @ 2006-09-03 1:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910609020731k25ce3a0aw7a84542f8cd516f6@mail.gmail.com>
On 9/3/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> The Mozilla people have a web page describing what they are looking
> for in a new version control system. How does git stack up?
Hi Jon,
you've been playing with GIT quite a bit by now, so I guess you know
the answer ;-) Is there anything in particular you are wondering
about?
The one item that sticks out for me as not there is ACLs, but access
controls can be implemented in hooks for direct pushes. Maintain an
.htaccess-like file and have a perl script to check it on pushes to
the repo.
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.
cheers,
martin
--
VGER BF report: U 0.544429
^ permalink raw reply
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Linus Torvalds @ 2006-09-03 0:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vodty1swz.fsf@assigned-by-dhcp.cox.net>
On Sat, 2 Sep 2006, Junio C Hamano wrote:
>
> 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
I have to say, that adding another pack-objects-specific flag to rev-list
doesn't necessarily strike me as very nice.
It might be much better to just teach "git pack-objects" to walk the
object list by hand. The whole "git-rev-list | git-pack-objects" approach
made more sense back when git-rev-list was the _only_ think listing
objects, but now that we've librarized the whole object listing thing,
maybe it's time to avoid the pipeline and just do it inside the packer
logic.
Of course, having git-pack-objects be able to take input from stdin is
still useful, but I'd rather start moving the obviously packing-specific
flags out of git-rev-list, and into git-pack-objects instead.
[ That would also potentially make packing more efficient - right now the
"phase 1" of packing is literally to just figure out the type and the
size of the object, in order to sort the object list.
So when you do a big repack, first "git-rev-list" ends up doing all this
work, and then "git-pack-object" ends up _redoing_ some of it.
Especially for tree objects (which are one of the most common kinds), we
already opened the object once when we traversed it, so opening it again
just to look at its size is kind of sad.. ]
We also used to have a bug with repacking, where a git-rev-list that died
with a failure would silently cause a "good" repack to happen because it
had fed git-pack-objects an incomplete list of objects. Junio fixed that
with a hack, but if we did all the object listing inside git-pack-objects,
we'd not need that kind of things at all..
Hmm? Comments?
Linus
--
VGER BF report: U 0.500053
^ permalink raw reply
* Re: [PATCH][RFC] Add git-archive-tree
From: Junio C Hamano @ 2006-09-02 21:27 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git, Franck Bui-Huu
In-Reply-To: <44F977C0.4060901@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Currently git-archive-tree -f tar is slower than git-tar-tree. This is
> because it is welded to the side of the existing code to minimize patch
> size, and I also suspect read_tree_recursive() to be quite a bit slower
> than builtin-tar-tree.c::traverse_tree().
Yes, I suspect "struct object" and friends are very inefficient
to use for things like this. "struct tree_desc" based traverser
is much preferred.
--
VGER BF report: U 0.772588
^ permalink raw reply
* Re: [PATCH][RFC] Add git-archive-tree
From: Junio C Hamano @ 2006-09-02 21:19 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Git Mailing List, Franck Bui-Huu
In-Reply-To: <44F982BD.1050509@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Does it make sense to change the wire protocol to simply send the
> command line options one by one?
Which wire protocol are you talking about? The one between
upload-tar and local "tar-tree --remote"? I think that one was
a tar-tree specific hack and we do not want to mimic it.
Your idea of making archiver neutral upload/download pair makes
sense. The daemon can invoke upload-archive with a single
parameter (the repository, "."), just like upload_tar() in
"pu:daemon.c" does [*1*], and upload-archive talks with the
other end to know which archiver to run with what paramter. We
would probably want to use some sort of side-band mechanism so
that we can do progress-bar as well.
*1* Unrelated side note. I find myself typing "git less" quite
often ;-)
git less pu:daemon.c
and get "no such command, dummy" response.
Yes, I know I could alias it to "-p cat-file -p". I am just
too lazy to do so.
--
VGER BF report: U 0.709954
^ permalink raw reply
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Junio C Hamano @ 2006-09-02 20:56 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:
> For me, performance has always been one of the primary goals, but being
> able to trust the end result has been even _more_ primary.
Agreed, violently ;-).
--
VGER BF report: U 0.735423
^ permalink raw reply
* Re: Mozilla .git tree
From: Junio C Hamano @ 2006-09-02 20:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060902175125.GC27826@spearce.org>
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?
--
VGER BF report: U 0.905241
^ permalink raw reply
* Re: Mozilla .git tree
From: Junio C Hamano @ 2006-09-02 20:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0609021151280.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 2 Sep 2006, Shawn Pearce wrote:
>
>> I think Junio and Nico have already agreed to change the base SHA1
>> to be an offset instead;
I am not in favor of that, at least not yet, especially I
haven't thought about the implications of that on streaming
unpacker. I do not have much objections about changing
base-delta order, though.
> Of course, if we change the pack/index-file format for other reasons, then
> we should obviously fix the 4G issue at the same time, but were there
> actually any real other reasons at this point?
Not really, from my point of view. Probably 70% of motivation
of the new \377tOc index format originally came from wanting to
have "where is the end of this object" which turned out to be
unneeded; and by making repack easier to use I think we do not
have to solve 4G issue either.
There is only one case that might need a single pack that can be
indexed with 4G offset: initial clone or repack of a huge
repository.
--
VGER BF report: U 0.788936
^ permalink raw reply
* Re: [PATCH][RFC] Add git-archive-tree
From: Franck Bui-Huu @ 2006-09-02 20:13 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <44F982BD.1050509@lsrfire.ath.cx>
2006/9/2, Rene Scharfe <rene.scharfe@lsrfire.ath.cx>:
> The two patches I sent are what I have been able to come up with so far.
> The next step would be to add archive-neutral upload and download support.
>
> Having thought a bit about it I propose to keep git-archive-tree for
> local operations, only. It can be called by the uploader just like
Well I don't see why putting the remote operations in an other file. I
was more thinking on something like this:
git-archive --format=<fmt> [--remote=<repo>] <tree-ish> [path...]
This main porcelain function would call directly functions provided by
archivers lib. We will need to define an API which git-archive will
use for local operations.
Symetrically, on the sever side we would have:
git-upload-archive --format=<fmt> <repo> [path...]
used by git-daemon. It will deal with protocol, paths and use archiver's lib.
Eventually, we would have 2 commands:
git-archive
git-upload-archive
and get ride of
git-tar-tree
git-zip-tree
git-upload-tar
git-upload-zip
> git-tar-tree is now called by git-upload-tar. As Franck suggested, the
> uploader should allow the list of archive formats it supports to be
> restricted in a config file. The range of allowed compression levels
> should also be configurable.
>
> Does it make sense to change the wire protocol to simply send the
> command line options one by one?
That would make sense if the number of options grow up. Currently the
remote protocol had been written by Junio, I just pick up that part
from git-tar-tree and put it into git-archive. But if we allow
pathspec for remote operations, then we need to send them to the
uploader.
>
> The interface could be something like this:
>
> git-download-archive <repo> <git-archive-tree options...>
> git-upload-archive <directory>
>
> Or, if the big number of git command names is a concern:
>
I think it is, IMHO. And that's why I think we could have only one
command for building localy/remotely archive whatever the format.
git-archive should be a main procelain command, and we should get rid
of git-{tar,zip}-tree commands.
--
Franck
--
VGER BF report: U 0.742177
^ permalink raw reply
* Re: [PATCH 0/3] git-daemon: plug new upload-tar command
From: Franck Bui-Huu @ 2006-09-02 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rene Scharfe, git
In-Reply-To: <7vfyfa1rvf.fsf@assigned-by-dhcp.cox.net>
2006/9/2, Junio C Hamano <junkio@cox.net>:
> "Franck Bui-Huu" <vagabon.xyz@gmail.com> writes:
>
> >> So if you beat me to it, that would be great. Or if you have a better
> >> idea, that would be also great. :-)
> >
> > Well I'll try to start something, not sure to have a lot of time
> > though. Please contact me before starting anything, I would be sad to
> > write something for /dev/null again ;)
>
> I do not necessarily think your effort were for /dev/null; for
> example, I was hoping you defend [PATCH 3/3].
>
Well, with a new git-archive-tree command, I thought it would make
sense to put the remote logic there and let the git-tar-tree be a
local command. But Rene has a different approach, please see his new
thread "Add git-archive-tree".
> While it makes sense to make "tar-tree --remote" usable outside
> a git managed repository, I think people expect the connection
> to obey core.gitproxy if the command is run inside a repository
> that has a configuration file.
>
Make sense.
--
Franck
--
VGER BF report: U 0.799618
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-09-02 19:29 UTC (permalink / raw)
To: git
In-Reply-To: <200609021817.09296.jnareb@gmail.com>
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?
--
Jakub Narębski
Poland
--
VGER BF report: U 0.5
^ permalink raw reply
* Re: Mozilla .git tree
From: Linus Torvalds @ 2006-09-02 18:56 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jon Smirl, Junio C Hamano, git
In-Reply-To: <20060902173922.GA27826@spearce.org>
On Sat, 2 Sep 2006, Shawn Pearce wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
> > If you're going to redo the pack formats another big win for the
> > Mozilla pack is to convert pack internal sha1 references into file
> > offsets.within the pack. Doing that will take around 30MB off from the
> > Mozilla pack size. sha1's are not compressible so this is a direct
> > savings.
>
> Right now Junio's working on the index to break the 4 GiB barrier.
> I think Junio and Nico have already agreed to change the base SHA1
> to be an offset instead; though this is an issue for the current
> way the base gets written out behind the delta as you need to know
> exactly how many bytes the delta is going to be so you can correctly
> compute the offset.
I think moving the delta to after the base object is fine, and solves that
problem.
However, the "--thin" pack problem is potentially worse, since the object
you delta against doesn't even _exist_, and as such you'd then end up
having two totally different formats (or perhaps we'd add a new object
type for use in thin packs: a "dummy object" that says "my type is
<so-and-so> and my SHA1 is <so-and-so>, you'd better have me already".
I'm not actually personally convinced that we need to solve the 4GB
pack-file problem right now. Does anybody have that problem yet? The
"partial mapping" issue is a much bigger one, I suspect, even if the tree
delta stuff seems to have fixed it largely (yes?) for the mozilla
fast-import pack-file.
So in many ways, I'd think that the 4GB problem is one where we are
perfectly happy to _know_ that a solution exists, rather than have to
actually solve it today.
Of course, if we change the pack/index-file format for other reasons, then
we should obviously fix the 4G issue at the same time, but were there
actually any real other reasons at this point?
Linus
--
VGER BF report: U 0.500001
^ permalink raw reply
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Linus Torvalds @ 2006-09-02 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ae3ox2.fsf@assigned-by-dhcp.cox.net>
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)?
I'd rather be really safe by default, and then if somebody knows to trust
their archive, maybe add a "--fast" flag (or even a "core.reliablepack"
config option) to disable it for people who have backups and think their
machines are infallible - or have slow CPU's..
For me, performance has always been one of the primary goals, but being
able to trust the end result has been even _more_ primary. A lot of the
design has centered around not doing things that are unsafe (eg the whole
"never ever re-write an object" thing was obviously a big part of the
design, and a lot of it is about being able to do things quickly _without_
having to do slow things like fsync).
Linus
--
VGER BF report: U 0.5
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Marco Costalba @ 2006-09-02 18:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609021817.09296.jnareb@gmail.com>
>
> * Code highlighting in blob view (from gitweb-xmms2), or to generalize
> to allow for generalized filter. The higlighter should have support
> for HTML support, it should always close elements before end of line,
> it would be better if it used CSS for styling, and it should accept
> file to highlight on standard input. gitweb-xmms2 uses Highlight
> http://www.andre-simon.de/
> but GNU Highlight (src-hilite) could be used instead
> http://www.gnu.org/software/src-highlite/
>
Current HEAD of qgit (I plan to release the new version very shortly)
uses GNU Highlight. I can say this tool is easy to use yet very
flexible and configurable and, last but not the least, the developer
is very responsive.
My two cents.
Marco
--
VGER BF report: U 0.500001
^ permalink raw reply
* Re: Mozilla .git tree
From: Shawn Pearce @ 2006-09-02 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bba1qg5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> > I think we probably should have done this when the binary headers
> > were introduced into loose objects.
>
> No. That was purely .pack format and did not affect .idx
> format. Honestly .idx is purely a local matter and not as
> important to keep stable as the .pack format.
I think you missed the point of my comment. I apologize for it
not being clear the first time.
The loose objects have format #1 (legacy text format compressed as
one big zlib stream) and now format #2 (pack object header followed
by data-only zlib stream).
In looking at this dictionary packing code that I'm working on right
now I may be introducing format #3 (dictionary based compression
rather than zlib compression).
We have no easy way to mark the version number of the loose objects.
I'm sure we can shoehorn in something though.
> > 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?
> I think your "allow zlib to eat the remainder of the current
> window and slide window when it exhausts the current window"
> logic is a very good on and makes it unnecessary to know the
> tail of each object.
I'll send patches to sha1_file.c probably later tonight. My last
round of offset changes was the start of that, this next round
should finish it. Its mostly a copy-n-paste from fast-import.c
so it should go quickly.
--
Shawn.
--
VGER BF report: U 0.960524
^ permalink raw reply
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Linus Torvalds @ 2006-09-02 17:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vwt8m1u6b.fsf@assigned-by-dhcp.cox.net>
On Sat, 2 Sep 2006, Junio C Hamano wrote:
>
> The Linus's theory goes like this:
>
> (1) A bit in an existing pack was damaged somehow. It might have
> happened on the mothership machine when it was first created,
> or after it was read and copied to the notebook via rsync.
NOTE! With the new loose object format, this will be true even of
individually packed files (if you set "core.legacyheaders" to false). So
checking the SHA1 of the pack-files is insufficient - at least for those
loose objects.
So revalidating the individual objects will catch that case too, while
revalidating the SHA1 of the old pack-files won't.
Linus
--
VGER BF report: U 0.5
^ permalink raw reply
* Re: Mozilla .git tree
From: Shawn Pearce @ 2006-09-02 17:39 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, git
In-Reply-To: <9e4733910609020720w3633aa0cq5016fb1e223fc4cb@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> If you're going to redo the pack formats another big win for the
> Mozilla pack is to convert pack internal sha1 references into file
> offsets.within the pack. Doing that will take around 30MB off from the
> Mozilla pack size. sha1's are not compressible so this is a direct
> savings.
Right now Junio's working on the index to break the 4 GiB barrier.
I think Junio and Nico have already agreed to change the base SHA1
to be an offset instead; though this is an issue for the current
way the base gets written out behind the delta as you need to know
exactly how many bytes the delta is going to be so you can correctly
compute the offset.
> This might reduce memory usage too. The index is only needed to get
> the initial object from the pack. Since index use is lighter it could
> just be open/closed when needed.
True; however when you are walking a series of commits (to produce
output for `git log` for example) every time you parse a commit you
need to go back to the .idx to relookup the ancestor commit(s).
So you don't want to open/close the .idx file on every object;
instead put the .idx file into the LRU like the .pack files are
(or into their own LRU chain) and maintain some threshold on how
many bytes worth of .idx is kept live.
> You could also introduce a zlib dictionary object into the format and
> just leave it empty for now.
No. I'm not sure I'm ready to propose that as a solution for
decreasing pack size. Now that my exams are over I've started
working on a true dictionary based compression implementation.
I want to try to get Git itself repacked under it, then try the
Mozilla pack after I get my new amd64 based system built.
If that's as big of space saver as we're hoping it would be then
the pack format would be radically different and need to change;
if it doesn't gain us anything (or is worse!) then we can go back
to the drawing board and consider other pack format changes such as
a zlib dictionary. But right now its measly 4% gain isn't very much.
--
Shawn.
--
VGER BF report: U 0.653439
^ permalink raw reply
* Re: [PATCH] Rewrite branch in C and make it a builtin.
From: Kristian Høgsberg @ 2006-09-02 17:39 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20060902010806.GA24234@spearce.org>
Shawn Pearce wrote:
> Kristian H??gsberg <krh@redhat.com> wrote:
>> A more or less straight port to C of the shell script version.
>
> [snip]
>> +static void create_reflog(struct ref_lock *lock)
>
> I'm attaching a patch to the reflog code which introduces a new
> force_log option. You can use set this after you lock the ref
> but before writing it, provided that the user supplied -l on
> the command line.
>
> This completely replaces the create_reflog function with common code.
Yeah, that should work, I'll send out a new version that uses the new flag.
> I apologize for taking so long to get around to this but I've been
> busy with other stuff lately. :-)
No problem at all, I'm working on this on and off anyway :)
Kristian
--
VGER BF report: U 0.499995
^ permalink raw reply
* [PATCH] gitweb: Add GIT favicon, assuming image/png type
From: Jakub Narebski @ 2006-09-02 16:57 UTC (permalink / raw)
To: git
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
My first [PATCH] with binary patch.
Makefile | 2 ++
gitweb/git-favicon.png | Bin
gitweb/gitweb.perl | 5 +++++
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 164dbcf734c964b7de1742f2d63db710a323e284..6a2cce5fecd0a966075222bd59c44cd206c88886 100644
--- a/Makefile
+++ b/Makefile
@@ -137,6 +137,7 @@ GITWEB_LIST =
GITWEB_HOMETEXT = indextext.html
GITWEB_CSS = gitweb.css
GITWEB_LOGO = git-logo.png
+GITWEB_FAVICON = git-favicon.png
export prefix bindir gitexecdir template_dir GIT_PYTHON_DIR
@@ -674,6 +675,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_HOMETEXT++|$(GITWEB_HOMETEXT)|g' \
-e 's|++GITWEB_CSS++|$(GITWEB_CSS)|g' \
-e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
+ -e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
$< >$@+
chmod +x $@+
mv $@+ $@
diff --git a/gitweb/git-favicon.png b/gitweb/git-favicon.png
new file mode 100644
index 0000000000000000000000000000000000000000..de637c0608090162a6ce6b51d5f9bfe512cf8bcf
GIT binary patch
literal 164
zc-rd>@N?(olHy`uVBq!ia0vp^0wB!93?!50ihlx9JOMr-t_OgO28RD&a4c8tKak5=
z;1OBOz`!jG!i)^F=12eq?L1u^Ln;_q4{j86a1dcV@b%g0mmUiOK9(+Io+#BK-XURJ
z*52lzAh4o%_q+oa1XgVS7Wa3@eurhH>!fs<8s*Qab3eLq`JX({BnD4cKbLh*2~7aN
C3N}^%
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 06bdb0ed74ae1d810645359dcd7713acb41e1b37..74ea6b369394dd47acfca3d023b2a8fdaaa355db 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -48,6 +48,8 @@ # URI of default stylesheet
our $stylesheet = "++GITWEB_CSS++";
# URI of GIT logo
our $logo = "++GITWEB_LOGO++";
+# URI of GIT favicon, assumed to be image/png type
+our $favicon = "++GITWEB_FAVICON++";
# source of projects list
our $projects_list = "++GITWEB_LIST++";
@@ -1225,6 +1227,9 @@ EOF
'href="%s" type="application/rss+xml"/>'."\n",
esc_param($project), href(action=>"rss"));
}
+ if (defined $favicon) {
+ print qq(<link rel="shortcut icon" href="$favicon" type="image/png"/>\n);
+ }
print "</head>\n" .
"<body>\n" .
--
1.4.1.1
--
VGER BF report: U 0.5
^ permalink raw reply related
* [PATCH] Trace into a file or an open fd and refactor tracing code.
From: Christian Couder @ 2006-09-02 16:23 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
If GIT_TRACE is set to an absolute path (starting with a
'/' character), we interpret this as a file path and we
trace into it.
Also if GIT_TRACE is set to an integer value greater than
1 and lower than 10, we interpret this as an open fd value
and we trace into it.
Note that this behavior is not compatible with the
previous one.
We also trace whole messages using one write(2) call to
make sure messages from processes do net get mixed up in
the middle.
This patch makes it possible to get trace information when
running "make test".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Makefile | 2 -
cache.h | 6 ++
exec_cmd.c | 18 +------
git.c | 25 ++-------
imap-send.c | 25 ---------
quote.c | 32 ++++++++++++
quote.h | 1
t/test-lib.sh | 10 +++-
trace.c | 149 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
write_or_die.c | 25 +++++++++
10 files changed, 229 insertions(+), 64 deletions(-)
diff --git a/Makefile b/Makefile
index 05bd77f..a639cdf 100644
--- a/Makefile
+++ b/Makefile
@@ -249,7 +249,7 @@ LIB_OBJS = \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o \
- write_or_die.o \
+ write_or_die.o trace.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS)
BUILTIN_OBJS = \
diff --git a/cache.h b/cache.h
index 7257c4c..195908f 100644
--- a/cache.h
+++ b/cache.h
@@ -398,6 +398,7 @@ extern char git_commit_encoding[MAX_ENCO
extern int copy_fd(int ifd, int ofd);
extern void write_or_die(int fd, const void *buf, size_t count);
+extern int write_or_whine(int fd, const void *buf, size_t count, const char *msg);
/* Finish off pack transfer receiving end */
extern int receive_unpack_pack(int fd[2], const char *me, int quiet, int);
@@ -423,4 +424,9 @@ extern struct commit *alloc_commit_node(
extern struct tag *alloc_tag_node(void);
extern void alloc_report(void);
+/* trace.c */
+extern int nfvasprintf(char **str, const char *fmt, va_list va);
+extern void trace_printf(const char *format, ...);
+extern void trace_argv_printf(const char **argv, int count, const char *format, ...);
+
#endif /* CACHE_H */
diff --git a/exec_cmd.c b/exec_cmd.c
index e30936d..5d6a124 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -97,26 +97,12 @@ int execv_git_cmd(const char **argv)
tmp = argv[0];
argv[0] = git_command;
- if (getenv("GIT_TRACE")) {
- const char **p = argv;
- fputs("trace: exec:", stderr);
- while (*p) {
- fputc(' ', stderr);
- sq_quote_print(stderr, *p);
- ++p;
- }
- putc('\n', stderr);
- fflush(stderr);
- }
+ trace_argv_printf(argv, -1, "trace: exec:");
/* execve() can only ever return if it fails */
execve(git_command, (char **)argv, environ);
- if (getenv("GIT_TRACE")) {
- fprintf(stderr, "trace: exec failed: %s\n",
- strerror(errno));
- fflush(stderr);
- }
+ trace_printf("trace: exec failed: %s\n", strerror(errno));
argv[0] = tmp;
}
diff --git a/git.c b/git.c
index 05871ad..403fb3a 100644
--- a/git.c
+++ b/git.c
@@ -179,17 +179,9 @@ static int handle_alias(int *argcp, cons
if (!strcmp(alias_command, new_argv[0]))
die("recursive alias: %s", alias_command);
- if (getenv("GIT_TRACE")) {
- int i;
- fprintf(stderr, "trace: alias expansion: %s =>",
- alias_command);
- for (i = 0; i < count; ++i) {
- fputc(' ', stderr);
- sq_quote_print(stderr, new_argv[i]);
- }
- fputc('\n', stderr);
- fflush(stderr);
- }
+ trace_argv_printf(new_argv, count,
+ "trace: alias expansion: %s =>",
+ alias_command);
new_argv = xrealloc(new_argv, sizeof(char*) *
(count + *argcp + 1));
@@ -292,16 +284,7 @@ static void handle_internal_command(int
prefix = setup_git_directory();
if (p->option & USE_PAGER)
setup_pager();
- if (getenv("GIT_TRACE")) {
- int j;
- fprintf(stderr, "trace: built-in: git");
- for (j = 0; j < argc; ++j) {
- fputc(' ', stderr);
- sq_quote_print(stderr, argv[j]);
- }
- putc('\n', stderr);
- fflush(stderr);
- }
+ trace_argv_printf(argv, argc, "trace: built-in: git");
exit(p->fn(argc, argv, prefix));
}
diff --git a/imap-send.c b/imap-send.c
index 65c71c6..6a52dbd 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -110,7 +110,6 @@ static char *next_arg( char ** );
static void free_generic_messages( message_t * );
-static int nfvasprintf( char **str, const char *fmt, va_list va );
static int nfsnprintf( char *buf, int blen, const char *fmt, ... );
@@ -372,21 +371,6 @@ free_generic_messages( message_t *msgs )
}
static int
-git_vasprintf( char **strp, const char *fmt, va_list ap )
-{
- int len;
- char tmp[1024];
-
- if ((len = vsnprintf( tmp, sizeof(tmp), fmt, ap )) < 0 || !(*strp = xmalloc( len + 1 )))
- return -1;
- if (len >= (int)sizeof(tmp))
- vsprintf( *strp, fmt, ap );
- else
- memcpy( *strp, tmp, len + 1 );
- return len;
-}
-
-static int
nfsnprintf( char *buf, int blen, const char *fmt, ... )
{
int ret;
@@ -399,15 +383,6 @@ nfsnprintf( char *buf, int blen, const c
return ret;
}
-static int
-nfvasprintf( char **str, const char *fmt, va_list va )
-{
- int ret = git_vasprintf( str, fmt, va );
- if (ret < 0)
- die( "Fatal: Out of memory\n");
- return ret;
-}
-
static struct {
unsigned char i, j, s[256];
} rs;
diff --git a/quote.c b/quote.c
index e220dcc..f90091e 100644
--- a/quote.c
+++ b/quote.c
@@ -74,6 +74,38 @@ char *sq_quote(const char *src)
return buf;
}
+char *sq_quote_argv(const char** argv, int count)
+{
+ char *buf, *to;
+ int i;
+ size_t len = 0;
+
+ /* Count argv if needed. */
+ if (count < 0) {
+ for (count = 0; argv[count]; count++)
+ ; /* just counting */
+ }
+
+ /* Special case: no argv. */
+ if (!count)
+ return xcalloc(1,1);
+
+ /* Get destination buffer length. */
+ for (i = 0; i < count; i++)
+ len += sq_quote_buf(NULL, 0, argv[i]) + 1;
+
+ /* Alloc destination buffer. */
+ to = buf = xmalloc(len + 1);
+
+ /* Copy into destination buffer. */
+ for (i = 0; i < count; ++i) {
+ *to++ = ' ';
+ to += sq_quote_buf(to, len, argv[i]);
+ }
+
+ return buf;
+}
+
char *sq_dequote(char *arg)
{
char *dst = arg;
diff --git a/quote.h b/quote.h
index fc5481e..a6c4611 100644
--- a/quote.h
+++ b/quote.h
@@ -31,6 +31,7 @@ #include <stdio.h>
extern char *sq_quote(const char *src);
extern void sq_quote_print(FILE *stream, const char *src);
extern size_t sq_quote_buf(char *dst, size_t n, const char *src);
+extern char *sq_quote_argv(const char** argv, int count);
/* This unwraps what sq_quote() produces in place, but returns
* NULL if the input does not look like what sq_quote would have
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 470a909..e262933 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -28,13 +28,21 @@ unset GIT_DIR
unset GIT_EXTERNAL_DIFF
unset GIT_INDEX_FILE
unset GIT_OBJECT_DIRECTORY
-unset GIT_TRACE
unset SHA1_FILE_DIRECTORIES
unset SHA1_FILE_DIRECTORY
export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export EDITOR VISUAL
+case $(echo $GIT_TRACE |tr [A-Z] [a-z]) in
+ 1|2|true)
+ echo "* warning: Some tests will not work if GIT_TRACE" \
+ "is set as to trace on STDERR ! *"
+ echo "* warning: Please set GIT_TRACE to something" \
+ "other than 1, 2 or true ! *"
+ ;;
+esac
+
# Each test should start with something like this, after copyright notices:
#
# test_description='Description of this test...
diff --git a/trace.c b/trace.c
new file mode 100644
index 0000000..fecd897
--- /dev/null
+++ b/trace.c
@@ -0,0 +1,149 @@
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) 2000-2002 Michael R. Elkins <me@mutt.org>
+ * Copyright (C) 2002-2004 Oswald Buddenhagen <ossi@users.sf.net>
+ * Copyright (C) 2004 Theodore Y. Ts'o <tytso@mit.edu>
+ * Copyright (C) 2006 Mike McCormack
+ * Copyright (C) 2006 Christian Couder
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include "cache.h"
+#include "quote.h"
+
+/* Stolen from "imap-send.c". */
+static int git_vasprintf(char **strp, const char *fmt, va_list ap)
+{
+ int len;
+ char tmp[1024];
+
+ if ((len = vsnprintf(tmp, sizeof(tmp), fmt, ap)) < 0 ||
+ !(*strp = xmalloc(len + 1)))
+ return -1;
+ if (len >= (int)sizeof(tmp))
+ vsprintf(*strp, fmt, ap);
+ else
+ memcpy(*strp, tmp, len + 1);
+ return len;
+}
+
+/* Stolen from "imap-send.c". */
+int nfvasprintf(char **str, const char *fmt, va_list va)
+{
+ int ret = git_vasprintf(str, fmt, va);
+ if (ret < 0)
+ die("Fatal: Out of memory\n");
+ return ret;
+}
+
+/* Get a trace file descriptor from GIT_TRACE env variable. */
+static int get_trace_fd(int *need_close)
+{
+ char *trace = getenv("GIT_TRACE");
+
+ if (!trace || !strcmp(trace, "0") || !strcasecmp(trace," false"))
+ return 0;
+ if (!strcmp(trace, "1") || !strcasecmp(trace, "true"))
+ return STDERR_FILENO;
+ if (strlen(trace) == 1 && isdigit(*trace))
+ return atoi(trace);
+ if (*trace == '/') {
+ int fd = open(trace, O_WRONLY | O_APPEND | O_CREAT, 0666);
+ if (fd == -1) {
+ fprintf(stderr,
+ "Could not open '%s' for tracing: %s\n"
+ "Defaulting to tracing on stderr...\n",
+ trace, strerror(errno));
+ return STDERR_FILENO;
+ }
+ *need_close = 1;
+ return fd;
+ }
+
+ fprintf(stderr, "What does '%s' for GIT_TRACE means ?\n", trace);
+ fprintf(stderr, "If you want to trace into a file, "
+ "then please set GIT_TRACE to an absolute pathname "
+ "(starting with /).\n");
+ fprintf(stderr, "Defaulting to tracing on stderr...\n");
+
+ return STDERR_FILENO;
+}
+
+static const char err_msg[] = "Could not trace into fd given by "
+ "GIT_TRACE environment variable";
+
+void trace_printf(const char *format, ...)
+{
+ char *trace_str;
+ va_list rest;
+ int need_close = 0;
+ int fd = get_trace_fd(&need_close);
+
+ if (!fd)
+ return;
+
+ va_start(rest, format);
+ nfvasprintf(&trace_str, format, rest);
+ va_end(rest);
+
+ write_or_whine(fd, trace_str, strlen(trace_str), err_msg);
+
+ free(trace_str);
+
+ if (need_close)
+ close(fd);
+}
+
+void trace_argv_printf(const char **argv, int count, const char *format, ...)
+{
+ char *argv_str, *format_str, *trace_str;
+ size_t argv_len, format_len, trace_len;
+ va_list rest;
+ int need_close = 0;
+ int fd = get_trace_fd(&need_close);
+
+ if (!fd)
+ return;
+
+ /* Get the argv string. */
+ argv_str = sq_quote_argv(argv, count);
+ argv_len = strlen(argv_str);
+
+ /* Get the formated string. */
+ va_start(rest, format);
+ nfvasprintf(&format_str, format, rest);
+ va_end(rest);
+
+ /* Allocate buffer for trace string. */
+ format_len = strlen(format_str);
+ trace_len = argv_len + format_len + 1; /* + 1 for \n */
+ trace_str = xmalloc(trace_len + 1);
+
+ /* Copy everything into the trace string. */
+ strncpy(trace_str, format_str, format_len);
+ strncpy(trace_str + format_len, argv_str, argv_len);
+ strcpy(trace_str + trace_len - 1, "\n");
+
+ write_or_whine(fd, trace_str, trace_len, err_msg);
+
+ free(argv_str);
+ free(format_str);
+ free(trace_str);
+
+ if (need_close)
+ close(fd);
+}
diff --git a/write_or_die.c b/write_or_die.c
index ab4cb8a..bfe4eeb 100644
--- a/write_or_die.c
+++ b/write_or_die.c
@@ -18,3 +18,28 @@ void write_or_die(int fd, const void *bu
p += written;
}
}
+
+int write_or_whine(int fd, const void *buf, size_t count, const char *msg)
+{
+ const char *p = buf;
+ ssize_t written;
+
+ while (count > 0) {
+ written = xwrite(fd, p, count);
+ if (written == 0) {
+ fprintf(stderr, "%s: disk full?\n", msg);
+ return 0;
+ }
+ else if (written < 0) {
+ if (errno == EPIPE)
+ exit(0);
+ fprintf(stderr, "%s: write error (%s)\n",
+ msg, strerror(errno));
+ return 0;
+ }
+ count -= written;
+ p += written;
+ }
+
+ return 1;
+}
--
1.4.2.g0f2c-dirty
--
VGER BF report: U 0.5
^ permalink raw reply related
* [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-09-02 16:17 UTC (permalink / raw)
To: git
This is second series of planned gitweb features. Still ideas for many
of them come from xmms2's gitweb version, which can you see in work at
http://git.xmms.se/?p=gitweb-xmms2.git;a=summary
Some of gitweb features like snapshot support and clone/fetch URL were
implemented, some of cleanup like refactoring navbar generation or
putting CSS into separate style file too.
I have put the list here for three reasons. First to get input which
features are most wanted, and to receive perhaps ideas for new
features. Second, to have TODO list, and receive input if somebody is
doing implementing some of the features to avoid duplicate work. Third,
and most important, some of features needs discussion about _how_ to
implement them.
Copy sent to Sham Chukoury, owner of gitweb-xmms2.
Cleanup, tidying, refactoring:
* HTML code still needs cleanup. All elements should have be either
assigned class, or given unique id. Presentational elements like <i>
or <b> should be replaced by styling using CSS. Page should be divided
into block elements; avoid overuse of <br/>.
* CSS cleanup. Names of classes should reflect intent, not be
replacement for presentational elements, or be incomprehensive:
e.g. classes age0, age1, age2, dark, light. padding: 8px; repeats many
times, perhaps it could be replaced by setting margin in encompassing
element, or via inheritance or additional class.
* Separate generating link and related links to object
(e.g. "blob | blame | history | raw" for blob in "tree" view)
into subroutine, similarly to refactoring navbar. The problem is that
the set of links depends not only on the type of object, but also on
the action/view we are in, for example links to commit object might
be either "commit | commitdiff", or "log | shortlog" if the commit is
considered ref. DISCUSSION needed.
* Collapse similar subroutines into one, e.g. git_blob and
git_blob_plain, and use parameter to set format. Perhaps instead of
having
sub git_commitdiff_plain {
git_commitdiff('plain');
}
we can simply use
my %actions = (
# ...
"commitdiff_plain" => sub { git_commitdiff('plain'); }
# ...
);
Which of this options is more readable, which one is faster?
* Refactoring formatsnav similarly to commit/hashbase related main
navbar (upper part of navbar now). For blob it would be "html",
"plain", "blame", "head" (or "base"), optionally "HEAD", "history",
perhaps later "highlight". For tree it would be "tree", "blame" and
"history". For commit it would be "html", "plain", and "combined"
if applicable.
* Perhaps some of the views should be made into format, e.g. 'shortlog'
and 'log' (and perhaps 'rss') for log views (this includes
"log"/"shortlog" and "history" views), or 'html', 'opml' and
'plain'/'index' for "project_list". DISCUSSION encouraged.
* Things like description or cloneurls (repourls) and further category
should be perhaps available to set in repository config, not only from
additional files in repository.
Gitweb speed:
* Ensure that gitweb is compatibile with mod_perl not only in
Apache::Registry/ModPerl::Registry CGI script compatibility mode,
but also as native mod_perl handler/script. Make it easy to use
FastCGI instead of CGI (perhaps via CGI::Fast).
This could be ensured by creating 'handler'/'main' method which
does parameter reading, validation and dispatching action. Perhaps
we should add gitweb_params subroutine, which given the names
of parameters returns values of needed parameters (either as list of
parameter names and returning list of parameters in order set by
subroutine argument, or as hash with keys and undefined values and
returning hash or hashref with values filled). The exception being
project and action parameters, which must be accessed before
dispatching action.
We could make script options parameters my() again, and leave our()
only for global variables which changes from invocation to invocation,
like $project, $action, $git_dir etc.
* Add new CORE GIT command, git-show-refs, which returns for given
by glob set of refs required fields (specified by --format option),
sorted by given field (specified by --sort option). This would speed
up "tags" and "summary" views considerably.
See Junio post in "[PATCH/RFC] gitweb: Great subroutines renaming"
thread for proposed git-show-refs options.
http://permalink.gmane.org/gmane.comp.version-control.git/25055
Message-Id: <7vejvsyum8.fsf@assigned-by-dhcp.cox.net>
* Try to avoid unnecessary calls to git commands, try do do things
using one command. For example instead of getting list of revisions
from git-rev-list, then parsing commit after commit use one
git-rev-list invocation to get and parse list of revisions.
It would be easier if some CORE GIT commands, for example git-ls-tree,
acquired --stdin option, similarly to git-diff-tree (and output
revision before output for that revison, like git-diff-tree).
* In the future, use Git.pm
Improvements of existing views and features:
* Make pickaxe search a feature (as it is expensive), and document
existing search operators. Perhaps refactor git_search as well.
* Make history follow renames. This could I think be done without CORE
GIT support, but it would be better with it. The proposition is to add
--follow option to git-rev-list (or -C, -M, -B options), which would
make if follow renames in files in path limit; I think following
renames with pathspec being glob is out, unless we expand glob to
individual file names and then follow those, and that following
directory renames would be very hard if not impossible.
Additionally make git-rev-list output current path limit, in format
suitable as argument for other git commands like git-diff-tree, i.e.
<hash> -- <path limit>
instead of current
<hash>
Make git-diff-tree at least accept and understand this kind of input
also on stdin with --stdin option.
* Perhaps add number of changed lines to the short information about
blob (perhaps via title to patch/diff link?), and diffstat to
"commitdiff_plain" view.
* Parse $GIT_DIR/remotes/ to mark tracking branches in "heads" view,
e.g. as a popup.
New features:
* Categories support (from gitweb-xmms2), although I'm not sure about
adding yet another file "category" to git repository. Perhaps first
part of dirname could serve as category name, or we could use
gitweb.category configuration variable.
* Code highlighting in blob view (from gitweb-xmms2), or to generalize
to allow for generalized filter. The higlighter should have support
for HTML support, it should always close elements before end of line,
it would be better if it used CSS for styling, and it should accept
file to highlight on standard input. gitweb-xmms2 uses Highlight
http://www.andre-simon.de/
but GNU Highlight (src-hilite) could be used instead
http://www.gnu.org/software/src-highlite/
* Committags support, i.e. extend hyperlinking commit sha1 to commit
view to hyperlinking bug #nn/BUG(nn) to the proper bugtracker, in both
commit message view and (harder to do properly) in commit
title/subject line which is hyperlink itself. The problem is how to do
this general enough...
I have thought about structure somewhat similar to %feature hash, i.e.
something like %commitfilter hash, with 'enabled', 'override', 'name',
'options' or something like that and of course 'sub' (as we probably
would use $cgi->a(...) to construct hyperlink, and not simple regexp
replacement.
DISCUSSION needed.
* Etags/Ctags/LXR based anchors in the blob view. In gitweb-xmms2 they
use temporary file to avoid race condition for both etags and
highlighting. Is it worth doing? GNU Highlight has ctags
(encumberant-ctags) support built in, I don't know about Highlight.
New views:
* Reflog support: show history of branch. I'm not sure if it is worth
doing, as of now reflogs are local matter, and doesn't get copied on
push even to bare repository.
* ViewVC-like "tree_blame" view. It probably would need CORE GIT support
to have acceptable speed, although version using git-ls-tree wasn't
that slow. Or at least git-ls-tree with --stdin support.
* gitk-ish (qgit-ish) view, with graph showing branches forking and
merging. Not that easy, but probably possible.
In the future:
* AJAX-ize parts of gitweb.
Comments? Other ideas? <wishful thinking>Code?</wishful thinking>
--
Jakub Narebski
ShadeHawk on #git
Poland
--
VGER BF report: H 0
^ 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