* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vbphaquwl.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 09:52:10PM -0800, Junio C Hamano wrote:
> > I agree that Solaris default tools are insane, but is there any reason
> > to munge the PATH for a single feature like external grep? Why not
> > EXTERNAL_GREP=/usr/xpg4/bin/grep (or /usr/local/bin/grep) in the
> > Makefile? Why not GIT_EXTERNAL_GREP=$HOME/bin/grep in the environment?
>
> That git-sh-setup "fix" is not for running external grep. It is for our
> scripted Porcelains that rely on working basic tools (sed, tr, who knows
> what else is broken).
Right, but I thought this thread was about external grep, and I thought
you were saying "if you want decent tools, you can use SANE_TOOL_PATH".
And I think we can do much better for that particular case than
recommending SANE_TOOL_PATH (but it seems that is not what you were
actually recommending).
But I admit, I have never really wanted to specify my own external grep.
Wanting your own grep for _features_ is probably insane, as some of your
greps (on worktree files) will use the external grep, and some (on
cached files) will not. So it is really just an optimization, and I
have never felt it so slow that I cared about messing with an
alternative grep on Solaris.
I have to wonder, though...did anybody ever actually profile our
internal grep to find out _why_ it was so much slower than GNU grep?
Could we simply ship a better grep engine and obsolete external grep?
> In fact, our Makefile by default punts on external grep on Sun's. Run
> "git grep NO_EXTERNAL_GREP -- Makefile" to see for yourself --- it would
> work even on Solaris ;-)
Yes, I am even mentioned in the commit log of 01ae841c. :)
-Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Mike Hommey @ 2010-01-04 6:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Miles Bader, Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.LFD.2.00.1001031124420.3630@localhost.localdomain>
On Sun, Jan 03, 2010 at 11:32:24AM -0800, Linus Torvalds wrote:
>
>
> On Sun, 3 Jan 2010, Miles Bader wrote:
> >
> > Since it's a general attribute of solaris that the default (/usr/bin)
> > tools are horrible sysv things and the actual useful tools are in
> > e.g. /usr/xpg4/bin, maybe it would be better to just try and add that
> > directory to the path...?
>
> There is no generic way to make solaris sane, I'm afraid.
>
> Everybody agrees that the "normal" Solaris tools are so horrible that they
> all set up some alternative. However, qutie often the preferred
> alternative is the GNU versions, mostly installed in /usr/local, and then
> they put that first in the path.
Or /usr/sfw, where Sun themselves ship some GNU tools
> Which means that if you put /usr/xpg4/bin before other paths in your PATH,
> you'll totally break such systems, because now you get the (inferior)
> tools in xpg4 before the preferred tools in /usr/local. Or - this also
> happens - people end up installing their own versions in $HOME/bin,
> because the system admin is uncaring or incompetent.
>
> In other words, there is no single normal or default Solaris installation
> that we can work around. The normal/default installation is so horrible
> that it's virtually never used in any environment where people actually
> have shell access and do development.
>
> Don't ask me why. EVERYBODY knows that the default /usr/bin is total crap.
> Even Sun people know. But there's apparently some very deep-seated reason
> (probably not technical, but mental/historical) why they can't be fixed or
> replaced, probably relating to "make world" and the whole build system.
There is simply no explanation for these tools to be that crappy at all.
The most common reason that is given for these tools to stay as crappy as
they always have been is for backwards compatibility. But how does that
prevent from adding features is beyond me. And on the other hand, they
*do* add features to their /usr/bin tools, such as -h in (at least) df
and ls.
Anyways, why not generate the hash-bang lines of the shell scripts from a
Makefile variable that would be set to /usr/xpg4/bin/sh on Solaris and
/bin/sh on others ?
Mike
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Junio C Hamano @ 2010-01-04 5:52 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy,
git
In-Reply-To: <20100104053125.GA5083@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Jan 03, 2010 at 12:49:15PM -0800, Junio C Hamano wrote:
>
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>> > Which means that if you put /usr/xpg4/bin before other paths in your PATH,
>> > you'll totally break such systems, because now you get the (inferior)
>> > tools in xpg4 before the preferred tools in /usr/local. Or - this also
>> > happens - people end up installing their own versions in $HOME/bin,
>> > because the system admin is uncaring or incompetent.
>>
>> The build allows you to define SANE_TOOL_PATH ("the tools found in here
>> are saner than the ones in /usr/bin or /bin" is what it means) and we
>> insert it just in front of /usr/bin or /bin in the original PATH (see
>> git_brokne_path_fix in git-sh-setup.sh).
>>
>> I would call this the right thing (TM) or the best workaround we could do
>> under the constraints, depending on the mood.
>
> I agree that Solaris default tools are insane, but is there any reason
> to munge the PATH for a single feature like external grep? Why not
> EXTERNAL_GREP=/usr/xpg4/bin/grep (or /usr/local/bin/grep) in the
> Makefile? Why not GIT_EXTERNAL_GREP=$HOME/bin/grep in the environment?
That git-sh-setup "fix" is not for running external grep. It is for our
scripted Porcelains that rely on working basic tools (sed, tr, who knows
what else is broken).
In fact, our Makefile by default punts on external grep on Sun's. Run
"git grep NO_EXTERNAL_GREP -- Makefile" to see for yourself --- it would
work even on Solaris ;-)
> Obviously we still need SANE_TOOL_PATH for systems where the /usr/bin is
> so crappy as to be unusable for our scripts. But surely we can do better
> for individual tools where the user might have some more specific
> preference about which tool he uses.
>
> -Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 5:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7v3a2mzzg4.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 12:49:15PM -0800, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > Which means that if you put /usr/xpg4/bin before other paths in your PATH,
> > you'll totally break such systems, because now you get the (inferior)
> > tools in xpg4 before the preferred tools in /usr/local. Or - this also
> > happens - people end up installing their own versions in $HOME/bin,
> > because the system admin is uncaring or incompetent.
>
> The build allows you to define SANE_TOOL_PATH ("the tools found in here
> are saner than the ones in /usr/bin or /bin" is what it means) and we
> insert it just in front of /usr/bin or /bin in the original PATH (see
> git_brokne_path_fix in git-sh-setup.sh).
>
> I would call this the right thing (TM) or the best workaround we could do
> under the constraints, depending on the mood.
I agree that Solaris default tools are insane, but is there any reason
to munge the PATH for a single feature like external grep? Why not
EXTERNAL_GREP=/usr/xpg4/bin/grep (or /usr/local/bin/grep) in the
Makefile? Why not GIT_EXTERNAL_GREP=$HOME/bin/grep in the environment?
Obviously we still need SANE_TOOL_PATH for systems where the /usr/bin is
so crappy as to be unusable for our scripts. But surely we can do better
for individual tools where the user might have some more specific
preference about which tool he uses.
-Peff
^ permalink raw reply
* Re: git file sharing/versioning.
From: Bas Driessen @ 2010-01-04 4:47 UTC (permalink / raw)
To: git
In-Reply-To: <1262580346.9041.20.camel@ams.xobas.net>
Hello,
I have a project where I have 2 trees with several hundreds of files.
Let's call them tree1 and tree2. Only a handful of files in tree2 are
different. What is the best way to set this up in GIT? Basically most
files in tree2 should act as a symbolic link to tree1. So if the file
changes in tree 1, it automatically changes in tree 2. Obviously, I
don't want to store everything double. Branching does not appear to be
an option as changes in tree1 would not be visible in the tree2 branch.
Any advise of how to set this up?
Thanks in advance for your help.
Bas.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: git-svn: handling merge-base failures
From: Andrew Myrick @ 2010-01-04 4:43 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <20100104034540.GA4548@dcvr.yhbt.net>
On Jan 3, 2010, at 7:45 PM, Eric Wong wrote:
> Andrew Myrick <amyrick@apple.com> wrote:
>> On Dec 23, 2009, at 11:54 AM, Andrew Myrick wrote:
>>> One of my projects is failing to clone because merge-base is failing
>>> on one of the revisions; the branch is a partial branch, so
>>> merge-base can't find a common ancestor with trunk. I'd like to
>>> catch the exception that command_oneline should throw when
>>> merge-base fails,
>>
>> Instead of using the Error.pm module, I was able to handle the
>> exception with the more basic eval block. However, there are some
>> details here I would like to discuss with the community.
>>
>> When git-svn fetches a partial branch, it appears to refetch all of
>> the history of the subdirectory from which the branch was created.
>> This creates new commits for the old revisions, and these new commits
>> exist as a separate history for the partial branch. When git-svn
>> fetches the revision at which this partial branch is merged back to
>> trunk, git-svn attempts to run merge-base to find a common ancestor.
>> However, because the partial branch has its own history, the
>> merge-base fails, and git-svn dies.
>>
>> Naively handling the exception with an eval block and skipping the
>> merge ticket works fine in that it brings us back to parity with git
>> 1.6.5.7, but it means that the merge parent relationship between trunk
>> and the partial branch is lost. Is there any way to preserve this
>> information, or does the separate commit history of the partial branch
>> make it fundamentally impossible?
>
> Hi Andrew,
>
> A method of preserving the $SVN_PATH <=> $PARENT@$REV mapping for
> reusing follow_parent-created branches is definitely desired.
>
> I've just been lacking time and motivation these days with other
> projects taking priority. Help (even if it's just to refactor/cleanup
> existing code) would definitely be appreciated here.
Thanks for the explanation, Eric. Unfortunately, I also don't have the time to commit to taking this on for the foreseeable future. I'll try to get my existing patches out in the next couple of days that at least fix the regressions from 1.6.5.7.
Regards,
Andrew
^ permalink raw reply
* Re: git-svn: handling merge-base failures
From: Eric Wong @ 2010-01-04 3:45 UTC (permalink / raw)
To: Andrew Myrick; +Cc: git, Sam Vilain
In-Reply-To: <7878A426-9D87-43B5-A10A-38F3C9369165@apple.com>
Andrew Myrick <amyrick@apple.com> wrote:
> On Dec 23, 2009, at 11:54 AM, Andrew Myrick wrote:
> > One of my projects is failing to clone because merge-base is failing
> > on one of the revisions; the branch is a partial branch, so
> > merge-base can't find a common ancestor with trunk. I'd like to
> > catch the exception that command_oneline should throw when
> > merge-base fails,
>
> Instead of using the Error.pm module, I was able to handle the
> exception with the more basic eval block. However, there are some
> details here I would like to discuss with the community.
>
> When git-svn fetches a partial branch, it appears to refetch all of
> the history of the subdirectory from which the branch was created.
> This creates new commits for the old revisions, and these new commits
> exist as a separate history for the partial branch. When git-svn
> fetches the revision at which this partial branch is merged back to
> trunk, git-svn attempts to run merge-base to find a common ancestor.
> However, because the partial branch has its own history, the
> merge-base fails, and git-svn dies.
>
> Naively handling the exception with an eval block and skipping the
> merge ticket works fine in that it brings us back to parity with git
> 1.6.5.7, but it means that the merge parent relationship between trunk
> and the partial branch is lost. Is there any way to preserve this
> information, or does the separate commit history of the partial branch
> make it fundamentally impossible?
Hi Andrew,
A method of preserving the $SVN_PATH <=> $PARENT@$REV mapping for
reusing follow_parent-created branches is definitely desired.
I've just been lacking time and motivation these days with other
projects taking priority. Help (even if it's just to refactor/cleanup
existing code) would definitely be appreciated here.
> I've created a small svn repository that demonstrates this failure
> with git v1.6.6. Its dump is attached.
Thanks. This (and a similar dump a few weeks back) will definitely
come in handy for writing test cases and fixing this long-standing
issue.
--
Eric Wong
^ permalink raw reply
* Re: git-svn: handling merge-base failures
From: Andrew Myrick @ 2010-01-04 1:37 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Sam Vilain
In-Reply-To: <931B0483-7628-488E-BB9F-C40346353149@apple.com>
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]
On Dec 23, 2009, at 11:54 AM, Andrew Myrick wrote:
> One of my projects is failing to clone because merge-base is failing on one of the revisions; the branch is a partial branch, so merge-base can't find a common ancestor with trunk. I'd like to catch the exception that command_oneline should throw when merge-base fails,
Instead of using the Error.pm module, I was able to handle the exception with the more basic eval block. However, there are some details here I would like to discuss with the community.
When git-svn fetches a partial branch, it appears to refetch all of the history of the subdirectory from which the branch was created. This creates new commits for the old revisions, and these new commits exist as a separate history for the partial branch. When git-svn fetches the revision at which this partial branch is merged back to trunk, git-svn attempts to run merge-base to find a common ancestor. However, because the partial branch has its own history, the merge-base fails, and git-svn dies.
Naively handling the exception with an eval block and skipping the merge ticket works fine in that it brings us back to parity with git 1.6.5.7, but it means that the merge parent relationship between trunk and the partial branch is lost. Is there any way to preserve this information, or does the separate commit history of the partial branch make it fundamentally impossible?
I've created a small svn repository that demonstrates this failure with git v1.6.6. Its dump is attached.
-Andrew
[-- Attachment #2: partial.dump --]
[-- Type: application/octet-stream, Size: 4314 bytes --]
SVN-fs-dump-format-version: 2
UUID: ef8533a7-8eba-4e00-b9e4-68f81a8a4a0e
Revision-number: 0
Prop-content-length: 56
Content-length: 56
K 8
svn:date
V 27
2010-01-04T00:41:48.890110Z
PROPS-END
Revision-number: 1
Prop-content-length: 119
Content-length: 119
K 7
svn:log
V 17
Initial import
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:42:12.648154Z
PROPS-END
Node-path: branches
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: tags
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Revision-number: 2
Prop-content-length: 113
Content-length: 113
K 7
svn:log
V 11
New files
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:43:30.046704Z
PROPS-END
Node-path: trunk/a
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: trunk/a/file
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 0
Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
Content-length: 10
PROPS-END
Node-path: trunk/b
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: trunk/b/file
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 0
Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
Content-length: 10
PROPS-END
Revision-number: 3
Prop-content-length: 122
Content-length: 122
K 7
svn:log
V 20
Create full branch
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:44:34.670334Z
PROPS-END
Node-path: branches/fullbranch
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 2
Node-copyfrom-path: trunk
Revision-number: 4
Prop-content-length: 112
Content-length: 112
K 7
svn:log
V 10
Add text
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:45:11.654184Z
PROPS-END
Node-path: branches/fullbranch/a/file
Node-kind: file
Node-action: change
Text-content-length: 5
Text-content-md5: 6137cde4893c59f76f005a8123d8e8e6
Text-content-sha1: c5d84736ba451747dd5f0eb9d17e104f3697ef47
Content-length: 5
data
Revision-number: 5
Prop-content-length: 129
Content-length: 129
K 7
svn:log
V 27
Merge fullbranch to trunk
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:45:41.203114Z
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: change
Prop-content-length: 59
Content-length: 59
K 13
svn:mergeinfo
V 24
/branches/fullbranch:3-4
PROPS-END
Node-path: trunk/a/file
Node-kind: file
Node-action: change
Text-content-length: 5
Text-content-md5: 6137cde4893c59f76f005a8123d8e8e6
Text-content-sha1: c5d84736ba451747dd5f0eb9d17e104f3697ef47
Content-length: 5
data
Revision-number: 6
Prop-content-length: 125
Content-length: 125
K 7
svn:log
V 23
Create partial branch
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:47:34.954727Z
PROPS-END
Node-path: branches/partialbranch
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 5
Node-copyfrom-path: trunk/b
Prop-content-length: 61
Content-length: 61
K 13
svn:mergeinfo
V 26
/branches/fullbranch/b:3-4
PROPS-END
Revision-number: 7
Prop-content-length: 110
Content-length: 110
K 7
svn:log
V 9
Add data
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:48:22.334502Z
PROPS-END
Node-path: branches/partialbranch/file
Node-kind: file
Node-action: change
Text-content-length: 10
Text-content-md5: 284b44f9273171eb622b27d9a4df5acd
Text-content-sha1: 59cb3d79577306b6be81d41c273ea47cd47968e1
Content-length: 10
more data
Revision-number: 8
Prop-content-length: 133
Content-length: 133
K 7
svn:log
V 31
Merge partial branch to trunk
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:49:11.588697Z
PROPS-END
Node-path: trunk/b
Node-kind: dir
Node-action: change
Prop-content-length: 89
Content-length: 89
K 13
svn:mergeinfo
V 54
/branches/fullbranch/b:3-4
/branches/partialbranch:6-7
PROPS-END
Node-path: trunk/b/file
Node-kind: file
Node-action: change
Text-content-length: 10
Text-content-md5: 284b44f9273171eb622b27d9a4df5acd
Text-content-sha1: 59cb3d79577306b6be81d41c273ea47cd47968e1
Content-length: 10
more data
^ permalink raw reply
* Re: [PATCH v2] Use warning function instead of fprintf(stderr, "Warning: ...").
From: Junio C Hamano @ 2010-01-04 0:41 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Thiago Farina, gitster, git
In-Reply-To: <20100104091847.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Thiago Farina <tfransosi@gmail.com>
>
>> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
>> ---
>> Removed the LF from the end of the strings.
>
> Trying this patch makes t6030-bisect-porcelain.sh fail for me. Was this tested at all?
I noticed it as well; will squash this in.
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index def397c..c51865f 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -423,7 +423,7 @@ test_expect_success 'skipped merge base when good and bad are siblings' '
grep "merge base must be tested" my_bisect_log.txt &&
grep $HASH4 my_bisect_log.txt &&
git bisect skip > my_bisect_log.txt 2>&1 &&
- grep "Warning" my_bisect_log.txt &&
+ grep "warning" my_bisect_log.txt &&
grep $SIDE_HASH6 my_bisect_log.txt &&
git bisect reset
'
^ permalink raw reply related
* Re: [PATCH v2] Use warning function instead of fprintf(stderr, "Warning: ...").
From: Nanako Shiraishi @ 2010-01-04 0:18 UTC (permalink / raw)
To: Thiago Farina; +Cc: gitster, git
In-Reply-To: <1262535630-3918-1-git-send-email-tfransosi@gmail.com>
Quoting Thiago Farina <tfransosi@gmail.com>
> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
> ---
> Removed the LF from the end of the strings.
Trying this patch makes t6030-bisect-porcelain.sh fail for me. Was this tested at all?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [notice] the tip of 'next' rewound
From: Junio C Hamano @ 2010-01-03 23:56 UTC (permalink / raw)
To: git
As announced earlier, 'next' was rebuild directly on top of 'master',
dropping a few topics that has been reverted during 1.6.6 period and
currently has only the following topics:
nd/sparse: sparse checkout;
tr/http-updates: support for non-Basic auth methods to http transport;
jc/checkout-merge-base: "git checkout foo...bar" (notice three-dot);
jh/notes: an early part of "git notes" update;
jk/maint-1.6.5-reset-hard: fix "GIT_WORK_TREE=somewhere git reset --hard";
^ permalink raw reply
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Tay Ray Chuan @ 2010-01-03 23:03 UTC (permalink / raw)
To: Sebastian Thiel; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <loom.20100103T114055-16@post.gmane.org>
Hi,
(you dropped the Cc list; fixed that for you.)
On Sun, Jan 3, 2010 at 6:41 PM, Sebastian Thiel <byronimo@gmail.com> wrote:
> Adding a commandline option to git-push and git-pull that enforces progress
> messages to be printed to stderr would be a feasible and simple fix that would
> clearly improve the usability of tortoise-git and git-python to name only two.
>
> That said, I hope I managed to make myself clear enough this time to help the
> people in charge to figure out how to solve the issue. Once the desired solution
> has been sketched out and the desired new commandline options have been named,
> it could even be me to implement it if necessary, as I'd consider it a gentle
> start into the world of the git codebase.
from your above message solely and setting aside your original patch,
I presume that you want to introduce the ability to force progress
reporting even if stderr isn't a terminal.
I am working a feature (display progress for http operations) that
happens to add this ability to git-push and git-fetch, by specifying
the --progress option.
Regarding git-pull - I guess it's only git-fetch (being
transport-related) that reports progress?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Junio C Hamano @ 2010-01-03 20:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.LFD.2.00.1001031124420.3630@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Which means that if you put /usr/xpg4/bin before other paths in your PATH,
> you'll totally break such systems, because now you get the (inferior)
> tools in xpg4 before the preferred tools in /usr/local. Or - this also
> happens - people end up installing their own versions in $HOME/bin,
> because the system admin is uncaring or incompetent.
The build allows you to define SANE_TOOL_PATH ("the tools found in here
are saner than the ones in /usr/bin or /bin" is what it means) and we
insert it just in front of /usr/bin or /bin in the original PATH (see
git_brokne_path_fix in git-sh-setup.sh).
I would call this the right thing (TM) or the best workaround we could do
under the constraints, depending on the mood.
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-03 19:32 UTC (permalink / raw)
To: Miles Bader; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <877hrzga16.fsf@catnip.gol.com>
On Sun, 3 Jan 2010, Miles Bader wrote:
>
> Since it's a general attribute of solaris that the default (/usr/bin)
> tools are horrible sysv things and the actual useful tools are in
> e.g. /usr/xpg4/bin, maybe it would be better to just try and add that
> directory to the path...?
There is no generic way to make solaris sane, I'm afraid.
Everybody agrees that the "normal" Solaris tools are so horrible that they
all set up some alternative. However, qutie often the preferred
alternative is the GNU versions, mostly installed in /usr/local, and then
they put that first in the path.
Which means that if you put /usr/xpg4/bin before other paths in your PATH,
you'll totally break such systems, because now you get the (inferior)
tools in xpg4 before the preferred tools in /usr/local. Or - this also
happens - people end up installing their own versions in $HOME/bin,
because the system admin is uncaring or incompetent.
In other words, there is no single normal or default Solaris installation
that we can work around. The normal/default installation is so horrible
that it's virtually never used in any environment where people actually
have shell access and do development.
Don't ask me why. EVERYBODY knows that the default /usr/bin is total crap.
Even Sun people know. But there's apparently some very deep-seated reason
(probably not technical, but mental/historical) why they can't be fixed or
replaced, probably relating to "make world" and the whole build system.
Linus
^ permalink raw reply
* [PATCH v2] Use warning function instead of fprintf(stderr, "Warning: ...").
From: Thiago Farina @ 2010-01-03 16:20 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
Removed the LF from the end of the strings.
bisect.c | 4 ++--
builtin-mv.c | 4 +---
http.c | 2 +-
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/bisect.c b/bisect.c
index dc18db8..f1a1f84 100644
--- a/bisect.c
+++ b/bisect.c
@@ -813,11 +813,11 @@ static void handle_skipped_merge_base(const unsigned char *mb)
char *bad_hex = sha1_to_hex(current_bad_sha1);
char *good_hex = join_sha1_array_hex(&good_revs, ' ');
- fprintf(stderr, "Warning: the merge base between %s and [%s] "
+ warning("the merge base between %s and [%s] "
"must be skipped.\n"
"So we cannot be sure the first bad commit is "
"between %s and %s.\n"
- "We continue anyway.\n",
+ "We continue anyway.",
bad_hex, good_hex, mb_hex, bad_hex);
free(good_hex);
}
diff --git a/builtin-mv.c b/builtin-mv.c
index f633d81..8247186 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -169,9 +169,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
* check both source and destination
*/
if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
- fprintf(stderr, "Warning: %s;"
- " will overwrite!\n",
- bad);
+ warning("%s; will overwrite!", bad);
bad = NULL;
} else
bad = "Cannot overwrite";
diff --git a/http.c b/http.c
index ed6414a..455732f 100644
--- a/http.c
+++ b/http.c
@@ -1244,7 +1244,7 @@ int finish_http_object_request(struct http_object_request *freq)
process_http_object_request(freq);
if (freq->http_code == 416) {
- fprintf(stderr, "Warning: requested range invalid; we may already have all the data.\n");
+ warning("requested range invalid; we may already have all the data.");
} else if (freq->curl_result != CURLE_OK) {
if (stat(freq->tmpfile, &st) == 0)
if (st.st_size == 0)
--
1.6.6.75.g37bae
^ permalink raw reply related
* [PATCHv2/RFC 4/4 (resent)] gitweb: Makefile improvements
From: Jakub Narebski @ 2010-01-03 16:07 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Jakub Narebski
In-Reply-To: <1262534850-24572-1-git-send-email-jnareb@gmail.com>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This commit adjust the main Makefile so you can simply run
make gitweb
which in turn calls gitweb/Makefile. This means that in order to
generate gitweb, you can simply run 'make' from gitweb subdirectory:
cd gitweb
make
Targets gitweb/gitweb.cgi and (dependent on JSMIN being defined)
gitweb/gitweb.min.js in main Makefile are preserved for backward
compatibility.
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This implements separate Makefile for gitweb, with main Makefile calling
it, like for gitk-git/, git-gui/, Documentation/, t/, and templates/
directories. The original patch by J.H. did it the opposite way, with
gitweb/Makefile calling main Makefile.
It is marked as RFC because I don't feel that my make-fu is strong enough
to be sure that there are no errors / mistakes. Very slightly tested.
Makefile | 65 +++++----------------------
gitweb/Makefile | 129 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 141 insertions(+), 53 deletions(-)
create mode 100644 gitweb/Makefile
diff --git a/Makefile b/Makefile
index c11719c..9c6d2b2 100644
--- a/Makefile
+++ b/Makefile
@@ -282,29 +282,6 @@ pathsep = :
# JavaScript minifier invocation that can function as filter
JSMIN =
-# default configuration for gitweb
-GITWEB_CONFIG = gitweb_config.perl
-GITWEB_CONFIG_SYSTEM = /etc/gitweb.conf
-GITWEB_HOME_LINK_STR = projects
-GITWEB_SITENAME =
-GITWEB_PROJECTROOT = /pub/git
-GITWEB_PROJECT_MAXDEPTH = 2007
-GITWEB_EXPORT_OK =
-GITWEB_STRICT_EXPORT =
-GITWEB_BASE_URL =
-GITWEB_LIST =
-GITWEB_HOMETEXT = indextext.html
-GITWEB_CSS = gitweb.css
-GITWEB_LOGO = git-logo.png
-GITWEB_FAVICON = git-favicon.png
-ifdef JSMIN
-GITWEB_JS = gitweb.min.js
-else
-GITWEB_JS = gitweb.js
-endif
-GITWEB_SITE_HEADER =
-GITWEB_SITE_FOOTER =
-
export prefix bindir sharedir sysconfdir
CC = gcc
@@ -1526,6 +1503,11 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
chmod +x $@+ && \
mv $@+ $@
+
+.PHONY: gitweb
+gitweb:
+ $(QUIET_SUBDIR0)gitweb $(QUIET_SUBDIR1) all
+
ifdef JSMIN
OTHER_PROGRAMS += gitweb/gitweb.cgi gitweb/gitweb.min.js
gitweb/gitweb.cgi: gitweb/gitweb.perl gitweb/gitweb.min.js
@@ -1533,30 +1515,13 @@ else
OTHER_PROGRAMS += gitweb/gitweb.cgi
gitweb/gitweb.cgi: gitweb/gitweb.perl
endif
- $(QUIET_GEN)$(RM) $@ $@+ && \
- sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
- -e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
- -e 's|++GIT_BINDIR++|$(bindir)|g' \
- -e 's|++GITWEB_CONFIG++|$(GITWEB_CONFIG)|g' \
- -e 's|++GITWEB_CONFIG_SYSTEM++|$(GITWEB_CONFIG_SYSTEM)|g' \
- -e 's|++GITWEB_HOME_LINK_STR++|$(GITWEB_HOME_LINK_STR)|g' \
- -e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
- -e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
- -e 's|"++GITWEB_PROJECT_MAXDEPTH++"|$(GITWEB_PROJECT_MAXDEPTH)|g' \
- -e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
- -e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
- -e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
- -e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
- -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' \
- -e 's|++GITWEB_JS++|$(GITWEB_JS)|g' \
- -e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
- -e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
- $< >$@+ && \
- chmod +x $@+ && \
- mv $@+ $@
+ $(QUIET_SUBDIR0)gitweb $(QUIET_SUBDIR1) $(patsubst gitweb/%,%,$@)
+
+ifdef JSMIN
+gitweb/gitweb.min.js: gitweb/gitweb.js
+ $(QUIET_SUBDIR0)gitweb $(QUIET_SUBDIR1) $(patsubst gitweb/%,%,$@)
+endif # JSMIN
+
git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css gitweb/gitweb.js
$(QUIET_GEN)$(RM) $@ $@+ && \
@@ -1583,12 +1548,6 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
mv $@+ $@
endif # NO_PERL
-
-ifdef JSMIN
-gitweb/gitweb.min.js: gitweb/gitweb.js
- $(QUIET_GEN)$(JSMIN) <$< >$@
-endif # JSMIN
-
ifndef NO_PYTHON
$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS
$(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
diff --git a/gitweb/Makefile b/gitweb/Makefile
new file mode 100644
index 0000000..c9eb1ee
--- /dev/null
+++ b/gitweb/Makefile
@@ -0,0 +1,129 @@
+# The default target of this Makefile is...
+all::
+
+# Define V=1 to have a more verbose compile.
+#
+# Define JSMIN to point to JavaScript minifier that functions as
+# a filter to have gitweb.js minified.
+#
+
+prefix ?= $(HOME)
+bindir ?= $(prefix)/bin
+RM ?= rm -f
+
+# JavaScript minifier invocation that can function as filter
+JSMIN ?=
+
+# default configuration for gitweb
+GITWEB_CONFIG = gitweb_config.perl
+GITWEB_CONFIG_SYSTEM = /etc/gitweb.conf
+GITWEB_HOME_LINK_STR = projects
+GITWEB_SITENAME =
+GITWEB_PROJECTROOT = /pub/git
+GITWEB_PROJECT_MAXDEPTH = 2007
+GITWEB_EXPORT_OK =
+GITWEB_STRICT_EXPORT =
+GITWEB_BASE_URL =
+GITWEB_LIST =
+GITWEB_HOMETEXT = indextext.html
+GITWEB_CSS = gitweb.css
+GITWEB_LOGO = git-logo.png
+GITWEB_FAVICON = git-favicon.png
+ifdef JSMIN
+GITWEB_JS = gitweb.min.js
+else
+GITWEB_JS = gitweb.js
+endif
+GITWEB_SITE_HEADER =
+GITWEB_SITE_FOOTER =
+
+# include user config
+-include ../config.mak.autogen
+-include ../config.mak
+
+# determine version
+../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
+ $(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE
+
+-include ../GIT-VERSION-FILE
+
+### Build rules
+
+SHELL_PATH ?= $(SHELL)
+PERL_PATH ?= /usr/bin/perl
+
+# Shell quote;
+bindir_SQ = $(subst ','\'',$(bindir)) #'
+SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) #'
+PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH)) #'
+
+# Quiet generation (unless V=1)
+QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
+QUIET_SUBDIR1 =
+
+ifneq ($(findstring $(MAKEFLAGS),w),w)
+PRINT_DIR = --no-print-directory
+else # "make -w"
+NO_SUBDIR = :
+endif
+
+ifneq ($(findstring $(MAKEFLAGS),s),s)
+ifndef V
+ QUIET = @
+ QUIET_GEN = $(QUIET)echo ' ' GEN $@;
+ QUIET_SUBDIR0 = +@subdir=
+ QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \
+ $(MAKE) $(PRINT_DIR) -C $$subdir
+ export V
+ export QUIET
+ export QUIET_GEN
+ export QUIET_SUBDIR0
+ export QUIET_SUBDIR1
+endif
+endif
+
+all:: gitweb.cgi
+
+ifdef JSMIN
+FILES=gitweb.cgi gitweb.min.js
+gitweb.cgi: gitweb.perl gitweb.min.js
+else # !JSMIN
+FILES=gitweb.cgi
+gitweb.cgi: gitweb.perl
+endif # JSMIN
+
+gitweb.cgi:
+ $(QUIET_GEN)$(RM) $@ $@+ && \
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
+ -e 's|++GIT_BINDIR++|$(bindir)|g' \
+ -e 's|++GITWEB_CONFIG++|$(GITWEB_CONFIG)|g' \
+ -e 's|++GITWEB_CONFIG_SYSTEM++|$(GITWEB_CONFIG_SYSTEM)|g' \
+ -e 's|++GITWEB_HOME_LINK_STR++|$(GITWEB_HOME_LINK_STR)|g' \
+ -e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
+ -e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
+ -e 's|"++GITWEB_PROJECT_MAXDEPTH++"|$(GITWEB_PROJECT_MAXDEPTH)|g' \
+ -e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
+ -e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
+ -e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
+ -e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
+ -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' \
+ -e 's|++GITWEB_JS++|$(GITWEB_JS)|g' \
+ -e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
+ -e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
+ $< >$@+ && \
+ chmod +x $@+ && \
+ mv $@+ $@
+
+ifdef JSMIN
+gitweb.min.js: gitweb.js
+ $(QUIET_GEN)$(JSMIN) <$< >$@
+endif # JSMIN
+
+clean:
+ $(RM) $(FILES)
+
+.PHONY: all clean .FORCE-GIT-VERSION-FILE
--
1.6.5.3
^ permalink raw reply related
* [PATCHv3 3/4 (resent)] gitweb: Optionally add "git" links in project list page
From: Jakub Narebski @ 2010-01-03 16:07 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Jakub Narebski
In-Reply-To: <1262534850-24572-1-git-send-email-jnareb@gmail.com>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This adds a "git" link for each project in the project list page,
should a common $gitlinkurl_base be defined and not empty. The full
URL of each link is composed of $gitlinkurl_base and project name.
It is intended for git:// links, and in fact GITWEB_BASE_URL build
variable is used as its default value only if it starts with git://
This does make the assumption that the git repositories share a common
path. Nothing to date is known to actually make use of introduced
link.
Created "git" link follows rel=vcs-* microformat specification:
http://kitenet.net/~joey/rfc/rel-vcs/
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I think it might be good idea... but for the fact "Nothing to date is
known to actually make use of introduced link". What's its intended
use?
Differences to original version by John 'Warthog9' Hawley (J.H.):
* It doesn't cause syntax error ;-)
* Escaping of attribute value is left to CGI.pm (avoid double escaping)
* $gitlinkurl got renamed to $gitlinkurl_base, now includes git://
prefix, and defaults to GITWEB_BASE_URL if it begins with git://
* Added description of $gitlinkurl_base to gitweb/README
* Uses rel=vcs-* microformat by Joey Hess
I assume that nobody sane would define $gitlinkurl_base to "0";
the code assumes that is enough to check that $gitlinkurl_base
is true-ish.
gitweb/README | 4 ++++
gitweb/gitweb.perl | 8 ++++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 608b0f8..36fb059 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -71,6 +71,7 @@ You can specify the following configuration variables when building GIT:
* GITWEB_BASE_URL
Git base URLs used for URL to where fetch project from, i.e. full
URL is "$git_base_url/$project". Shown on projects summary page.
+ If it begins with "git://" it is also used for $gitlinkurl_base, see below.
Repository URL for project can be also configured per repository; this
takes precedence over URLs composed from base URL and a project name.
Note that you can setup multiple base URLs (for example one for
@@ -204,6 +205,9 @@ not include variables usually directly set during build):
access, and one for http:// "dumb" protocol access). Note that per
repository configuration in 'cloneurl' file, or as values of gitweb.url
project config.
+ * $gitlinkurl_base
+ Git base URL used (if it is defined and not empty) for "git" link in
+ projects list, for each project. Full URL is "$gitlinkurl_base/$project".
* $default_blob_plain_mimetype
Default mimetype for blob_plain (raw) view, if mimetype checking
doesn't result in some other type; by default 'text/plain'.
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b9bd865..efb6471 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -224,6 +224,10 @@ our %avatar_size = (
# If it is true, exit if gitweb version and git binary version don't match
our $git_versions_must_match = 0;
+# If this variable is set and not empty, add an extra link called "git"
+# for each project in project list. Full URL is "$gitlinkurl_base/$project".
+our $gitlinkurl_base = ("++GITWEB_BASE_URL++" =~ m!^(git://.*)$!) ? $1 : '';
+
# Used to set the maximum load that we will still respond to gitweb queries.
# If server load exceed this value then return "503 server busy" error.
# If gitweb cannot determined server load, it is taken to be 0.
@@ -4472,6 +4476,10 @@ sub git_project_list_body {
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
+ ($gitlinkurl_base ?
+ " | " . $cgi->a({-href=>"$gitlinkurl_base/$pr->{'path'}",
+ -rel=>"vcs-git"}, "git")
+ : '') .
"</td>\n" .
"</tr>\n";
}
--
1.6.5.3
^ permalink raw reply related
* [RFC/PATCHv2 2/4 (resent)] gitweb: Add option to force version match
From: Jakub Narebski @ 2010-01-03 16:07 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Jakub Narebski
In-Reply-To: <1262534850-24572-1-git-send-email-jnareb@gmail.com>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This adds $git_versions_must_match variable, which is set to true
value checks that we are running on the same version of git that we
shipped with, and if not throw '500 Internal Server Error' error.
What is checked is the version of gitweb (embedded in building
gitweb.cgi), against version of runtime git binary used.
Gitweb can usually run with a mismatched git install. This is more
here to give an obvious warning as to whats going on vs. silently
failing.
By default this feature is turned off.
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I don't quite see the reason behind such option, and I think that
error (instead of for example warning) on version mismatch is too much.
In short: this change is meant to avoid situation where version
mismatch results in silent error, but it would work only if it would
be default on; on the other hand having it default on is I think too
inconvenient, so I changed it to default off, which perhaps defeats
the stated purpose of this patch.
This is an RFC because formatting of error page is a bit rough, and
(ab)uses exist CSS classes instead of creating new classnames for
semantic markup.
Differences from original version, by J.H.:
* Changed name and flipped meaning of config variable, from
$missmatch_git to $git_versions_must_match
* $git_versions_must_match is boolean flag - do not compare with an
empty string.
* Changed error message a bit, fixed style, added entry in README
gitweb/README | 3 +++
gitweb/gitweb.perl | 33 +++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 6c2c8e1..608b0f8 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -233,6 +233,9 @@ not include variables usually directly set during build):
If server load exceed this value then return "503 Service Unavailable" error.
Server load is taken to be 0 if gitweb cannot determine its value. Set it to
undefined value to turn it off. The default is 300.
+ * $git_versions_must_match
+ If set, gitweb fails with 500 Internal Server Error if the version of gitweb
+ doesn't match version of git binary. The default is false.
Projects list file format
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3222131..b9bd865 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -221,6 +221,9 @@ our %avatar_size = (
'double' => 32
);
+# If it is true, exit if gitweb version and git binary version don't match
+our $git_versions_must_match = 0;
+
# Used to set the maximum load that we will still respond to gitweb queries.
# If server load exceed this value then return "503 server busy" error.
# If gitweb cannot determined server load, it is taken to be 0.
@@ -581,6 +584,36 @@ if (defined $maxload && get_loadavg() > $maxload) {
our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
$number_of_git_cmds++;
+# Throw an error if git versions does not match, if $git_versions_must_match is true.
+if ($git_versions_must_match &&
+ $git_version ne $version) {
+ git_header_html('500 - Internal Server Error');
+ my $admin_contact =
+ defined $ENV{'SERVER_ADMIN'} ? ", $ENV{'SERVER_ADMIN'}," : '';
+ print <<"EOT";
+<div class="page_body">
+<br /><br />
+500 - Internal Server Error
+<br />
+</div>
+<hr />
+<div class="readme">
+<h1 align="center">*** Warning ***</h1>
+<p>
+This version of gitweb was compiled for <b>@{[esc_html($version)]}</b>,
+however git version <b>@{[esc_html($git_version)]}</b> was found on server,
+and administrator requested strict version checking.
+</p>
+<p>
+Please contact the server administrator${admin_contact} to either configure
+gitweb to allow mismatched versions, or update git or gitweb installation.
+</p>
+</div>
+EOT
+ git_footer_html();
+ exit;
+}
+
$projects_list ||= $projectroot;
# ======================================================================
--
1.6.5.3
^ permalink raw reply related
* [PATCHv2 1/4 (resent)] gitweb: Load checking
From: Jakub Narebski @ 2010-01-03 16:07 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Jakub Narebski
In-Reply-To: <1262534850-24572-1-git-send-email-jnareb@gmail.com>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This changes slightly the behavior of gitweb, so that it verifies
that the box isn't inundated with before attempting to serve gitweb.
If the box is overloaded, it basically returns a 503 Server Unavailable
until the load falls below the defined threshold. This helps dramatically
if you have a box that's I/O bound, reaches a certain load and you
don't want gitweb, the I/O hog that it is, increasing the pain the
server is already undergoing.
This behavior is controlled by $maxload configuration variable.
Default is a load of 300, which for most cases should never be hit.
Unset it (set it to undefined value, i.e. undef) to turn off checking.
Currently it requires that '/proc/loadavg' file exists, otherwise the
load check is bypassed (load is taken to be 0). So platforms that do
not implement '/proc/loadavg' currently cannot use this feature.
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Originally appeared in
http://permalink.gmane.org/gmane.comp.version-control.git/135418
Differences to original version by John 'Warthog9' Hawley (J.H.):
* Slightly improved wording in commit message and in comments
* $maxload is described in "Gitweb config file variables section
in gitweb/README
* You can use '$maxload = undef;' to turn off load checking
* Error page for too high load is generated using die_error, which had
to be extended to handle 503 Service Unavailable HTTP error code
One complaints that didn't get addressed was describing alternate
approaches to just reading '/proc/loadavg', like using BSD::getloadavg
module from CPAN, either in comments in gitweb.perl or in commit
message. But I have changed my mind since then about this issue,
and now I think it is not strictly necessary. I think that
limitations of current approach are described in sufficient detail,
and we have fall back for when used method cannot work.
gitweb/README | 7 ++++++-
gitweb/gitweb.perl | 39 +++++++++++++++++++++++++++++++++++----
2 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index e34ee79..6c2c8e1 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -174,7 +174,7 @@ not include variables usually directly set during build):
Base URL for relative URLs in pages generated by gitweb,
(e.g. $logo, $favicon, @stylesheets if they are relative URLs),
needed and used only for URLs with nonempty PATH_INFO via
- <base href="$base_url>. Usually gitweb sets its value correctly,
+ <base href="$base_url">. Usually gitweb sets its value correctly,
and there is no need to set this variable, e.g. to $my_uri or "/".
* $home_link
Target of the home link on top of all pages (the first part of view
@@ -228,6 +228,11 @@ not include variables usually directly set during build):
repositories from launching cross-site scripting (XSS) attacks. Set this
to true if you don't trust the content of your repositories. The default
is false.
+ * $maxload
+ Used to set the maximum load that we will still respond to gitweb queries.
+ If server load exceed this value then return "503 Service Unavailable" error.
+ Server load is taken to be 0 if gitweb cannot determine its value. Set it to
+ undefined value to turn it off. The default is 300.
Projects list file format
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7e477af..3222131 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -221,6 +221,12 @@ our %avatar_size = (
'double' => 32
);
+# Used to set the maximum load that we will still respond to gitweb queries.
+# If server load exceed this value then return "503 server busy" error.
+# If gitweb cannot determined server load, it is taken to be 0.
+# Leave it undefined (or set to 'undef') to turn off load checking.
+our $maxload = 300;
+
# You define site-wide feature defaults here; override them with
# $GITWEB_CONFIG as necessary.
our %feature = (
@@ -551,6 +557,26 @@ if (-e $GITWEB_CONFIG) {
do $GITWEB_CONFIG_SYSTEM if -e $GITWEB_CONFIG_SYSTEM;
}
+# Get loadavg of system, to compare against $maxload.
+# Currently it requires '/proc/loadavg' present to get loadavg;
+# if it is not present it returns 0, which means no load checking.
+sub get_loadavg {
+ open my $fd, '<', '/proc/loadavg'
+ or return 0;
+ my @load = split(/\s+/, scalar <$fd>);
+ close $fd;
+
+ # The first three columns measure CPU and IO utilization of the last one,
+ # five, and 10 minute periods. The fourth column shows the number of
+ # currently running processes and the total number of processes in the m/n
+ # format. The last column displays the last process ID used.
+ return $load[0] || 0;
+}
+
+if (defined $maxload && get_loadavg() > $maxload) {
+ die_error(503, "The load average on the server is too high");
+}
+
# version of the core git binary
our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
$number_of_git_cmds++;
@@ -3354,14 +3380,19 @@ sub git_footer_html {
# 500: The server isn't configured properly, or
# an internal error occurred (e.g. failed assertions caused by bugs), or
# an unknown error occurred (e.g. the git binary died unexpectedly).
+# 503: The server is currently unavailable (because it is overloaded,
+# or down for maintenance). Generally, this is a temporary state.
sub die_error {
my $status = shift || 500;
my $error = shift || "Internal server error";
- my %http_responses = (400 => '400 Bad Request',
- 403 => '403 Forbidden',
- 404 => '404 Not Found',
- 500 => '500 Internal Server Error');
+ my %http_responses = (
+ 400 => '400 Bad Request',
+ 403 => '403 Forbidden',
+ 404 => '404 Not Found',
+ 500 => '500 Internal Server Error',
+ 503 => '503 Service Unavailable',
+ );
git_header_html($http_responses{$status});
print <<EOF;
<div class="page_body">
--
1.6.5.3
^ permalink raw reply related
* [PATCHv3 0/4 (resent)] Miscelanous gitweb improvements from J.H.
From: Jakub Narebski @ 2010-01-03 16:07 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Jakub Narebski
This is resend of early part of "[PATCH 0/6] Gitweb caching changes v2"
thread by John 'Warthog9' Hawley (J.H.),
Message-ID: <1260488743-25855-1-git-send-email-warthog9@kernel.org>
http://thread.gmane.org/gmane.comp.version-control.git/135052
or alternatively
git://git.kernel.org/pub/scm/git/warthog9/gitweb.git gitweb-ml-v2
with a few modifications of my own. Those patches were send originally as
responses in the mentioned thread, for further comments from original
author. As the discussion didn't pick up (because of kernel.org upgrade, and
perhaps due to end-of-year stuff), I am resending those patches in a
separate thread for a better visibility; only comments are changed.
This series of patches is rebased on top of commit 37bae10
(Merge branch 'maint', 2009-12-31) in 'master' branch.
Change that apply to all patches in series:
* moving from "GITWEB - " to "gitweb: " as subsystem prefix
* changing author to John 'Warthog9' Hawley <warthog9@kernel.org>
(it was John 'Warthog9' Hawley <warthog9@eaglescrag.net>)
* add signoff or change it to John 'Warthog9' Hawley <warthog9@kernel.org>,
and of course add my own signoff.
I have included reply to neither "GITWEB - File based caching layer"
nor "GITWEB - Separate defaults from main file" in this thread/series.
I haven't included the main point of the whole series, namely adding
response caching layer in the form that is used in git.kernel.org, because
I think this patch should be split into smaller parts, and unit-tested.
As it is now it is a bit of mess. I have done patch which makes gitweb
always use explicit filehandle when printing (simplifying a bit it
replaces 'print <something>' by 'print {$out} <something>', with $out set
to \*STDOUT), as a patch that prepares for (optional) gitweb caching, while
not affecting throughput, latency and memory consumption when caching is
disabled, as opposed to original solution by J.H. of always storing whole
response in scalar and writing it at the end.
I haven't included splitting of gitweb_defaults.perl off gitweb.perl, as it
was after large and invasive gitweb caching patch, it would require
substantial changes to gitweb tests upfront (by testing built gitweb.cgi and
not source gitweb.perl), and needs fixing of Makefile to actually work
reliably (we could have to process both gitweb.perl and
gitweb_defaults.perl, while provided Makefile process only the file which
triggered the rule... I think).
I am not sure if 'gitweb: Add option to force version match' is a good
solution to the problem it tires to address, i.e. if it is worth having,
and I am not sure if I did 'gitweb: Makefile improvements' correctly.
John 'Warthog9' Hawley (4):
gitweb: Load checking
gitweb: Add option to force version match
gitweb: Optionally add "git" links in project list page
gitweb: Makefile improvements
Makefile | 65 +++++---------------------
gitweb/Makefile | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++++
gitweb/README | 14 +++++-
gitweb/gitweb.perl | 80 ++++++++++++++++++++++++++++++--
4 files changed, 230 insertions(+), 58 deletions(-)
create mode 100644 gitweb/Makefile
John, any comments?
--
Jakub Narebski
ShadeHawk or jnareb on #git
Poland
^ permalink raw reply
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Sebastian Thiel @ 2010-01-03 10:41 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20091119T221732-624@post.gmane.org>
Sorry for the badly formatted message, and thanks a lot for the correction which
is what my post should have been in the first place.
Redoing the commit is not what will be needed for git-python to work properly
which is why I will tell the whole story before submitting any(more) patches.
With git v1.6.5, git-push was adjusted not to provide progress messages anymore
if the device attached to stderr is not a tty. Previously, this was only the
case with git-fetch. For git-python, and other callers of the commandline such
as tortoise-git, there currently is no way to provide progress information to
the user unless they (somehow) simulate a tty which appears unfeasible. When
using these tools, time consuming operations tend to appear as if they are
hanging. One might argue that most code is fetched and pushed in a matter of
seconds, but if git is used to store large binary data, processing and
transferring it will take time.
The issue mentioned with git-update-index and it's missing flush that would
cause a deadlock in some porcelain can be fixed trivially, but seen in the
context of the git-push and git-pull a more thorough solution might be more
appealing. As mentioned by Junio, a default flush after each report might slow
down some existing porcelain, and a commandline option would be part of the
proper solution. I would argue though that a separate option would add quite
some complexity to the command as it is a very specialized one. Instead I would
recommend checking whether --stdin is given on the commandline, and flush stdout
if that is true. This would natively make the command behave like
git-hash-object and git-cat-file. If --stdin is not provided, report is not
required to flush after every call as the commandline options are processed
without additional user interaction.
Adding a commandline option to git-push and git-pull that enforces progress
messages to be printed to stderr would be a feasible and simple fix that would
clearly improve the usability of tortoise-git and git-python to name only two.
That said, I hope I managed to make myself clear enough this time to help the
people in charge to figure out how to solve the issue. Once the desired solution
has been sketched out and the desired new commandline options have been named,
it could even be me to implement it if necessary, as I'd consider it a gentle
start into the world of the git codebase.
Thanks for picking this up again,
Sebastian
^ permalink raw reply
* Re: suppress fatal pathspec errors from "git add"?
From: Jakub Narebski @ 2010-01-03 9:44 UTC (permalink / raw)
To: Jeff King; +Cc: aaron smith, git
In-Reply-To: <20100103074058.GB23031@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Dec 31, 2009 at 01:24:59PM -0800, aaron smith wrote:
>
> > I'm looking through the add documentation, I don't see a way to
> > suppress fatal pathspec errors? For example, if I'm adding 5 files,
> > but one of them is mis-spelled, can I have git just supress the errors
> > and add the other four?
>
> Hmm. I would have thought "git add --ignore-errors" would do what you
> want, but it only ignores errors in reading the file. If we can't stat
> it, we will always die. IMHO that is an oversight in how
> "--ignore-errors" works (why should this one particular error be treated
> as fatal, when others are not?).
I have thought that this is task for --ignore-missing / --missing-ok
option, but this option(s) does not apply to git-add / git-rm; the former
is from git-write-index, the latter form from git-write-tree.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v3] Smart-http documentation: add example of how to execute from userdir
From: Junio C Hamano @ 2010-01-03 8:34 UTC (permalink / raw)
To: Tay Ray Chuan, Shawn O. Pearce; +Cc: git, Tarmigan Casebolt
In-Reply-To: <1262467101-5755-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
> Smart-http may be an attactive and easy way for people to setup git
> hosting on shared servers whose primary web server configuration they
> do not control. To facilite this, provide an example of how it may be
> done.
>
> cc: Tay Ray Chuan <rctay89@gmail.com>
> cc: Shawn O. Pearce <spearce@spearce.org>
> Editing-by: Tay Ray Chuan <rctay89@gmail.com>
> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
I still see Cc: here; are people named above (and others commented on
earlier versions) happy with this round?
^ permalink raw reply
* Re: suppress fatal pathspec errors from "git add"?
From: Jeff King @ 2010-01-03 8:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: aaron smith, git
In-Reply-To: <7vk4vz38v0.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 12:12:19AM -0800, Junio C Hamano wrote:
> If your primary activity that happens in the work tree were:
>
> while :
> do
> file=$(date +"random-%H%M%S")
> >"$file"
> rm -f "$file"
> done
>
> and your add were done in
>
> while sleep 3600
> do
> git add $(for i in *; do test -e $i && echo $i; done)
> git commit -m "hourly snapshot"
> done
>
> totally asynchronously without coordinating with what the primary activity
> is doing, your "test -e && echo" can race with a concurrent "rm".
Of course. But in such a situation, you are almost certainly better off
doing "git add -A". The external loop is really only useful if you want
to add a subset of the files that may or may not exist for some reason.
Which is getting pretty specific and crazy.
I haven't checked to see whether "add -A" has a race in discovering
files versus actually adding them (I suppose there has to be one...even
if we open() immediately and use fstat() and friends for everything
else, there still must be a race between getting the name from readdir()
and calling open()).
And I can see that as a potentially useful workflow: you are doing
regular snapshots of a set of files which are being changed by an
outside force. You care about errors, but not files disappearing between
readdir() and stat(). The "find" command has an "--ignore-readdir-race"
option, which is what you would want.
But that is not "--ignore-errors should also ignore missing files". It
is "I want to ignore missing files but not other errors".
> Even though I think it is an insane use pattern that we shouldn't bother
> to bend too much backwards to support it, --ignore-errors were added
> primarily for a similar use case (i.e. by the time we try to read it, it
> is either gone or it cannot be read by the user who runs "git add"), so in
> that sense it _might_ make sense to ignore all errors with the option. If
> we choose to go in that direction, it would also make tons of sense to
> update the documentation of the option to caution more strongly that its
> use is a sign of insanity and is discouraged at the same time.
I tracked down the original thread and it looks like the motivation was
to handle repositories with a mixed set of readable and inaccessible
(due to permissions) files:
http://article.gmane.org/gmane.comp.version-control.git/75676
So I think it's not _totally_ insane there. You would do "git add
--ignore-errors ." instead of having to manually write the shell loop of
accessible items (though personally, I think I would just write the
shell loop in that situation).
That's just my two cents on the matter. I'm not personally planning on
writing patches for either case.
-Peff
^ permalink raw reply
* Re: suppress fatal pathspec errors from "git add"?
From: Junio C Hamano @ 2010-01-03 8:12 UTC (permalink / raw)
To: Jeff King; +Cc: aaron smith, git
In-Reply-To: <20100103074058.GB23031@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... I could see it
> if your workflow were something like "in a script, add these N files if
> they exist, but it is not an error if they don't". But I still don't
> think you would want to ignore all errors; you would want to do
> something like:
>
> $ git add $(for i in foo bar baz; do test -e $i && echo $i; done)
>
> instead. Am I missing something?
If your primary activity that happens in the work tree were:
while :
do
file=$(date +"random-%H%M%S")
>"$file"
rm -f "$file"
done
and your add were done in
while sleep 3600
do
git add $(for i in *; do test -e $i && echo $i; done)
git commit -m "hourly snapshot"
done
totally asynchronously without coordinating with what the primary activity
is doing, your "test -e && echo" can race with a concurrent "rm".
Even though I think it is an insane use pattern that we shouldn't bother
to bend too much backwards to support it, --ignore-errors were added
primarily for a similar use case (i.e. by the time we try to read it, it
is either gone or it cannot be read by the user who runs "git add"), so in
that sense it _might_ make sense to ignore all errors with the option. If
we choose to go in that direction, it would also make tons of sense to
update the documentation of the option to caution more strongly that its
use is a sign of insanity and is discouraged at the same time.
^ 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