* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-09 11:51 UTC (permalink / raw)
To: Martin Langhoff, Git Mailing List
Cc: Linus Torvalds, Jeff Garzik, H. Peter Anvin, Rogan Dawes,
Kernel Org Admin
In-Reply-To: <46a038f90612081756w1ab4609epcb4a2cbd9f4d8205@mail.gmail.com>
Martin Langhoff wrote:
> We can make gitweb to detect mod_perl and a few smarter things if it
> is running inside of it. In fact, we can (ab)use mod_perl and perl
> facilities a bit to do some serialization which will be a big win for
> some pages. What we need for that is to set a sensible the ETag and
> use some IPC to announce/check if other apache/modperl processes are
> preparing content for the same ETag. The first-process-to-announce a
> given ETag can then write it to a common temp directory (atomically -
> write to a temp-name and move to the expected name) while other
> processes wait, polling for the file. Once the file is in place the
> latecomers can just serve the content of the file and exit.
First, it would (and could) work only for serving gitweb over mod_perl.
I'm not sure if overhead with IPC and complications implementing are
worth it: this perhaps be better solved by caching engine.
But let us put aside for a while actual caching (writing HTML version
of the page to a common temp directory, and serving this static page
if possible), and talk a bit what gitweb can do with respect to
cache validation.
In addition to setting either Expires: header or Cache-Control: max-age
gitweb should also set Last-Modified: and ETag headers, and also
probably respond to If-Modified-Since: and If-None-Match: requests.
Would be worth implementing this?
> (I am calling the "state we are serving" identifier ETag because I
> think we should also set it as the ETag in the HTTP headers, so well
> be able to check the ETag of future requests for staleness - all we
> need is a ref lookup, and if the SHA1 matches, we are sorted). So
> having this 'unique request identifier' doubles up nicely...
For some pages ETag is natural; for other Last-Modified: would be more
natural.
> The ETag should probably be:
> - SHA1+displaytype+args for pages that display an object identified
> by SHA1
What uniquely identifies contents in "object" views ("commit", "tag",
"tree", "blob") is either h=SHA1, or hb=SHA1;f=FILENAME (with absence
of h=SHA1). If both h=SHA1 and hb=SHA1 is present, hb=SHA1 serves as
backlink. The "diff" views ("commitdiff", "blobdiff") are uniquely
identified by pair of object identifiers (pairs of SHA1, or pairs of
hb SHA1 + FILENAME).
Three of those views ("blob", "commitdiff", "blobdiff") have their
"plain" version; so ETag should include displaytype (action, 'a'
parameter).
The hb=SHA1;f=FILENAME indentifier can be converted at cost of one
call to git command (but which is a bit expensive as it recurses
trees), namely to git-ls-tree.
ETag can be simply args (query), if all h/hb/hbp parameters are SHA1.
Or ETag can be SHA1 of an object (or pair of SHA1 in the case of diff),
but this is little more costly to verify. Although we usually (always?)
convert hb=SHA1;f=FILENAME to h=SHA1 anyway when displaying/generating
page.
Usualy you can compare ETags base on URL alone.
> - refname+SHA!+displaytype+args for pages that display something
> identified by a ref
For objects views we can simply convert refname to SHA1. I'm not sure if
it is worth it. In the cases when for view we have to calculate SHA1 of
object anyway, we can return (and validate) ETag with SHA1 as above.
- ETag and/or Last-Modified headers for "log" views: "log",
"shortlog" (is part of summary view), "history", "rss"/"atom" views.
On one hand all log views (at least now) are identified by their
parameters (action/view name, and filename in the case of history view)
and SHA1 of top commit. On the other hand it might be easier to use
Last-Modified with date of top commit... Verifying SHA1 based ETag
could add some overhead in the case of miss.
> - SHA1(names and sha1s of all refs) for the summary page
Wouldn't it be simplier to just set Last-Modified: header (and check
it?)
P.S. Can anyone post some benchmark comparing gitweb deployed under
mod_perl as compared to deployed as CGI script? Does kernel.org use
mod_perl, or CGI version of gitweb?
--
Jakub Narebski
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Marco Costalba @ 2006-12-09 12:15 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: Andreas Ericsson, Shawn Pearce, Git Mailing List
In-Reply-To: <f2b55d220612081210u6ec3e95ciec6665a6b5e6a827@mail.gmail.com>
On 12/8/06, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> There is a very handy solution to this problem called "tmpfs". It
> should already be mounted at /tmp. Put tmp.txt there and your problem
> will go away.
>
Thanks Michael,
It seems to work! patch pushed.
Marco
P.S: I've looked again to Shawn idea (and code) of linking qgit
against libgit.a but I found these two difficult points:
- traverse_commit_list(&revs, show_commit, show_object) is blocking,
i.e. the GUI will stop responding for few seconds while traversing the
list. This is easily and transparently solved by the OS scheduler if
an external process is used for git-rev-list. To solve this in qgit I
have two ways: 1) call QEventLoop() once in a while from inside
show_commit()/ show_object() to process pending events 2) Use a
separate thread (QThread class). The first idea is not nice, the
second opens a whole a new set of problems and it's a big amount of
not trivial new code to add.
- traverse_commit_list() having an internal state it's not
re-entrant. git-rev-list it's used to load main view data but also
file history in another tab, and the two calls _could_ be ran
concurrently. With external process I simply run two instances of
DataLoader class and consequently two external git-rev-list processes,
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-09 12:42 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <200612091251.16460.jnareb@gmail.com>
Jakub Narebski wrote:
> First, it would (and could) work only for serving gitweb over mod_perl.
> I'm not sure if overhead with IPC and complications implementing are
> worth it: this perhaps be better solved by caching engine.
It is. At least for kernel.org, the issue isn't that CGI is expensive,
its that I/O is expensive.
> In addition to setting either Expires: header or Cache-Control: max-age
> gitweb should also set Last-Modified: and ETag headers, and also
> probably respond to If-Modified-Since: and If-None-Match: requests.
>
> Would be worth implementing this?
IMO yes, since most major browsers, caches, and spiders support these
headers.
> For some pages ETag is natural; for other Last-Modified: would be more
> natural.
Yes, a good point to note.
> Usualy you can compare ETags base on URL alone.
Mostly true: you must also consider HTTP_ACCEPT
> Wouldn't it be simplier to just set Last-Modified: header (and check
> it?)
That would be a good start, and suffice for many cases. If the CGI can
simply stat(2) files rather than executing git-* programs, that would
increase efficiency quite a bit.
A core problem with cache hints via HTTP headers (last-modified, etc.)
is that you don't achieve caching across multiple clients, just across
repeated queries from the same client (or caching proxy).
At least for the RSS/Atom feeds and the git main page, it makes no sense
to regenerate that data repeatedly.
Internally, gitweb would need to do a stat() on key files, and return
pre-generated XML for the feeds if the stat() reveals no changes. Ditto
for the front page.
> P.S. Can anyone post some benchmark comparing gitweb deployed under
> mod_perl as compared to deployed as CGI script? Does kernel.org use
> mod_perl, or CGI version of gitweb?
CGI version of gitweb.
But again, mod_perl vs. CGI isn't the issue.
Jeff
^ permalink raw reply
* Re: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
From: Han-Wen Nienhuys @ 2006-12-09 13:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b7qi0b4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
> Eric Wong <normalperson@yhbt.net> writes:
>
>> Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
>>> git-sh-setup isn't a 'normal' binary, in that it should be called by
>>> bash only and not run in a subshell. Therefore, it should not be installed
>>> in a executable directory, but rather in $prefix/share/git-core/
>> This seems to break existing hooks, or at least old repositories can
>> be stuck using an old version of git-sh-setup in those hooks.
>
> Honestly speaking, I do not think this patch is worth it.
> People who care deeply enough should just use gitexecdir that is
> separate from bindir.
And how about coding the path of git-sh-setup (in <prefix>/bin/git-sh-setup)
in the shell scripts? This will ensure that the sh-setup is the one
from the right package, but still retain backward compatibility for
scripts.
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-09 13:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <457AAF31.2050002@garzik.org>
Jeff Garzik wrote:
> Jakub Narebski wrote:
>> In addition to setting either Expires: header or Cache-Control: max-age
>> gitweb should also set Last-Modified: and ETag headers, and also
>> probably respond to If-Modified-Since: and If-None-Match: requests.
>>
>> Would be worth implementing this?
>
> IMO yes, since most major browsers, caches, and spiders support these
> headers.
Sending Last-Modified: should be easy; sending ETag needs some consensus
on the contents: mainly about validation. Responding to If-Modified-Since:
and If-None-Match: should cut at least _some_ of the page generating time.
If ETag can be calculated on URL alone, then we can cut If-None-Match:
just at beginning of script.
>> For some pages ETag is natural; for other Last-Modified: would be more
>> natural.
>
> Yes, a good point to note.
>
>> Usualy you can compare ETags base on URL alone.
>
> Mostly true: you must also consider HTTP_ACCEPT
Well, yes, ETag is HTTP/1.1 header.
>> Wouldn't it be simplier to just set Last-Modified: header (and check
>> it?)
>
> That would be a good start, and suffice for many cases. If the CGI can
> simply stat(2) files rather than executing git-* programs, that would
> increase efficiency quite a bit.
As I said, I'm not talking (at least now) about saving generated HTML
output. This I think is better solved in caching engine like Squid can
be. Although even here some git specific can be of help: we can invalidate
cache on push, and we know that some results doesn't ever change (well,
with exception of changing output of gitweb).
> A core problem with cache hints via HTTP headers (last-modified, etc.)
> is that you don't achieve caching across multiple clients, just across
> repeated queries from the same client (or caching proxy).
>
> At least for the RSS/Atom feeds and the git main page, it makes no sense
> to regenerate that data repeatedly.
>
> Internally, gitweb would need to do a stat() on key files, and return
> pre-generated XML for the feeds if the stat() reveals no changes. Ditto
> for the front page.
I'm not sure if it is worth implementing in gitweb, or is it better left
to caching engine. With the projects list page and summary page there is
additional problem with relative dates, although this can be solved using
Jonas Fonseca idea of using absolute dates in the page and using ECMAScript
(JavaScript) to convert them to relative: on load, and perhaps on timer ;-)
What can be _easily_ done:
* Use post 1.4.4 gitweb, which uses git-for-each-ref to generate summary
page; this leads to around 3 times faster summary page.
* Perhaps using projects list file (which can be now generated by gitweb)
instead of scanning directories and stat()-ing for owner would help
with time to generate projects lis page
What can be quite easy incorporated into gitweb:
* For immutable pages set Expires: or Cache-Control: max-age (or both)
to infinity
* Calculate hash+action based ETag at least for those actions where it is
easy, and respond with 304 Not Modified as soon as it can.
This might require some code reorganization to not begin writing output
before calculating ETag and ETag comparison (If-Match, If-None-Match).
* Generate Last-Modified: for those views where it can be calculated,
and respond with 304 Not Modified as soon as it can.
What can be easily done using caching engine:
* Select top 10 of common queries, and cache them, invalidating cache on push
(depending on query: for example invalidate project list on push to any
project, invalidate RSS/Atom feed and summary pages only on push to specific
project) - can be done with git hooks.
--
Jakub Narebski
^ permalink raw reply
* Re: RFC PATCH: support for default remote in StGIT
From: Yann Dirson @ 2006-12-09 13:36 UTC (permalink / raw)
To: Pavel Roskin; +Cc: "Catalin Marinas catalin.marinas", git
In-Reply-To: <1165656205.2816.47.camel@portland.localdomain>
Hi Pavel,
This is quite related to the subject of the "Handling of branches in
stgit" thread I launched recently (Nov 30th).
On Sat, Dec 09, 2006 at 04:23:25AM -0500, Pavel Roskin wrote:
> It's very important for me to have default remote support in StGIT. I'm
> trying to track different Linux branches, and I don't want to remember
> what branch I'm on when I run "stg pull".
Right, that's the main problem with the current implementation.
> One approach is to leave the default remote selection completely to git.
> The downside is that StGIT prints the remote it's pulling from. Now
> StGIT will have to print common words that it's pulling something. Or
> maybe it shouldn't print anything?
It could just print a generic message and let GIT print out
the details.
> Also, git-pull doesn't allow to specify the refspec without the remote.
> This limitation seems artificial to me, but we have to pass this
> limitation to the StGIT users.
In which situtation do you need to pass a refspec ? I thought all
necessary refspecs should already be part of a remote's definition.
> The positive side if that StGIT is completely unaware of the word
> "origin", and any changes in git handling of the default remote will
> propagate to StGIT immediately.
Indeed.
> The other approach is to calculate the default remote in StGIT. This
> would allow StGIT to tell the user where it's pulling from.
Doing so would probably require to teach StGIT about every new way of
fetching a branch (we already have 3 ways, as outlined in my initial
mail). OTOH, it may be the only way to present the user with a
uniform way of working, independently of the way we update the parent
branch.
Indeed, we may just want to distinguish whether the parent branch is a
remote one or not. Then if it's a remote one, git-fetch already has
enough info to do its work updating the parent branch (whether using
.git/remotes or .git/branches). If it's not a remote branch, there's
just nothing to do at this step.
Then, we just have to "pop -a" and move the stack base, without
relying on "pull". That would also transparently give support for
branching off a non-forwarding branch (like git's "next" and "pu", or
like any stgit managed branch). Would anyone miss the "git-pull" call ?
Best regards,
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-09 14:43 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <200612091437.01183.jnareb@gmail.com>
Jakub Narebski wrote:
> Sending Last-Modified: should be easy; sending ETag needs some consensus
> on the contents: mainly about validation. Responding to If-Modified-Since:
> and If-None-Match: should cut at least _some_ of the page generating time.
Definitely.
> As I said, I'm not talking (at least now) about saving generated HTML
> output. This I think is better solved in caching engine like Squid can
> be. Although even here some git specific can be of help: we can invalidate
> cache on push, and we know that some results doesn't ever change (well,
> with exception of changing output of gitweb).
It depends on how creatively you think ;-)
Consider generating static HTML files on each push, via a hook, for many
of the toplevel files. The static HTML would then link to the CGI for
further dynamic querying of the git database.
> What can be _easily_ done:
> * Use post 1.4.4 gitweb, which uses git-for-each-ref to generate summary
> page; this leads to around 3 times faster summary page.
This re-opens the question mentioned earlier, is Kay (or anyone?) still
actively maintaining gitweb on k.org?
> * Perhaps using projects list file (which can be now generated by gitweb)
> instead of scanning directories and stat()-ing for owner would help
> with time to generate projects lis page
This could be statically generated by a robot. I think everybody would
shrink in horror if a human needed to maintain such a file.
> What can be quite easy incorporated into gitweb:
> * For immutable pages set Expires: or Cache-Control: max-age (or both)
> to infinity
nice!
> * Generate Last-Modified: for those views where it can be calculated,
> and respond with 304 Not Modified as soon as it can.
agreed
> What can be easily done using caching engine:
> * Select top 10 of common queries, and cache them, invalidating cache on push
> (depending on query: for example invalidate project list on push to any
> project, invalidate RSS/Atom feed and summary pages only on push to specific
> project) - can be done with git hooks.
Or simply generate regular filesystem files into the webspace, as
triggered by a hook. Let the standard filesystem mirroring/caching work
its magic.
Jeff
^ permalink raw reply
* Easy shell question: how to make a script killing all his childs when killed?
From: Marco Costalba @ 2006-12-09 15:16 UTC (permalink / raw)
To: Git Mailing List
Ok. I am really bad at scripting, so perhaps my question is very silly, but...
I create and run a script with the content:
git rev-list --header --boundary --parents --topo-order 2229ff5c7c >
/tmp/qgit_135902672.txt
Then I kill the script while it's running, but his child
(git-rev-list) continues to run in background and I would like to stop
it either.
So how can I write the script to be sure that when stopped, it will
kill all his childern?
Thanks
Marco
P.S: I have no way to exec the script in fancy ways, I can just start
^ permalink raw reply
* Re: [PATCH] Add branch.*.merge warning and documentation update
From: Santi Béjar @ 2006-12-09 16:14 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, git
In-Reply-To: <200612090228.26722.Josef.Weidendorfer@gmx.de>
On 12/9/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> This patch clarifies the meaning of the branch.*.merge option.
> Previously, if branch.*.merge was specified but did not match any
> ref, the message "No changes." was not really helpful regarding
> the misconfiguration. This patch adds a warning for this.
>
> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Acked-by: Santi Béjar <sbejar@gmail.com>
And thanks for the patch.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-09 16:26 UTC (permalink / raw)
To: Martin Langhoff
Cc: Jakub Narebski, Rogan Dawes, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <46a038f90612082134x38be9c8dgca6fe60c087bf100@mail.gmail.com>
Martin Langhoff wrote:
> On 12/9/06, H. Peter Anvin <hpa@zytor.com> wrote:
>> Martin Langhoff wrote:
>> > I posted separately about those. And I've been mulling about whether
>> > the thundering herd is really such a big problem that we need to
>> > address it head-on.
>>
>> Uhm... yes it is.
>
> Got some more info, discussion points or links to stuff I should read
> to appreciate why that is? I am trying to articulate why I consider it
> is not a high-payoff task, as well as describing how to tackle it.
>
> To recap, the reasons it is not high payoff is that:
>
> - the main benefit comes from being cacheable and able to revalidate
> the cache cheaply (with the ETags-based strategy discussed above)
> - highly distributed caches/proxies means we'll seldom see a true
> cold cache situation
> - we have a huge set of URLs which are seldom hit, and will never see
> a thundering anything
> - we have a tiny set of very popular URLs that are the key target for
> the thundering herd - (projects page, summary page, shortlog, fulllog)
> - but those are in the clear as soon as the caches are populated
>
> Why do we have to take it head-on? :-)
>
Because the primary failure scenario is timeout on the common queries
due to excess parallel invocations under high I/O load resulting in
catastrophic failure.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-09 17:02 UTC (permalink / raw)
To: Jeff Garzik
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <457ACBA1.4090007@garzik.org>
Jeff Garzik wrote:
> Jakub Narebski wrote:
>> As I said, I'm not talking (at least now) about saving generated HTML
>> output. This I think is better solved in caching engine like Squid can
>> be. Although even here some git specific can be of help: we can invalidate
>> cache on push, and we know that some results doesn't ever change (well,
>> with exception of changing output of gitweb).
>
> It depends on how creatively you think ;-)
>
> Consider generating static HTML files on each push, via a hook, for many
> of the toplevel files. The static HTML would then link to the CGI for
> further dynamic querying of the git database.
You mean that the links in this pre-generated HTML would be to CGI
pages?
>> What can be _easily_ done:
>> * Use post 1.4.4 gitweb, which uses git-for-each-ref to generate summary
>> page; this leads to around 3 times faster summary page.
>
> This re-opens the question mentioned earlier, is Kay (or anyone?) still
> actively maintaining gitweb on k.org?
By the way, thanks to Martin Waitz it is much easier to install gitweb.
I for example use the following script to test changes I have made to gitweb:
-- >8 --
#!/bin/bash
BINDIR="/home/local/git"
function make_gitweb()
{
pushd "/home/jnareb/git/"
make GITWEB_PROJECTROOT="/home/local/scm" \
GITWEB_CSS="/gitweb/gitweb.css" \
GITWEB_LOGO="/gitweb/git-logo.png" \
GITWEB_FAVICON="/gitweb/git-favicon.png" \
bindir=$BINDIR \
gitweb/gitweb.cgi
popd
}
function copy_gitweb()
{
cp -fv /home/jnareb/git/gitweb/gitweb.{cgi,css} /home/local/gitweb/
}
make_gitweb
copy_gitweb
# end of gitweb-update.sh
-- >8 --
>> * Perhaps using projects list file (which can be now generated by gitweb)
>> instead of scanning directories and stat()-ing for owner would help
>> with time to generate projects lis page
>
> This could be statically generated by a robot. I think everybody would
> shrink in horror if a human needed to maintain such a file.
Gitweb can generate this file. The problem is that one would have to
temporary turn off using index file. This can be done by having the
following gitweb_list_projects.perl file:
-- >8 --
#!/usr/bin/perl
$projects_list = "";
-- >8 --
then use the following invocation to generate project index file:
$ GATEWAY_INTERFACE="CGI/1.1" HTTP_ACCEPT="*/*" REQUEST_METHOD="GET" \
GITWEB_CONFIG=gitweb_list_projects.perl QUERY_STRING="a=project_index" \
gitweb.cgi
--
Jakub Narebski
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-09 17:27 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <200612091802.12810.jnareb@gmail.com>
Jakub Narebski wrote:
> Jeff Garzik wrote:
>> Jakub Narebski wrote:
>
>>> As I said, I'm not talking (at least now) about saving generated HTML
>>> output. This I think is better solved in caching engine like Squid can
>>> be. Although even here some git specific can be of help: we can invalidate
>>> cache on push, and we know that some results doesn't ever change (well,
>>> with exception of changing output of gitweb).
>> It depends on how creatively you think ;-)
>>
>> Consider generating static HTML files on each push, via a hook, for many
>> of the toplevel files. The static HTML would then link to the CGI for
>> further dynamic querying of the git database.
>
> You mean that the links in this pre-generated HTML would be to CGI
> pages?
Yes, they must be. Otherwise, the gitweb interface changes.
You don't want to pre-generate HTML for every possible git query, that
would cause an explosion of data.
Both the HTML generator and CGI would need to know which pages were
pre-generated and which are not.
Jeff
^ permalink raw reply
* Re: doc bug?
From: Jonas Fonseca @ 2006-12-09 17:30 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <elc64k$t4i$1@sea.gmane.org>
On 12/8/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> Hi,
Hello,
> while messing with GIT's build system, I got
>
> **
> asciidoc -b docbook -d manpage -f ../Documentation/asciidoc.conf ../Documentation/git-tools.txt
> ERROR: git-tools.txt: line 2: malformed manpage title
> ERROR: git-tools.txt: line 6: first section must be named NAME
> ERROR: git-tools.txt: line 9: malformed NAME section body
> FAILED: /home/lilydev/vc/git/Documentation/git-tools.txt: line 9: unexpected error:
> [traceback]
> **
>
> is this a new problem? I'm on FC6, with asciidoc 7.0.2
The git-tools.txt document is not intended to be a man page
(there is no git-tools command) so it cannot be converted into
a man page. You should be able to make a HTML document
out of it, although the AsciiDoc formatting is not "optimal".
--
^ permalink raw reply
* Re: Easy shell question: how to make a script killing all his childs when killed?
From: Alex Riesen @ 2006-12-09 17:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550612090716p215167b9r2277b09c09b18894@mail.gmail.com>
Marco Costalba, Sat, Dec 09, 2006 16:16:32 +0100:
> So how can I write the script to be sure that when stopped, it will
> kill all his childern?
Strictly speaking: you can't. Anything you'd try will either be not
portable or involve quiet complex dependencies (like perl).
Are you sure you can't control each process independently?
Speaking not so strictly, you can use a script engine which supports
either signal handling or exit notification (i.e. sh has traps and
perl has %SIG and END{}). It's unsafe, ugly and not quiet portable to
that other operating system, but it often works and is (ab)used.
> P.S: I have no way to exec the script in fancy ways, I can just start
> it and get is PID.
Which is "fancy" enough. What do you mean "start"? Starting a new
process usually and notably involves forking and execing (even if the
first thing to exec will be your shell).
^ permalink raw reply
* Re: Easy shell question: how to make a script killing all his childs when killed?
From: Marco Costalba @ 2006-12-09 17:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20061209173703.GA12373@steel.home>
On 12/9/06, Alex Riesen <fork0@t-online.de> wrote:
> Marco Costalba, Sat, Dec 09, 2006 16:16:32 +0100:
>
> > P.S: I have no way to exec the script in fancy ways, I can just start
> > it and get is PID.
>
> Which is "fancy" enough. What do you mean "start"? Starting a new
> process usually and notably involves forking and execing (even if the
> first thing to exec will be your shell).
>
>
By 'start' I mean it is done inside Qt QProcess class back box ;-)
Anyway I have written an homegrown 'wanna be hacker' launching script:
git rev-list --header --boundary --parents --topo-order HEAD >
/tmp/qgit_136224752.txt &
echo $!
wait
With this I can get the pid of git-rev-list from my QProcess interface
so to be able to kill it when needed with another command ('kill'
BTW).
I have googled around and it seems that 'echo $!' and 'wait' _should_
be portable among many shell, please correct me if'm wrong or if the
approach is failing (I already know it's ugly ;-) )
^ permalink raw reply
* Re: doc bug?
From: Han-Wen Nienhuys @ 2006-12-09 18:04 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30612090930o7b856223ub87746181f958b7c@mail.gmail.com>
Jonas Fonseca escreveu:
>> is this a new problem? I'm on FC6, with asciidoc 7.0.2
>
> The git-tools.txt document is not intended to be a man page
So why does the doc try make one for it? This is a bug, no?
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Linus Torvalds @ 2006-12-09 18:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jakub Narebski, Martin Langhoff, Git Mailing List, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <457AAF31.2050002@garzik.org>
On Sat, 9 Dec 2006, Jeff Garzik wrote:
>
> It is. At least for kernel.org, the issue isn't that CGI is expensive, its
> that I/O is expensive.
Note that if we had a new gitweb, we could also used the packed refs.
Those help CPU usage, but they actually help IO patterns more, exactly
because they avoid all the seeking around in the filesystem.
So with packed refs, there's no need to go from directory lookup to inode
lookup to data lookup to object lookup for *each* ref - you can do the
"packed-refs" lookup _once_ (which obviously does the dir->inode->data),
and you don't need to do the object lookup at all.
Of course, gitweb will then end up doing the object lookup anyway (because
of getting the dates etc for refs), but if you have packed-refs and a
reasonably packed repository, that should still really cut down on IO in a
big way.
So there's probably tons of room for making this more efficient: using a
newer gitweb, packing refs, using the cgi cache thing.. It sounds like
what it really needs is just somebody with the competence and time to be
willing to step up and maintain gitweb on kernel.org...
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-09 18:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff Garzik, Jakub Narebski, Martin Langhoff, Git Mailing List,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <Pine.LNX.4.64.0612090957360.3516@woody.osdl.org>
Linus Torvalds wrote:
>
> So there's probably tons of room for making this more efficient: using a
> newer gitweb, packing refs, using the cgi cache thing.. It sounds like
> what it really needs is just somebody with the competence and time to be
> willing to step up and maintain gitweb on kernel.org...
>
Indeed. We have a lot of projects on kernel.org which are like this:
not at all conceptually hard, but a huge time commitment for Doing It
Right[TM]. This is why I sometimes think that it would be a Good Thing
to get paid staff for kernel.org, although I was hoping to defer the
need for that until at least we have our 501(c)3 paperwork done, which
looks like mid-2007 at this point (assuming no further delays.)
^ permalink raw reply
* Re: doc bug?
From: Junio C Hamano @ 2006-12-09 18:42 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <elc64k$t4i$1@sea.gmane.org>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> while messing with GIT's build system, I got
>
> **
> asciidoc -b docbook -d manpage -f ../Documentation/asciidoc.conf ../Documentation/git-tools.txt
> ERROR: git-tools.txt: line 2: malformed manpage title
> ERROR: git-tools.txt: line 6: first section must be named NAME
> ERROR: git-tools.txt: line 9: malformed NAME section body
> FAILED: /home/lilydev/vc/git/Documentation/git-tools.txt: line 9: unexpected error:
That is interesting. git-tools is listed on ARTICLES which is
excluded from MAN1_TXT so the Makefile should not even try to
run the above commandline that says 'manpage'.
At least that is what our Makefile intends to do.
So that means you may have found a bug in our Makefile, or your
make (by the way I think we pretty much requires GNU make to
build git), or perhaps both.
But I do not see an obvious breakage in our Makefile in this
area...
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Nicolas Pitre @ 2006-12-09 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsatelvv.fsf@assigned-by-dhcp.cox.net>
On Fri, 8 Dec 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Frankly I feel unconfortable with this.
> >
> > 1) too many examples.
> >
> > Yes, examples are good, but somehow there is something in the current
> > text that make me feel they are not providing the clarification they
> > should. Dunno... I think I'd still push them after option list.
>
> Hmmm. I was merely trying to respond with recent requests on
> the list (might have been #git log) to make common usage
> examples more prominent. While I feel that following the UNIXy
> manpage tradition to push examples down is the right thing to
> do, you and I are not the primary audience of Porcelain
> manpages, so...
Sure, but sometimes too much is just as bad as not enough. And given
the amount of text in your version I feel the essence of the information
gets dilluted too much.
> > 2) explanation of how to resolve and commit a conflicting merge should
> > really be found in git-merge.txt not in git-commit.txt.
> >
> > It feels a bit awkward to suddenly start talking about git ls-files and
> > merge here.
>
> I agree that it looks a bit out of place; the primary reason I
> talked about the merge was to make it clear that a conflicted
> merge will still stage the changes for cleanly auto-resolved
> paths. In other words, it makes me feel uneasy that there is no
> mention of it in the list in your version that follows this
> sentence:
>
> > +... All changes
> > +to be committed must be explicitly identified using one of the following
> > +methods:
>
> It would make me happier if you had, at the end of enumeration,
> something like:
>
> Note that the contents of the paths that resolved
> cleanly by a conflicted merge are automatically staged
> for the next commit; you still need to explicitly
> identify what you want in the resulting commit using one
> of the above methods before concluding the merge.
But why couldn't this be in the git-merge man page instead? That is
precisely the sort of addition that makes me feel like we're trying to
say too much at the same time. When in the context of learning how
"commit" works, it is certainly not necessary to talk about how "merge"
works. That should really be mentioned in the "merging" documentation
(with a link to git-commit for more options on commit).
> Another reason I described the merge workflow is it would become
> much less clear why --only is useless in merge situation if the
> reader does not know that a conflicted merge stages the
> auto-resolved changes.
Sure, but the whole merge concept might still not make any sense at the
moment the user is learning about commit. In other words, the "commit"
documentation must not depend on the "merge" concept. It should rather
be the other way around, i.e. the "merge" documentation can easily
depend on the "commit" documentation.
Just like I carefully avoided talking about "commit -a" in the git-add
man page to avoid circular conceptual dependencies. But obviously the
git-commit man page must talk about the "add" concept.
This way you get a progressive knowledge base with git-add which pretty
much stands on its own, then you move to git-commit that depends on
git-add, then you move to merging and resolving conflicts that depend on
git-commit. And so without being distracted by concepts you don't need
to know just yet along the way.
^ permalink raw reply
* Re: [PATCH] rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am
From: Junio C Hamano @ 2006-12-09 20:08 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1165613397460-git-send-email-normalperson@yhbt.net>
I looked at your previous 5-patch series but will replace with
this updated 2-patch series.
The rerere command started its life as a mere helper for
Porcelains, but with 'status' and 'diff', you are making it
somewhat Porcelain-ish. I still have not decided myself, but I
think we probably would want to treat this as a Porcelain and
give a bit of usability to it, so what I've committed has two
changes from your version:
(1) 'diff' without @ARGV defaults to '-u';
(2) running rerere with unknown sub command die()s instead of
silently exiting with 0.
The difference between your previous 5-patch series and this
round raises an interesting issue.
You used to have a safety valve in git-commit to prevent users
from running it while rebase/am is in progress, which I imagine
would be a common mistake.
There are three commands in git suite that a user would use to
eventually make new commits, out of something other than what
was edited and prepared in the working tree, that can stop in
the middle.
(1) git-am is used to make new commits from e-mailed patches,
and stops in the middle when a patch does not apply.
"git-am --resolved/--skip" are the ways to continue.
(2) git-rebase is used to rewrite the history of a branch, and
stops in the middle when a patch does not apply or merge
conflicts. "git-rebase --continue/--skip/--abort" are
possible exits [*1*].
(3) git-pull/git-merge are used to make merge commits with
another branch, and stops in the middle when it conflicts.
Possible exits are "git commit" or "git reset".
Now, I am not going to propose to fix this inconsistency and
forbid use of "git commit" to resolve "git-merge" (instead, the
user would say "git-merge --resolved/--abort"). As the workflow
goes, these are very different operations and the user is often
well aware which workflow is in progress; having different
commands for different exit route is fine.
But in order to implement the safety valve like you did cleanly,
we should first have an enumeration of states (the above is a
subset --- there is the "base state" in which you are working
towards a commit based on HEAD, which is obviously concluded
with a "git commit", and "bisect in progress") and make it easy
for commands to communicate what state the working tree is in.
That would also help 'git-explain'.
[Footnote]
*1* Resuming rebase was much worse before Sean updated it with
commit 031321c6 to hide that it uses git-am as its backend,
which is purely its implementation detail.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Tilman Sauerbeck @ 2006-12-09 20:44 UTC (permalink / raw)
To: git
In-Reply-To: <7vwt54yb8d.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Junio C Hamano [2006-12-06 13:18]:
> * The 'maint' branch has produced a new release 1.4.4.2
Any reason why this wasn't announced?
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Jakub Narebski @ 2006-12-09 20:49 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612091442470.2630@xanadu.home>
Nicolas Pitre wrote:
> On Fri, 8 Dec 2006, Junio C Hamano wrote:
[...]
>> Another reason I described the merge workflow is it would become
>> much less clear why --only is useless in merge situation if the
>> reader does not know that a conflicted merge stages the
>> auto-resolved changes.
>
> Sure, but the whole merge concept might still not make any sense at the
> moment the user is learning about commit. In other words, the "commit"
> documentation must not depend on the "merge" concept. It should rather
> be the other way around, i.e. the "merge" documentation can easily
> depend on the "commit" documentation.
>
> Just like I carefully avoided talking about "commit -a" in the git-add
> man page to avoid circular conceptual dependencies. But obviously the
> git-commit man page must talk about the "add" concept.
>
> This way you get a progressive knowledge base with git-add which pretty
> much stands on its own, then you move to git-commit that depends on
> git-add, then you move to merging and resolving conflicts that depend on
> git-commit. And so without being distracted by concepts you don't need
> to know just yet along the way.
IMVHO for reference documentation (and manpages for commands are such
documentation) it is more important to be complete, than to be
self-contained and without circular conceptual dependencies. The latter
(and defining things before using it) is more important for things like
tutorial or quickstart.
If one is not doing merge then one can skip the talk about merges. If one
git-commit complains about using --only (because of merge), one would
rather search for information in git-commit(1), not git-merge(1) or
git-pull(1); well, the merge might be result of git-checkout -m.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-09 21:10 UTC (permalink / raw)
To: Tilman Sauerbeck; +Cc: git
In-Reply-To: <20061209204413.GA1482@code-monkey.de>
Tilman Sauerbeck <tilman@code-monkey.de> writes:
> Junio C Hamano [2006-12-06 13:18]:
>> * The 'maint' branch has produced a new release 1.4.4.2
>
> Any reason why this wasn't announced?
Well, vger seems to have ate the message.
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.4.2
From: Junio C Hamano @ 2006-12-09 21:13 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.4.2 has been available at
the usual places for a few days, but vger seems to have eaten
the message I sent out, so here is a resend:
http://www.kernel.org/pub/software/scm/git/
git-1.4.4.2.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.4.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.4.2.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.4.2-1.$arch.rpm (RPM)
This contains a handful fixes since 1.4.4.1; nothing earth
shattering.
----------------------------------------------------------------
Changes since v1.4.4.1 are as follows:
Alex Riesen (1):
git-blame: fix rev parameter handling.
Andy Parkins (2):
Increase length of function name buffer
Document git-repo-config --bool/--int options.
Eric Wong (4):
git-svn: error out from dcommit on a parent-less commit
git-svn: correctly handle revision 0 in SVN repositories
git-svn: preserve uncommitted changes after dcommit
git-svn: avoid fetching files twice in the same revision
Johannes Schindelin (1):
git-mv: search more precisely for source directory in index
Junio C Hamano (5):
git blame -C: fix output format tweaks when crossing file boundary.
tutorial: talk about user.name early and don't start with commit -a
receive-pack: do not insist on fast-forward outside refs/heads/
unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.
git-reset to remove "$GIT_DIR/MERGE_MSG"
René Scharfe (1):
archive-zip: don't use sizeof(struct ...)
^ 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