* Re: git-svnimport failed and now git-repack hates me
From: Linus Torvalds @ 2007-01-04 18:30 UTC (permalink / raw)
To: Chris Lee; +Cc: Git Mailing List
In-Reply-To: <204011cb0701040956p11ea2cepe3efaaf396056ac0@mail.gmail.com>
On Thu, 4 Jan 2007, Chris Lee wrote:
>
> Unfortunately, that's how the KDE repo is organized. (I tried arguing
> against this when they were going to do the original import, but I
> lost the argument.) And git-svnimport doesn't appear to have any sort
> of method for splitting a gigantic svn repo into several smaller git
> repos.
Well, the good news is, I think we could probably split it up from within
git. It's not fundamentally hard, although it is pretty damn expensive
(and it would require the subproject support to do really well).
So ignore that issue for now. I'd love to see the end result, if only
because it sounds like you have a test-case for git that is four times
bigger than the mozilla archive - even if it's just because of some really
really stupid design decisions from the KDE SVN maintainers ;)
(But I would actually expect that KDE SVN uses SVN subprojects, so
hopefully it's not _really_ one big repository. Of course, I don't know if
SVN really does subprojects or how well it does them, so that's just a
total guess).
The real problem with a SVN import is that I think SVN doesn't do merges
right, so you can't import merge history properly (well, you can, if you
decide that "properly" really means "SVN can't merge, so we can't really
show it as merges in git either").
I think both git-svn and git-svnimport can _guess_ about merges, but it's
just a heuristic, afaik. Whether it's a good one, I don't know.
> Yeah. I haven't bothered hacking git-svnimport yet - but it looks like
> having it automatically repack every thousand revisions or so would
> probably be a pretty big win.
That, or making it use the same "fastimport" that the hacked-up CVS
importer was made to use. Either way, somebody who understands SVN
intimately (and probably perl) would need to work on it.
That would not be me, so I can't really help ;)
> By default, if I had, say, one pack with the first 1000 revisions, and
> I imported another 1000, running 'git-repack' on its own would leave
> the first pack alone and create a new pack with just the second 1000
> revisions, right?
Yes. It's _probably_ better to do a full re-pack every once in a while
(because if you have a lot of pack-files, eventually that ends up being
problematic too), but as a first approximation, it's probably fine to just
do a plain "git repack" every thousand commits, and then do a full big
repack at the end.
The big repack will still be pretty expensive, but it should be less
painful than having everything unpacked. And at least the import won't
have run with millions and millions of loose objects.
So doing a "git repack -a -d" at the end is a good idea, and _maybe_ it
could be done in the middle too for really big packs.
Again, doing what fastimport does avoids most of the whole issue, since it
just generates a pack up-front instead. But that requires the importer to
specifically understand about that kind of setup.
> This is on a dual-CPU dual-core Opteron, running the AMD64 variant of
> Ubuntu's Edgy release (64-bit kernel, 64-bit native userland). The
> pack-file was around 2.3GB.
Ok, that should all be fine. A 31-bit thing in OpenSSL would explain it,
and doesn't sound unlikely. Just somebody using "int" somewhere, and it
would never have been triggered by any sane user of SHA1_Update(). The git
pack-check.c usage really _is_ very odd, even if it happens to make sense
in that particular schenario.
Linus
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Alex Riesen @ 2007-01-04 18:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt4647g0.fsf@assigned-by-dhcp.cox.net>
On 1/2/07, Junio C Hamano <junkio@cox.net> wrote:
> Here are the topics that have been cooking. Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'. The topics list the commits in reverse chronological
> order.
>
> * sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
Running this and the merge-recursive speedup I sent today locally.
sp/mmap needs relatively recent cygwin library (otherwise pread
is broken). No other ill effects noticed. Perfomance is bearable.
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Chris Lee @ 2007-01-04 17:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Shawn Pearce, Sasha Khapyorsky, Git Mailing List
In-Reply-To: <7v1wmbnw9x.fsf@assigned-by-dhcp.cox.net>
> If Chris still has that huge .pack & .idx pair, it would be a
> very good guinea pig to try a few things on, assuming that this
> problem is that the pack-check.c feeds a huge blob to SHA-1
> function with a single call.
I do not still have it, but I can pretty easily regenerate it. Should
have it again in another nine hours or so. :)
> (1) Apply the attached patch on top of "master" (the patch
> should apply to 1.4.1 almost cleanly as well, except that
> we have hashcmp(a,b) instead of memcmp(a,b,20) since then),
> and see what it says about the packfile. If your suspicion
> is correct, it should complain about your SHA-1
> implementation.
>
> (2) Try tip of "next" to see if its verify-pack passes the
> check. Again, if your suspicion is correct, it should, since it
> uses Shawn's sliding mmap() stuff that will not feed the
> whole pack in one go.
>
> (3) I suspect that the tip of "master" should work except
> verify-pack. It may be interesting to see how well the tip
> of "master" and "next" performs on the resulting huge pack
> (say, "time git log -p HEAD >/dev/null"). I am hoping this
> would be another datapoint to judge the runtime penalty of
> Shawn's sliding mmap() in "next" -- I suspect the penalty
> is either negligible or even negative.
I'll try all of this after the pack is regenerated. Thanks!
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Chris Lee @ 2007-01-04 17:56 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <204011cb0701031816hda8af9bw4d4a469c2b111339@mail.gmail.com>
Accidentally sent this to just Linus instead of the list...
On 1/3/07, Linus Torvalds <torvalds@osdl.org> wrote:
> > So I'm using git 1.4.1, and I have been experimenting with importing
> > the KDE sources from Subversion using git-svnimport.
>
> As one single _huge_ import? All the sub-projects together? I have to say,
> that sounds pretty horrid.
Unfortunately, that's how the KDE repo is organized. (I tried arguing
against this when they were going to do the original import, but I
lost the argument.) And git-svnimport doesn't appear to have any sort
of method for splitting a gigantic svn repo into several smaller git
repos.
> > First issue I ran into: On a machine with 4GB of RAM, when I tried to
> > do a full import, git-svnimport died after 309906 revisions, saying
> > that it couldn't fork.
> >
> > Checking `top` and `ps` revealed that there were no git-svnimport
> > processes doing anything, but all of my 4G of RAM was still marked as
> > used by the kernel. I had to do sysctl -w vm.drop_caches=3 to get it
> > to free all the RAM that the svn import had used up.
>
> I think that was just all cached, and all ok. The reason you didn't see
> any git-svnimport was that it had died off already, and all your memory
> was just caches. You could just have left it alone, and the kernel would
> have started re-using the memory for other things even without any
> "drop_caches".
>
> But what you did there didn't make anything worse, it was just likely had
> no real impact.
I got the tip about drop_caches from davej. Normally, when a process
taking up a huge amount of memory exits, it shows a bunch of free
memory in `top` and friends. I was a little bit surprised when that
didn't happen this time.
> However, it does sound like git-svnimport probably acts like git-cvsimport
> used to, and just keeps too much in memory - so it's never going to act
> really nicely..
>
> It also looks like git-svnimport never repacks the repo, which is
> absolutely horrible for performance on all levels. The CVS importer
> repacks every one thousand commits or something like that.
Yeah. I haven't bothered hacking git-svnimport yet - but it looks like
having it automatically repack every thousand revisions or so would
probably be a pretty big win.
> > Now, after that, I tried doing `git-repack -a` because I wanted to see
> > how small the packed archive would be (before trying to continue
> > importing the rest of the revisions. There are at least another 100k
> > revisions that I should be able to import, eventually.)
>
> I suspect you'd have been better off just re-starting, and using something
> like
>
> while :
> do
> git svnimport -l 1000 <...>
> .. figure out some way to decide if it's all done ..
> git repack -d
> done
>
> which would make svnimport act a bit more sanely, and repack
> incrementally. That should make both the import much faster, _and_ avoid
> any insane big repack at the end (well, you'd still want to do a "git
> repack -a -d" at the end to turn the many smaller packs into a bigger one,
> but it would be nicer).
>
> However, I don't know what the proper magic is for svnimport to do that
> sane "do it in chunks and tell when you're all done". Or even better - to
> just make it repack properly and not keep everything in memory.
You can pass limits to svnimport to give it a revision to start at and
another one to end at, so that wouldn't be too bad - I was thinking
about working around it like that (so that i don't have to go poking
around in the Perl code behind the svn importer).
By default, if I had, say, one pack with the first 1000 revisions, and
I imported another 1000, running 'git-repack' on its own would leave
the first pack alone and create a new pack with just the second 1000
revisions, right?
> > The repack finished after about nine hours, but when I try to do a
> > git-verify-pack on it, it dies with this error message:
> >
> > error: Packfile
> > .git/objects/pack/pack-540263fe66ab9398cc796f000d52531a5c6f3df3.pack
> > SHA1 mismatch with itself
>
> That sounds suspiciously like the bug we had in out POWER sha1
> implementation that would generate the wrong SHA1 for any pack-file that
> was over 512MB in size, due to an overflow in 32 bits (SHA1 does some
> counting in _bits_, so 512MB is 4G _bits_),
>
> Now, I assume you're not on POWER (and we fixed that bug anyway - and I
> think long before 1.4.1 too), but I could easily imagine the same bug in
> some other SHA1 implementation (or perhaps _another_ overflow at the 1GB
> or 2GB mark..). I assume that the pack-file you had was something horrid..
>
> I hope this is with a 64-bit kernel and a 64-bit user space? That should
> limit _some_ of the issues. But I would still not be surprised if your
> SHA1 libraries had some 32-bit ("unsigned int") or 31-bit ("int") limits
> in them somewhere - very few people do SHA1's over huge areas, and even
> when you do SHA1 on something like a DVD image (which is easily over any
> 4GB limit), that tends to be done as many smaller calls to the SHA1
> library routines.
This is on a dual-CPU dual-core Opteron, running the AMD64 variant of
Ubuntu's Edgy release (64-bit kernel, 64-bit native userland). The
pack-file was around 2.3GB.
^ permalink raw reply
* Re: How to commit removed file?
From: Michael S. Tsirkin @ 2007-01-04 17:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vwt44pop0.fsf@assigned-by-dhcp.cox.net>
> > ... That's a
> > great news.
> >
> > I am not interested to make it "all" myself -- if somebody else
> > does it, that is fine, though ;-).
>
> Just in case you do not know me, sorry for too much negative
> tone in my message. I was just venting. It was not like I was
> offended by something you said or anything like that.
>
> The "commit path..." feature, while I would even agree that it
> sometimes is useful in simple cases, is something that goes
> quite against what git does normally, and anybody would
> understand why after inspecting what git-commit has to do to
> implement that. I personally hate that "feature".
>
> Having said that, I am known to support features that I do not
> agree with myself for other people, and sometimes even implement
> them myself. But that does not mean I have to like them ;-).
Well, it's just a minor annoyance for me, so unless more people
ask for this to be fixed, I'm unlikely to invest time in this, either.
--
MST
^ permalink raw reply
* git-svn usability
From: David Kågedal @ 2007-01-04 17:34 UTC (permalink / raw)
To: git
I wanted to try out "git svn" and did a "git help svn" and got the man
page for git-svn. That page starts out by describing that git-svn
only is useful for working with a single svn branch. But then,
further down, it describes the commands "multi-init" and
"multi-fetch" anyway. Confusing. But I decided to give them a try.
But there isn't really any clear description on what the command line
should look like when you use multi-init (or any other git-svn command
for that matter). So I boldly decided to try to run "git svn help
multi-init". You never know, it might tell you something. This is
what happened:
morpheus% git svn help multi-init
GIT_SVN_ID set to 'trunk' for help/trunk
Initialized empty Git repository in /home/david/tmp/.git/
W: --branches/-b not specified
W: --tags/-t not specified
Not exactly what I wanted. The command-line parser in git-svn is
broken since it picks the first argument that looks like a command
name.
--
David Kågedal
^ permalink raw reply
* Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge
From: Horst H. von Brand @ 2007-01-04 16:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <459D1F54.1060709@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Junio C Hamano wrote:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> >> Junio C Hamano <junkio@cox.net> wrote:
> >>> After a pull that results in a conflicted merge, a new user
> >>> often tries another "git pull" in desperation. When the index
> >>> is unmerged, merge backends correctly bail out without touching
> >>> either index nor the working tree, so this does not make the
> >>> wound any worse.
> >> I've seen this many times too. I don't understand why users cannot
> >> read output messages and realize the current command failed, but
> >> they don't. *sigh*
> > That is not user's fault. Tools should not make things worse
> > when run more than once after they failed, and we do not either,
> > so it is not a stupid behaviour on the user's part to do that.
> > We just need to make sure that it is more clear to the user that
> > pull after a conflicted pull is futile, which is what this patch
> > does.
> "Pulling is futile. Nothing will be assimilated" ?
:-)
Been there, done that. The messages git gives don't give a (at this point
probably panicked) newbie any clue what to try next, or how to go back.
Perhaps best would be to offer some way to undo all and then try again?
Also, if a manual fix of the merge is warranted, the message doesn't give
clear directions on what to do next. Sure, you edit the offending files to
your liking, then what? "git commit" shows a scary commit message, you
abort the edit and the merge is commited anyway.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [PATCH] git-reset --hard: tell the user what the HEAD was reset to
From: Andy Whitcroft @ 2007-01-04 15:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git
In-Reply-To: <Pine.LNX.4.63.0701041357380.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 3 Jan 2007, Andy Whitcroft wrote:
>
>> I think we need to delimit the name better, probabally we need to quote
>> it. Perhaps something like:
>>
>> HEAD is now at ac9c110: "git-fetch: remove .keep file at the end".
>
> Fine. But this is "git log --pretty=oneline --abbrev-commit". I don't know
> how many things break if you change _that_.
>
> Alternatively, you could pipe that into a sed command adding the colon and
> the quotes.
Quack, so it is.
apw@pinky$ git log --pretty=oneline --abbrev-commit | head -1
f4bf218... Update clone/fetch documentation with --depth (shallow clone)
option
Perhaps we could do something like:
Head is now at "f4bf218... Update clone/fetch documentation with --depth
(shallow clone) option"
Hmmm ... oh well I guess I'll just get used to it.
-apw
^ permalink raw reply
* Re: [PATCH] Skip excessive blank lines before commit body
From: Andreas Ericsson @ 2007-01-04 15:50 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano
In-Reply-To: <11678312532251-git-send-email-hjemli@gmail.com>
Lars Hjemli wrote:
> This modifies pretty_print_commit() to make the output of git-rev-list and
> friends a bit more predictable.
>
> A commit body starting with blank lines might be unheard-of, but still possible
> to create using git-commit-tree (so is bound to appear somewhere, sometime).
>
Lovely. I was just looking in to doing the exact same thing myself.
For reference, there is a tool somewhere that creates CVS commit
messages with an empty title-line. When imported to git, those empty
lines remain and fuzz up gitk and qgit viewing ad nauseum. I'm guessing
(and hoping) this patch would take care of it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge
From: Andreas Ericsson @ 2007-01-04 15:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vmz51usqf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> Junio C Hamano <junkio@cox.net> wrote:
>>> After a pull that results in a conflicted merge, a new user
>>> often tries another "git pull" in desperation. When the index
>>> is unmerged, merge backends correctly bail out without touching
>>> either index nor the working tree, so this does not make the
>>> wound any worse.
>> I've seen this many times too. I don't understand why users cannot
>> read output messages and realize the current command failed, but
>> they don't. *sigh*
>
> That is not user's fault. Tools should not make things worse
> when run more than once after they failed, and we do not either,
> so it is not a stupid behaviour on the user's part to do that.
>
> We just need to make sure that it is more clear to the user that
> pull after a conflicted pull is futile, which is what this patch
> does.
>
"Pulling is futile. Nothing will be assimilated" ?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-svnimport failed and now git-repack hates me
From: Chris Lee @ 2007-01-04 2:16 UTC (permalink / raw)
To: Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0701031737300.4989@woody.osdl.org>
On 1/3/07, Linus Torvalds <torvalds@osdl.org> wrote:
> > So I'm using git 1.4.1, and I have been experimenting with importing
> > the KDE sources from Subversion using git-svnimport.
>
> As one single _huge_ import? All the sub-projects together? I have to say,
> that sounds pretty horrid.
Unfortunately, that's how the KDE repo is organized. (I tried arguing
against this when they were going to do the original import, but I
lost the argument.) And git-svnimport doesn't appear to have any sort
of method for splitting a gigantic svn repo into several smaller git
repos.
> > First issue I ran into: On a machine with 4GB of RAM, when I tried to
> > do a full import, git-svnimport died after 309906 revisions, saying
> > that it couldn't fork.
> >
> > Checking `top` and `ps` revealed that there were no git-svnimport
> > processes doing anything, but all of my 4G of RAM was still marked as
> > used by the kernel. I had to do sysctl -w vm.drop_caches=3 to get it
> > to free all the RAM that the svn import had used up.
>
> I think that was just all cached, and all ok. The reason you didn't see
> any git-svnimport was that it had died off already, and all your memory
> was just caches. You could just have left it alone, and the kernel would
> have started re-using the memory for other things even without any
> "drop_caches".
>
> But what you did there didn't make anything worse, it was just likely had
> no real impact.
I got the tip about drop_caches from davej. Normally, when a process
taking up a huge amount of memory exits, it shows a bunch of free
memory in `top` and friends. I was a little bit surprised when that
didn't happen this time.
> However, it does sound like git-svnimport probably acts like git-cvsimport
> used to, and just keeps too much in memory - so it's never going to act
> really nicely..
>
> It also looks like git-svnimport never repacks the repo, which is
> absolutely horrible for performance on all levels. The CVS importer
> repacks every one thousand commits or something like that.
Yeah. I haven't bothered hacking git-svnimport yet - but it looks like
having it automatically repack every thousand revisions or so would
probably be a pretty big win.
> > Now, after that, I tried doing `git-repack -a` because I wanted to see
> > how small the packed archive would be (before trying to continue
> > importing the rest of the revisions. There are at least another 100k
> > revisions that I should be able to import, eventually.)
>
> I suspect you'd have been better off just re-starting, and using something
> like
>
> while :
> do
> git svnimport -l 1000 <...>
> .. figure out some way to decide if it's all done ..
> git repack -d
> done
>
> which would make svnimport act a bit more sanely, and repack
> incrementally. That should make both the import much faster, _and_ avoid
> any insane big repack at the end (well, you'd still want to do a "git
> repack -a -d" at the end to turn the many smaller packs into a bigger one,
> but it would be nicer).
>
> However, I don't know what the proper magic is for svnimport to do that
> sane "do it in chunks and tell when you're all done". Or even better - to
> just make it repack properly and not keep everything in memory.
You can pass limits to svnimport to give it a revision to start at and
another one to end at, so that wouldn't be too bad - I was thinking
about working around it like that (so that i don't have to go poking
around in the Perl code behind the svn importer).
By default, if I had, say, one pack with the first 1000 revisions, and
I imported another 1000, running 'git-repack' on its own would leave
the first pack alone and create a new pack with just the second 1000
revisions, right?
> > The repack finished after about nine hours, but when I try to do a
> > git-verify-pack on it, it dies with this error message:
> >
> > error: Packfile
> > .git/objects/pack/pack-540263fe66ab9398cc796f000d52531a5c6f3df3.pack
> > SHA1 mismatch with itself
>
> That sounds suspiciously like the bug we had in out POWER sha1
> implementation that would generate the wrong SHA1 for any pack-file that
> was over 512MB in size, due to an overflow in 32 bits (SHA1 does some
> counting in _bits_, so 512MB is 4G _bits_),
>
> Now, I assume you're not on POWER (and we fixed that bug anyway - and I
> think long before 1.4.1 too), but I could easily imagine the same bug in
> some other SHA1 implementation (or perhaps _another_ overflow at the 1GB
> or 2GB mark..). I assume that the pack-file you had was something horrid..
>
> I hope this is with a 64-bit kernel and a 64-bit user space? That should
> limit _some_ of the issues. But I would still not be surprised if your
> SHA1 libraries had some 32-bit ("unsigned int") or 31-bit ("int") limits
> in them somewhere - very few people do SHA1's over huge areas, and even
> when you do SHA1 on something like a DVD image (which is easily over any
> 4GB limit), that tends to be done as many smaller calls to the SHA1
> library routines.
This is on a dual-CPU dual-core Opteron, running the AMD64 variant of
Ubuntu's Edgy release (64-bit kernel, 64-bit native userland). The
pack-file was around 2.3GB.
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Andreas Ericsson @ 2007-01-04 15:21 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Marco Costalba, Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <8c5c35580701030314t69b6a7dbhf9cb99de4567b93e@mail.gmail.com>
Lars Hjemli wrote:
> On 1/3/07, Marco Costalba <mcostalba@gmail.com> wrote:
>> On 1/3/07, Lars Hjemli <hjemli@gmail.com> wrote:
>> > On 1/3/07, Marco Costalba <mcostalba@gmail.com> wrote:
>> > > - one blank line
>> > > - zero or one line with log title
>> > > - zero or more lines with log message
>> > > - a terminating '\0'
>> >
>> > I think the should be:
>> > -zero or more blank lines
>>
>> Isn't it zero or _one_ blank line? Why more then one? would be it
>> useful? surely is slower to parse.
>
> My point is just that the log message is unformatted. There is nothing
> stopping you from
> adding blank lines at the start of the message.
>
> But then I tested it, and it seems as 'git-commit' strips off any
> leading blank lines (but git-commit-tree does not). So expecting one
> blank _might_ be good enough.
>
Other scm's from which we can import repositories have no such
mechanisms though. It would be nice to have this functionality in
rev-list. I'm looking into it at the moment.
>
>>
>> > -zero or more blank lines
>>
>> Why? this is necessary only to disambiguate muti (non blank) lines
>> titles, but as Junio pointed out distinction between log title and log
>> message is only in the Porcelain, not encoded in git. So the Porcalain
>> is going to show _one_line title if any an the remaining stuff in the
>> log message.
>
> Well, if the porcelain chooses to do so, it probably is ok. But I
> think the parsing/presentation of the log title/message would be more
> correct/better formatted if the parser is more "adaptive" to the
> content.
>
I disagree. If the title spans over more than one line, it's most likely
because it's too long to fit in one, in which case it won't look good
(or even be viewable in qgit / gitk) when printed anyways.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Andreas Ericsson @ 2007-01-04 15:18 UTC (permalink / raw)
To: Marco Costalba; +Cc: Lars Hjemli, Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <e5bfff550701030235g6f26044h8dd73e8abe1ec9e3@mail.gmail.com>
Marco Costalba wrote:
> On 1/3/07, Lars Hjemli <hjemli@gmail.com> wrote:
>> On 1/3/07, Marco Costalba <mcostalba@gmail.com> wrote:
>> > - one blank line
>> > - zero or one line with log title
>> > - zero or more lines with log message
>> > - a terminating '\0'
>>
>> I think the should be:
>> -zero or more blank lines
>
> Isn't it zero or _one_ blank line? Why more then one? would be it
> useful? surely is slower to parse.
>
I've imported a repository from CVS to git (the nagiosplugin repo),
where one author consistently put an empty line before the "commit
subject". I'm fairly certain this is done by the tool he uses (some GUI
thing, no doubt).
I'm currently looking into stripping optional empty lines appearing
postheaders-prebody from rev-list output, as it completely fudges qgit
and gitk viewing alike. Good thing the author in question only does
translations and no code work, or I'd be screaming with frustration
trying to figure out which commit does what. Mind you, CVS's lack of
forensic tools doesn't exactly inspire the clear and concise commit
messages we see in git, but still...
>> -zero or more non-blank lines with log title
>
> multi lines titles are allowed? never saw one of them.
>
They aren't disallowed. The log message part only by convention consists
of a title line followed by a blank and then the message body. It's
entirely possible to just start writing the message straight off, or put
any number of blank lines wherever.
>> -zero or more blank lines
>
> Why? this is necessary only to disambiguate muti (non blank) lines
> titles, but as Junio pointed out distinction between log title and log
> message is only in the Porcelain, not encoded in git. So the Porcalain
> is going to show _one_line title if any an the remaining stuff in the
> log message.
>
Sensible. There's no (reliable) way of knowing if the first line with
text on is actually a title or just the start of a 25-line sentence, or
even the signoff line, or completely empty.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 5/5] git-add: add ignored files when asked explicitly.
From: Andreas Ericsson @ 2007-01-04 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vslf3khsc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Mon, 25 Dec 2006, Junio C Hamano wrote:
>>
>>> $ git add foo.o
>>> $ git add '*.o'
>> Most people do
>>
>> $ git add *.o
>>
>> instead, where bash expands the expression. Maybe this new behaviour
>> should be hidden between a "-f" option?
>
> When would anybody do "git add *.o"?
>
Make that "git add *.c" then, in a directory normally containing a lot
of generated C-files.
>
> An alternative is to use the mechanism I added here to _detect_
> the attempt to add an ignored file with explicitly spelled out
> pathspec, and issue an info message that says something like:
>
> Path 'xyzzy/filfre.o' is not being ignored by one of
> your .gitignore files. If you really want to add it,
> please add this entry to .gitignore file:
>
> !/xyzzy/filfre.o
>
Sounds very sensible to me, although I assume you meant "path
xyzzy/filfre.o is being ignored" (ie, "is not being ignored" (sic) was a
typo).
> One advantage of this is that it would help guiding the user in
> the right direction, giving a reusable piece of knowledge,
> without changing the behaviour of the command (what is refused
> is refused). But I can already see people's complaints: if the
> tool knows how to fix that situation why forces the user to do
> so?
>
> Although the reason why the alternative does not do so is "The
> user earlier said *.o files are uninteresting but came back with
> a conflicting request to add xyzzy/filfre.o, which could be a
> mistake. We ask for a confirmation", which is very sensible,
Very sensible indeed. If you tell a cabdriver "go-left-go-right" (very
fast) he'll (hopefully) stop and ask you where you really wanted to go.
> another alternative would be to add the path anyway and issue an
> warning, like this:
>
> $ ls xyzzy
> filfre.c filfre.o
> $ git add xyzzy/filfre.?
> added ignored path xyzzy/filfre.o
>
I like the "you did something weird. Education served" option better.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-reset --hard: tell the user what the HEAD was reset to
From: Johannes Schindelin @ 2007-01-04 12:59 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Han-Wen Nienhuys, git
In-Reply-To: <459BACE1.5020406@shadowen.org>
Hi,
On Wed, 3 Jan 2007, Andy Whitcroft wrote:
> I think we need to delimit the name better, probabally we need to quote
> it. Perhaps something like:
>
> HEAD is now at ac9c110: "git-fetch: remove .keep file at the end".
Fine. But this is "git log --pretty=oneline --abbrev-commit". I don't know
how many things break if you change _that_.
Alternatively, you could pipe that into a sed command adding the colon and
the quotes.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Speedup recursive by flushing index only once for all entries
From: Alex Riesen @ 2007-01-04 12:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0701041327490.22628@wbgn013.biozentrum.uni-wuerzburg.de>
On 1/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > Johannes, I remember suggesting to do index flush for all
> > entries instead for every entry. It is already quite time ago,
> > but ... was there any reasons for not doing this?
>
> I wanted to be on the safe side, and eventually look through the code
> again for possible problems.
>
> I think what you did is safe, since you moved the call from
> process_entry() to its sole caller, merge_trees().
Me too, just wondered why didn't we do this back then.
Anyway, my "monster-merge" and the builtin tests pass with
no visible problems.
> However, I was wondering if the index has to be written at all.
> I expect the written index (except the last one, of course) to have no
> user...
Good question...
^ permalink raw reply
* Re: [PATCH] Speedup recursive by flushing index only once for all entries
From: Johannes Schindelin @ 2007-01-04 12:33 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <81b0412b0701040247k47e398e6q34dd5233bb5706f6@mail.gmail.com>
Hi,
On Thu, 4 Jan 2007, Alex Riesen wrote:
> Johannes, I remember suggesting to do index flush for all
> entries instead for every entry. It is already quite time ago,
> but ... was there any reasons for not doing this?
I wanted to be on the safe side, and eventually look through the code
again for possible problems.
I think what you did is safe, since you moved the call from
process_entry() to its sole caller, merge_trees().
However, I was wondering if the index has to be written at all.
I expect the written index (except the last one, of course) to have no
user...
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Speedup recursive by flushing index only once for all entries
From: Alex Riesen @ 2007-01-04 10:47 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Schindelin, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
Merge-recursive is very slow in repos with lots of files,
especially if lots of them change absolutely identically.
Updating index once after all of them changes speedups
merge quite noticable.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Johannes, I remember suggesting to do index flush for all
entries instead for every entry. It is already quite time ago,
but ... was there any reasons for not doing this?
The patch speeds it up a lot and no wonder: index is 6Mb
here, and this is cygwin.
merge-recursive.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
[-- Attachment #2: 0001-Speedup-recursive-by-flushing-index-only-once-for-all-entries.txt --]
[-- Type: text/plain, Size: 972 bytes --]
From d0e4d791cef8b307b32954a8b80c4aabd41755a9 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 4 Jan 2007 11:22:47 +0100
Subject: Speedup recursive by flushing index only once for all entries
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
merge-recursive.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index bac16f5..4d3a2ce 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1083,9 +1083,6 @@ static int process_entry(const char *path, struct stage_data *entry,
} else
die("Fatal merge failure, shouldn't happen.");
- if (cache_dirty)
- flush_cache();
-
return clean_merge;
}
@@ -1133,6 +1130,8 @@ static int merge_trees(struct tree *head,
if (!process_entry(path, e, branch1, branch2))
clean = 0;
}
+ if (cache_dirty)
+ flush_cache();
path_list_clear(re_merge, 0);
path_list_clear(re_head, 0);
--
1.5.0.rc0.g8bc4b-dirty
^ permalink raw reply related
* Re: [0/2 PATCH] FastCGI and nginx support for gitweb
From: Eric Wong @ 2007-01-04 9:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <enif9a$9ve$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Eric Wong wrote:
>
> > I was looking at nginx for another project and got sidetracked
> > into writing instaweb support for it; so I ended up writing a
> > simple FCGI wrapper for gitweb as well.
>
> FCGI, not CGI::Fast?
CGI::Fast is just a wrapper on top of FCGI but gives access to functions
in the CGI module. We already use the CGI module explicitly in gitweb;
and I didn't want to make deeper changes in gitweb nor introduce extra
dependencies.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] rerere: Fix removal of already resolved path.
From: Johannes Schindelin @ 2007-01-04 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkkjmcwr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 4 Jan 2007, Junio C Hamano wrote:
> There was an obvious thinko in memmove() to remove an entry that
> was resolved from the in-core data structure.
I keep making the same errors, don't I?
Sorry,
Dscho
^ permalink raw reply
* Re: [0/2 PATCH] FastCGI and nginx support for gitweb
From: Jakub Narebski @ 2007-01-04 8:56 UTC (permalink / raw)
To: git
In-Reply-To: <11678969111362-git-send-email-normalperson@yhbt.net>
Eric Wong wrote:
> I was looking at nginx for another project and got sidetracked
> into writing instaweb support for it; so I ended up writing a
> simple FCGI wrapper for gitweb as well.
FCGI, not CGI::Fast?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] rerere: Fix removal of already resolved path.
From: Junio C Hamano @ 2007-01-04 8:09 UTC (permalink / raw)
To: git
There was an obvious thinko in memmove() to remove an entry that
was resolved from the in-core data structure.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* If you were seeing mysterious "Cannot open" messages after
"git merge", "git rebase", and "git am" runs, this should fix
them.
builtin-rerere.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 7442498..079c0bd 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -350,11 +350,10 @@ static int do_plain_rerere(struct path_list *rr, int fd)
fprintf(stderr, "Recorded resolution for '%s'.\n", path);
copy_file(path, rr_path(name, "postimage"));
tail_optimization:
- if (i < rr->nr - 1) {
+ if (i < rr->nr - 1)
memmove(rr->items + i,
- rr->items + i + 1,
- rr->nr - i - 1);
- }
+ rr->items + i + 1,
+ sizeof(rr->items[0]) * (rr->nr - i - 1));
rr->nr--;
i--;
}
^ permalink raw reply related
* [PATCH 2/2] instaweb: add support for nginx + FastCGI
From: Eric Wong @ 2007-01-04 7:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11678969111362-git-send-email-normalperson@yhbt.net>
nginx does not support regular CGI
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Makefile | 5 +++-
git-instaweb.sh | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 3e94def..893c7f2 100644
--- a/Makefile
+++ b/Makefile
@@ -690,7 +690,8 @@ gitweb/gitweb.fcgi: gitweb/gitweb-fcgi.perl
chmod +x $@+
mv $@+ $@
-git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
+git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css \
+ gitweb/gitweb.fcgi
rm -f $@ $@+
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
@@ -699,6 +700,8 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
+ -e '/@@GITWEB_FCGI@@/r gitweb/gitweb.fcgi' \
+ -e '/@@GITWEB_FCGI@@/d' \
$@.sh > $@+
chmod +x $@+
mv $@+ $@
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 08362f4..dcd04fd 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -20,7 +20,7 @@ httpd="`git repo-config --get instaweb.httpd`"
browser="`git repo-config --get instaweb.browser`"
port=`git repo-config --get instaweb.port`
module_path="`git repo-config --get instaweb.modulepath`"
-
+fcgi_pid_file="$fqgitdir"/gitweb/fcgi.pid
conf=$GIT_DIR/gitweb/httpd.conf
# Defaults:
@@ -34,7 +34,22 @@ test -z "$browser" && browser='firefox'
# any untaken local port will do...
test -z "$port" && port=1234
+use_fcgi () {
+ case "$httpd" in
+ *nginx*)
+ return 0
+ ;;
+ esac
+ return -1
+}
+
start_httpd () {
+ if use_fcgi; then
+ "$fqgitdir"/gitweb/gitweb.fcgi \
+ --fcgi-socket="$fcgi_sock" \
+ --cgi-bin="$fqgitdir/gitweb/gitweb.cgi" &
+ echo $! > "$fcgi_pid_file"
+ fi
httpd_only="`echo $httpd | cut -f1 -d' '`"
if test "`expr index $httpd_only /`" -eq '1' || \
which $httpd_only >/dev/null
@@ -61,6 +76,9 @@ start_httpd () {
}
stop_httpd () {
+ if use_fcgi; then
+ test -f "$fcgi_pid_file" && kill `cat "$fcgi_pid_file"`
+ fi
test -f "$fqgitdir/pid" && kill `cat "$fqgitdir/pid"`
}
@@ -138,7 +156,48 @@ mkdir -p "$GIT_DIR/gitweb/tmp"
GIT_EXEC_PATH="`git --exec-path`"
GIT_DIR="$fqgitdir"
export GIT_EXEC_PATH GIT_DIR
+fcgi_sock="$fqgitdir/gitweb/fcgi.sock"
+nginx_conf () {
+ mkdir -p "$fqgitdir"/gitweb/logs
+ cat > "$conf" <<EOF
+pid $fqgitdir/pid;
+error_log $fqgitdir/gitweb/logs/error.log;
+events {
+ worker_connections 1024;
+}
+http {
+ access_log $fqgitdir/gitweb/logs/access.log;
+ types {
+ text/css css;
+ }
+ server {
+ listen $port;
+ root $fqgitdir/gitweb;
+ location = / {
+ fastcgi_pass unix:$fcgi_sock;
+ fastcgi_index gitweb.fcgi;
+ fastcgi_param QUERY_STRING \$query_string;
+ fastcgi_param REQUEST_METHOD \$request_method;
+ fastcgi_param CONTENT_TYPE \$content_type;
+ fastcgi_param CONTENT_LENGTH \$content_length;
+ fastcgi_param SCRIPT_NAME \$fastcgi_script_name;
+ fastcgi_param REQUEST_URI \$request_uri;
+ fastcgi_param DOCUMENT_URI \$document_uri;
+ fastcgi_param DOCUMENT_ROOT \$document_root;
+ fastcgi_param SERVER_PROTOCOL \$server_protocol;
+ fastcgi_param GATEWAY_INTERFACE CGI/1.1;
+ fastcgi_param SERVER_SOFTWARE nginx;
+ fastcgi_param REMOTE_ADDR \$remote_addr;
+ fastcgi_param REMOTE_PORT \$remote_port;
+ fastcgi_param SERVER_ADDR \$server_addr;
+ fastcgi_param SERVER_PORT \$server_port;
+ fastcgi_param SERVER_NAME \$server_name;
+ }
+ }
+}
+EOF
+}
lighttpd_conf () {
cat > "$conf" <<EOF
@@ -230,8 +289,16 @@ gitweb_css () {
EOFGITWEB
}
+gitweb_fcgi () {
+ cat > "$1" <<\EOFGITWEB
+@@GITWEB_FCGI@@
+EOFGITWEB
+ chmod +x "$1"
+}
+
gitweb_cgi $GIT_DIR/gitweb/gitweb.cgi
gitweb_css $GIT_DIR/gitweb/gitweb.css
+gitweb_fcgi $GIT_DIR/gitweb/gitweb.fcgi
case "$httpd" in
*lighttpd*)
@@ -240,6 +307,9 @@ case "$httpd" in
*apache2*)
apache2_conf
;;
+*nginx*)
+ nginx_conf
+ ;;
*)
echo "Unknown httpd specified: $httpd"
exit 1
--
1.5.0.rc0.gcafca-dirty
^ permalink raw reply related
* [PATCH 1/2] gitweb: add a simple wrapper for FCGI support
From: Eric Wong @ 2007-01-04 7:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11678969111362-git-send-email-normalperson@yhbt.net>
The FCGI wrapper is designed to be spawned from the
command-line, and can be backgrounded there. No
FCGI-specific spawners are necessary.
Since we re-eval gitweb.cgi on every request, I've
quieted warnings for redefined functions.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
.gitignore | 1 +
Makefile | 6 +++++
gitweb/gitweb-fcgi.perl | 51 +++++++++++++++++++++++++++++++++++++++++++++++
gitweb/gitweb.perl | 1 +
4 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 2904f12..700ac4f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -137,6 +137,7 @@ git-whatchanged
git-write-tree
git-core-*/?*
gitweb/gitweb.cgi
+gitweb/gitweb.fcgi
test-date
test-delta
test-dump-cache-tree
diff --git a/Makefile b/Makefile
index fa1a022..3e94def 100644
--- a/Makefile
+++ b/Makefile
@@ -684,6 +684,12 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
chmod +x $@+
mv $@+ $@
+gitweb/gitweb.fcgi: gitweb/gitweb-fcgi.perl
+ rm -f $@ $@+
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' $< >$@+
+ chmod +x $@+
+ mv $@+ $@
+
git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
rm -f $@ $@+
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
diff --git a/gitweb/gitweb-fcgi.perl b/gitweb/gitweb-fcgi.perl
new file mode 100644
index 0000000..2b7d5bf
--- /dev/null
+++ b/gitweb/gitweb-fcgi.perl
@@ -0,0 +1,51 @@
+#!/usr/bin/perl -w
+use strict;
+use FCGI;
+use CGI;
+use Getopt::Long qw/:config gnu_getopt no_ignore_case auto_abbrev/;
+
+sub usage {
+ print STDERR "$0 --fcgi-socket=(path|[host]:port) ",
+ "--cgi-bin=path\n";
+ exit 1;
+}
+
+my ($fcgi_sock, $cgi_bin);
+GetOptions('fcgi-socket|s=s' => \$fcgi_sock,
+ 'cgi-bin|c=s' => \$cgi_bin) or usage();
+
+usage() unless ($fcgi_sock && $cgi_bin);
+
+die "FastCGI socket: $fcgi_sock already exists!\n" if (-S $fcgi_sock);
+die "CGI executable: $cgi_bin does not exist!\n" if (!-f $cgi_bin);
+
+# gitweb will exit, make it throw an exception instead:
+no warnings qw/once/;
+*CORE::GLOBAL::exit = sub { die 'gitweb_exit' };
+use warnings;
+
+# FCGI will erase the current %ENV; so make sure we save this:
+my $gwcfg = $ENV{GITWEB_CONFIG};
+
+my $fcgi_req = FCGI::Request(\*STDIN, \*STDOUT, \*STDERR, \%ENV,
+ FCGI::OpenSocket($fcgi_sock, 128),
+ FCGI::FAIL_ACCEPT_ON_INTR);
+while ($fcgi_req->Accept >= 0) {
+ unless ($ENV{PATH_INFO}) {
+ # nginx currently fails to set PATH_INFO,
+ # so we'll do it ourselves
+ my $pi = $ENV{SCRIPT_NAME};
+ $pi =~ s!^/\+!!;
+ $ENV{PATH_INFO} = $pi;
+ }
+ # clear CGI query parameters set inside gitweb so we can reparse
+ # the %ENV fed to us
+ CGI::initialize_globals();
+ $ENV{GITWEB_CONFIG} = $gwcfg if defined $gwcfg;
+ do $cgi_bin;
+ delete $ENV{PATH_INFO};
+}
+
+END {
+ unlink $fcgi_sock if (defined $fcgi_sock && -S $fcgi_sock);
+}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2179054..4a9189b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -9,6 +9,7 @@
use strict;
use warnings;
+no warnings qw(redefine); # for FCGI
use CGI qw(:standard :escapeHTML -nosticky);
use CGI::Util qw(unescape);
use CGI::Carp qw(fatalsToBrowser);
--
1.5.0.rc0.gcafca-dirty
^ permalink raw reply related
* [0/2 PATCH] FastCGI and nginx support for gitweb
From: Eric Wong @ 2007-01-04 7:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I was looking at nginx for another project and got sidetracked
into writing instaweb support for it; so I ended up writing a
simple FCGI wrapper for gitweb as well.
---
.gitignore | 1 +
Makefile | 11 ++++++-
git-instaweb.sh | 72 ++++++++++++++++++++++++++++++++++++++++++++++-
gitweb/gitweb-fcgi.perl | 51 +++++++++++++++++++++++++++++++++
gitweb/gitweb.perl | 1 +
5 files changed, 134 insertions(+), 2 deletions(-)
--
Eric Wong
^ 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