* Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: Junio C Hamano @ 2006-09-27 6:19 UTC (permalink / raw)
To: David Rientjes; +Cc: git
In-Reply-To: <Pine.LNX.4.64N.0609262216390.12560@attu2.cs.washington.edu>
David Rientjes <rientjes@cs.washington.edu> writes:
> When I read "x > 0", my mind parses that very easily. When I read "0 <
> x", it takes me a few cycles longer. I think the goal of any software
> project is to not only emit efficient and quality code, but also code that
> can be read and deciphered with ease unless it's impossible otherwise.
Well, the thing is, I end up being the guy who needs to stare at
git code longer than you do ;-).
Before --stat-width was introduced there was code like this:
if (max + len > 70)
max = 70 - len;
Here "len" is the width of the filename part, and "max" is the
number of changes we need to express. The code is saying "if we
use one column for each changed line, does graph and name exceed
70 columns -- if so use the remainder of the line after we write
name for the graph". Your "constant at right" rule makes this
kosher.
If we make that to a variable, say line_width, we can still
write:
if (max + len > line_width)
...
I however tend to think "if line_width cannot fit (max + len)
then we do this", which would be more naturally expressed with:
if (line_width < max + len)
...
Now, at this point, it is really the matter of taste and there
is no real reason to prefer one over the other. Textual
ordering lets my eyes coast while reading the code without
taxing the brain. I can see that the expression compares two
quantities, "line_width" and "max + len", and the boolean holds
true if line_width _comes_ _before_ "max + len" on the number
line (having number line in your head helps visualizing what is
compared with what). If you write the comparison the wrong way,
it forces me to stop and think -- because on my number line
smaller numbers appear left, and cannot help me reading the
comparison written in "a > b" order.
I could try writing constants on the right hand side when
constants are involved, but I do not think it makes much sense.
It means that I would end up doing:
- if (max + len > 70)
- max = 70 - len;
+ if (line_width < max + len)
+ max = line_width - len;
Consistency counts not only while reading the finished code, but
also it helps reviewing the diff between the earlier version
that used constant (hence forced to have it on the right hand
side by your rule) and the version that made it into a variable.
> To change the code itself because of a hard 80-column limit or because
> you're tired of hitting the tab key is poor style.
Well, the program _firstly_ matches the logic flow better, and
_in_ _addition_ if you write it another way it becomes
unnecessarily too deeply indented. So while I agree with you as a
general principle that indentation depth should not dictate how
we code it does not apply to this particular example.
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-27 6:15 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Matthew L Foster
In-Reply-To: <20060927055216.GA28490@coredump.intra.peff.net>
On Wed, 27 Sep 2006 01:52:16 -0400
Jeff King <peff@peff.net> wrote:
> Yes, that is what I was trying to point out by making the branch/repo
> distinction in my previous mail.
Yeah, Junio's response made me realize that. Apologies.
> We should be able to make a naive space-time tradeoff: whenever a ref is
> updated from X to Y at time T, for each commit C in X..Y, mark the tuple
> (ref, C) with time T. Assuming a reasonably packed format (20 bytes of
> SHA1, 4 bytes of time, sorted into .git/time-cache/master) the git
> repository would require less than 1M per branch. Updating the ref
> becomes much more expensive, but looking up the value is quite cheap.
Yes. It should be relatively straight forward, and removes the need to
use the reflog at all. It's the right tradeoff since the value would
be queried much more often than updated.
> Of course, rewinding would make this more complicated. I'm still not
> convinced this approach is worth the effort.
You could almost ignore rewinding without too big a problem, or at least
only deal with it when performing a prune.
As for being worth the effort, we'll have to see if anyone steps up to
actually offer a patch. If not, you're right again :o)
Sean
^ permalink raw reply
* Re: git and time
From: Jeff King @ 2006-09-27 5:52 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, git, Matthew L Foster
In-Reply-To: <20060927010437.5fa57ed0.seanlkml@sympatico.ca>
On Wed, Sep 27, 2006 at 01:04:37AM -0400, Sean wrote:
> Well, yes. And all of my examples have assumed the example of
> Linus' repository where there is only one branch. So yes, in the
> case where there are more than one branch, you want to be able
> to ask the more specific question, when did this commit arrive
> into this repo-branch.
Yes, that is what I was trying to point out by making the branch/repo
distinction in my previous mail.
> If we do agree on that point, then the rest is just the details
> of how plausible it is to provide those answers. Shawn has made
> it clear that the reflog doesn't really have all the information
> we need yet. On top of which it would be expensive to compute
> etc.
We should be able to make a naive space-time tradeoff: whenever a ref is
updated from X to Y at time T, for each commit C in X..Y, mark the tuple
(ref, C) with time T. Assuming a reasonably packed format (20 bytes of
SHA1, 4 bytes of time, sorted into .git/time-cache/master) the git
repository would require less than 1M per branch. Updating the ref
becomes much more expensive, but looking up the value is quite cheap.
Of course, rewinding would make this more complicated. I'm still not
convinced this approach is worth the effort.
-Peff
^ permalink raw reply
* Re: [PATCH] svnimport add support for parsing From lines for author
From: Junio C Hamano @ 2006-09-27 5:34 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <4518DC11.5050806@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
>>> Now that we have support for parsing Signed-off-by: for author
>>> information it makes sense to handle From: as well.
>>
>> I take that you are referring to Sasha's change in ae35b304; I
>> asked for actual svn users for ACK/NACK but I did not hear any.
>> Can I understand that you use svnimport for real projects and
>> are happy with Sasha's change? --- that would be an ack that
>> would help me sleep better ;-).
>
> Heh. Yeah I am tracking a small SVN repository which is using the
> kernel DCO. we have From:/S-o-b: much as akpm uses in -mm. This was
> the result of seeing that change and wanting to see if it would pick up
> our sign-offs. It only seemed deficient in From: handling :). It seems
> to work well in practice for me.
Thanks.
>> I also wonder instead of piling up custom flags if it is better
>> to let match-and-extract pattern be specified from the command
>> line.
>
> I did look at reusing the -S flag, such that -S would be S-o-b: handling
> and -SS would be S-o-b: and From:, but this script is currently using
> the old getopt implementation which doesn't record repeats.
>
> So you're proposing something more like:
>
> git svn-import -S "Signed-off-by:" -S "From:" ...
>
> Again, we'll have to update the options handling to get that kind of
> behaviour. How would you feel about -SS in this context.
It was more of an idle speculation than a serious proposal. I
do not think there are too many different ways to record the
authorship information, so having just two hardwired patterns -F
and -S would be sufficient. If there were, then string of -S
options that specify the header-looking strings or match
patterns would have made more sense.
^ permalink raw reply
* Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: David Rientjes @ 2006-09-27 5:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz8lj3pl.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Sep 2006, Junio C Hamano wrote:
> David Rientjes <rientjes@cs.washington.edu> writes:
>
> > Again with the constant placement in a comparison expression.
>
> I won't comment on this one. See list archives ;-).
>
I'm very familiar with the list archives and your support of writing
relationals like 0 < x. It's a matter of taste. And since the large
majority of programmers in any language write x > 0 instead, I think it's
preferrable to write code that is in the style and taste of the majority.
Large software projects require a conformity in the style in which the
code is written. Granted the git developer community is small, there is
still a need for this confomity so that developers don't have to put up
with the subtleties in the style of which individuals decide to code.
When I read "x > 0", my mind parses that very easily. When I read "0 <
x", it takes me a few cycles longer. I think the goal of any software
project is to not only emit efficient and quality code, but also code that
can be read and deciphered with ease unless it's impossible otherwise.
> What's happening here in this particular case is:
>
> if the changes fits within the alloted width
> ; /* we do not have to do anything */
> else if we are using non-linear scale {
> scale it like this
> }
> else {
> scale it like that
> }
>
> so the code actually matches the flow of thought perfectly well.
>
> I first tried to write it without "if () ;/*empty*/ else" chain
> like this:
>
> if given width is narrower than changes we have {
> if we are doing non-linear scale {
> scale it like this
> }
> else {
> scale it like that
> }
> }
>
>
> It made the indentation unnecessarily deep.
>
To change the code itself because of a hard 80-column limit or because
you're tired of hitting the tab key is poor style. The idents are there
for a purpose: it tells the reader that the code is inside a block. So
when this conditional becomes a screen wide, I can understand it on the
second screen and remember that I'm inside a conditional and not rely on
the previous 'else' to jog my memory. C is not a whitespace-dependent
language like Python, but since when did idents (which are there _solely_
for the purpose of helping the reader) become deprecated?
David
^ permalink raw reply
* [PATCH] Ignore executable bit when adding files if filemode=0.
From: Shawn Pearce @ 2006-09-27 5:21 UTC (permalink / raw)
To: git
If the user has configured core.filemode=0 then we shouldn't set
the execute bit in the index when adding a new file as the user
has indicated that the local filesystem can't be trusted.
This means that when adding files that should be marked executable
in a repository with core.filemode=0 the user must perform a
'git update-index --chmod=+x' on the file before committing the
addition.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-update-index.c | 4 +++-
read-cache.c | 4 +++-
t/t3700-add.sh | 22 ++++++++++++++++++++++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 0620e77..a3c0a45 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -112,11 +112,13 @@ static int add_file_to_cache(const char
ce->ce_mode = create_ce_mode(st.st_mode);
if (!trust_executable_bit) {
/* If there is an existing entry, pick the mode bits
- * from it.
+ * from it, otherwise force to 644.
*/
int pos = cache_name_pos(path, namelen);
if (0 <= pos)
ce->ce_mode = active_cache[pos]->ce_mode;
+ else
+ ce->ce_mode = create_ce_mode(S_IFREG | 0644);
}
if (index_path(ce->sha1, path, &st, !info_only))
diff --git a/read-cache.c b/read-cache.c
index 20c9d49..97c3867 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -347,11 +347,13 @@ int add_file_to_index(const char *path,
ce->ce_mode = create_ce_mode(st.st_mode);
if (!trust_executable_bit) {
/* If there is an existing entry, pick the mode bits
- * from it.
+ * from it, otherwise force to 644.
*/
int pos = cache_name_pos(path, namelen);
if (pos >= 0)
ce->ce_mode = active_cache[pos]->ce_mode;
+ else
+ ce->ce_mode = create_ce_mode(S_IFREG | 0644);
}
if (index_path(ce->sha1, path, &st, 1))
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 6cd05c3..d36f22d 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -19,4 +19,26 @@ test_expect_success \
'Test that "git-add -- -q" works' \
'touch -- -q && git-add -- -q'
+test_expect_success \
+ 'git-add: Test that executable bit is not used if core.filemode=0' \
+ 'git repo-config core.filemode 0 &&
+ echo foo >xfoo1 &&
+ chmod 755 xfoo1 &&
+ git-add xfoo1 &&
+ case "`git-ls-files --stage xfoo1`" in
+ 100644" "*xfoo1) echo ok;;
+ *) echo fail; git-ls-files --stage xfoo1; exit 1;;
+ esac'
+
+test_expect_success \
+ 'git-update-index --add: Test that executable bit is not used...' \
+ 'git repo-config core.filemode 0 &&
+ echo foo >xfoo2 &&
+ chmod 755 xfoo2 &&
+ git-add xfoo2 &&
+ case "`git-ls-files --stage xfoo2`" in
+ 100644" "*xfoo2) echo ok;;
+ *) echo fail; git-ls-files --stage xfoo2; exit 1;;
+ esac'
+
test_done
--
1.4.2.1.g7a39b
^ permalink raw reply related
* Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: Junio C Hamano @ 2006-09-27 5:09 UTC (permalink / raw)
To: David Rientjes; +Cc: git
In-Reply-To: <Pine.LNX.4.64N.0609262005150.520@attu4.cs.washington.edu>
David Rientjes <rientjes@cs.washington.edu> writes:
> Again with the constant placement in a comparison expression.
I won't comment on this one. See list archives ;-).
>> if (max_change < width)
>> ;
>> + else if (non_linear_scale) {
>> + total = scale_non_linear(total, width, max_change);
>> + add = scale_linear(add, total, add + del);
>> + del = total - add;
>> + }
>> else {
>> total = scale_linear(total, width, max_change);
>> add = scale_linear(add, width, max_change);
>>
>
> if (...)
> ;
> else if {
> ...
> }
>
> is _never_ necessary.
What's happening here in this particular case is:
if the changes fits within the alloted width
; /* we do not have to do anything */
else if we are using non-linear scale {
scale it like this
}
else {
scale it like that
}
so the code actually matches the flow of thought perfectly well.
I first tried to write it without "if () ;/*empty*/ else" chain
like this:
if given width is narrower than changes we have {
if we are doing non-linear scale {
scale it like this
}
else {
scale it like that
}
}
It made the indentation unnecessarily deep.
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-27 5:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthew L Foster, Jeff King
In-Reply-To: <7v3badkj4k.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Sep 2006 21:50:51 -0700
Junio C Hamano <junkio@cox.net> wrote:
> For somebody who is tracking my "master" branch, it does not
> matter when some critical fix appeared on my "next" branch. The
> user will be vulnerable until that fix makes its way to the
> "master" branch. The user _can_ switch to track my "next"
> branch, but that is like arguing that the user can apply the
> same patch to his local copy that tracks my "master".
>
> I may try-pull from Paul to get updates from gitk, but usually I
> do that with "git fetch", not "git pull". So my repository may
> contain commits and blobs for the latest and greatest gitk, but
> until I merge it and push the result out nobody would benefit
> from it through my repository.
>
> See? Having a commit somewhere in the repository does not make
> any difference unless that commit is on some branches you care
> about.
Well, yes. And all of my examples have assumed the example of
Linus' repository where there is only one branch. So yes, in the
case where there are more than one branch, you want to be able
to ask the more specific question, when did this commit arrive
into this repo-branch.
But that is really the minutia of the issue. First we have to
agree that users _do_ want to know the date of commits beyond
just those recorded inside the commit itself.
If we do agree on that point, then the rest is just the details
of how plausible it is to provide those answers. Shawn has made
it clear that the reflog doesn't really have all the information
we need yet. On top of which it would be expensive to compute
etc.
Sean
^ permalink raw reply
* Re: apply-mbox claiming corrupt patch.
From: Junio C Hamano @ 2006-09-27 5:02 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20060927024628.GA29182@redhat.com>
Dave Jones <davej@redhat.com> writes:
> I tried to apply the mail below to my cpufreq.git tree on master.kernel.org,
> and got ..
>
> $ git-applymbox -k mbox
> 1 patch(es) to process.
>
> Applying '[CPUFREQ] Longhaul - Disable arbiter CLE266'
>
> fatal: corrupt patch at line 99
Like 99 (counting from where mailinfo splits proposed commit log
message and the patch body which is '---' line) is the line
after the closing brace "}" at the end of longhaul_cpu_init()
function.
> @@ -716,7 +739,7 @@ static int __init longhaul_cpu_init(stru
> return 0;
>
> err_acpi:
> - printk(KERN_ERR PFX "No ACPI support for CPU frequency changes.\n");
> + printk(KERN_ERR PFX "No ACPI support. No VT8601 or VT8623 northbridge. Aborting.\n");
> return -ENODEV;
> }
>
>
> ----------------------------------------------------------------------
> Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
The hunk claims to have 7 preimage lines and 7 postimage lines,
so that empty line after the closing brace _is_ part of the
hunk. And an empty context line is SP followed by LF. But the
SP that should be at the beginning of that line does not exist.
In short, you have a corrupt patch.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-27 4:53 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060927042850.GB9460@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> For what its worth I keep meaning to get around to fix receive-pack.c
> but I just haven't done it yet.
I've been futzing around that code because I wanted to make sure
we get the locking right on creation and deletion of refs. I'll
try to remember when I revisit the code tomorrow.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-27 4:50 UTC (permalink / raw)
To: Sean; +Cc: git, Matthew L Foster, Jeff King
In-Reply-To: <BAYC1-PASMTP0819E6B1CBE028BD171598AE1A0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> On Tue, 26 Sep 2006 23:34:59 -0400
> Jeff King <peff@peff.net> wrote:
>
>> Right. So you really want to know not "when did this commit enter this
>> repo" but rather "when did this head/branch first contain this commit"
>> (since there may be multiple branches within a repo).
>
> Even though it's being a bit pedantic, I have to disagree with you here.
> The question the user is asking is exactly, "When did this commit enter
> _this_ repo?".
>
> Because of the design of git, such a question must be converted into a
> question regarding reflogs and head/branch values etc... But the user
> doesn't care anything about all that. They're just interested in the
> date/time the commit was published in the repository in question, not
> the date time the commit was originally created in some distant
> repo.
I disagree.
For somebody who is tracking my "master" branch, it does not
matter when some critical fix appeared on my "next" branch. The
user will be vulnerable until that fix makes its way to the
"master" branch. The user _can_ switch to track my "next"
branch, but that is like arguing that the user can apply the
same patch to his local copy that tracks my "master".
I may try-pull from Paul to get updates from gitk, but usually I
do that with "git fetch", not "git pull". So my repository may
contain commits and blobs for the latest and greatest gitk, but
until I merge it and push the result out nobody would benefit
from it through my repository.
See? Having a commit somewhere in the repository does not make
any difference unless that commit is on some branches you care
about.
^ permalink raw reply
* Re: git and time
From: Shawn Pearce @ 2006-09-27 4:28 UTC (permalink / raw)
To: Sean; +Cc: Jeff King, Matthew L Foster, git
In-Reply-To: <20060926234309.b16aa44e.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Tue, 26 Sep 2006 23:34:59 -0400
> Jeff King <peff@peff.net> wrote:
>
> > Right. So you really want to know not "when did this commit enter this
> > repo" but rather "when did this head/branch first contain this commit"
> > (since there may be multiple branches within a repo).
>
> Even though it's being a bit pedantic, I have to disagree with you here.
> The question the user is asking is exactly, "When did this commit enter
> _this_ repo?".
>
> Because of the design of git, such a question must be converted into a
> question regarding reflogs and head/branch values etc... But the user
> doesn't care anything about all that. They're just interested in the
> date/time the commit was published in the repository in question, not
> the date time the commit was originally created in some distant
> repo.
And with the completely distributed nature of Git I have to say
that's a useful question to get an answer to. Though I believe
Junio pointed out that may be incorrect by several hours for
Linus' public tree due to the mirroring that occurs on kernel.org.
However so long as the existance of that lag is publically stated
I don't really see a problem.
As Junio correctly pointed out answering that question is rather
compute intensive (as Git things go) as you need to compare both
the reflog for the branch in question (or all branches!) against
the commit chain(s) and find where that commit became visible.
Not cheap certainly but possible with the data we have.
However people are ignoring the fact that receive-pack doesn't
update the reflog. As of current `next` its *still* doing the ref
updates by hand, rather than going through the common library code
in refs.c. As a consequence its bypassing the reflog implementation.
This means that `git-push` does not update the reflog. Which means
there's no way Linus' public repository could have a reflog.
Maybe if I (or someone else) fixed receive-pack.c Linus might
consider enabling reflog, and maybe someone could fix gitweb.cgi to
perform the computation - but possibly server owners wouldn't want
that feature running due to its high computation cost. Especially
if gitweb.cgi doesn't have a native C executable to do most of the
work for it.
For what its worth I keep meaning to get around to fix receive-pack.c
but I just haven't done it yet.
--
Shawn.
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-27 3:43 UTC (permalink / raw)
To: Jeff King; +Cc: Matthew L Foster, git
In-Reply-To: <20060927033459.GA27622@coredump.intra.peff.net>
On Tue, 26 Sep 2006 23:34:59 -0400
Jeff King <peff@peff.net> wrote:
> Right. So you really want to know not "when did this commit enter this
> repo" but rather "when did this head/branch first contain this commit"
> (since there may be multiple branches within a repo).
Even though it's being a bit pedantic, I have to disagree with you here.
The question the user is asking is exactly, "When did this commit enter
_this_ repo?".
Because of the design of git, such a question must be converted into a
question regarding reflogs and head/branch values etc... But the user
doesn't care anything about all that. They're just interested in the
date/time the commit was published in the repository in question, not
the date time the commit was originally created in some distant
repo.
Sean
^ permalink raw reply
* Re: [PATCH] gitk: Fix nextfile() and add prevfile()
From: OGAWA Hirofumi @ 2006-09-27 3:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Junio C Hamano
In-Reply-To: <17689.49841.913304.878599@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> OGAWA Hirofumi writes:
>
>> The current nextfile() jumps to last hunk, but I think this is not
>> intention, probably, it's forgetting to add "break;". And this
>> patch also adds prevfile(), it jumps to previous hunk.
>
> I think your prevfile isn't quite right - I don't think it will do the
> right thing if $loc is past the last entry in $difffilestart. Don't
> you want the "$ctext yview $prev" after the loop?
>
> Paul.
Sure, it's obviously useful in the case of big hunk. Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
The current nextfile() jumps to last hunk, but I think this is not
intention, probably, it's forgetting to add "break;". And this
patch also adds prevfile(), it jumps to previous hunk.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---
gitk | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff -puN gitk~gitk-nextfile-fix gitk
--- git/gitk~gitk-nextfile-fix 2006-09-27 12:14:07.000000000 +0900
+++ git-hirofumi/gitk 2006-09-27 12:16:23.000000000 +0900
@@ -4440,12 +4440,27 @@ proc getblobdiffline {bdf ids} {
}
}
+proc prevfile {} {
+ global difffilestart ctext
+ set prev [lindex $difffilestart 0]
+ set here [$ctext index @0,0]
+ foreach loc $difffilestart {
+ if {[$ctext compare $loc >= $here]} {
+ $ctext yview $prev
+ return
+ }
+ set prev $loc
+ }
+ $ctext yview $prev
+}
+
proc nextfile {} {
global difffilestart ctext
set here [$ctext index @0,0]
foreach loc $difffilestart {
if {[$ctext compare $loc > $here]} {
$ctext yview $loc
+ return
}
}
}
_
^ permalink raw reply
* Re: git and time
From: Jeff King @ 2006-09-27 3:34 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <20060927002745.15344.qmail@web51005.mail.yahoo.com>
On Tue, Sep 26, 2006 at 05:27:45PM -0700, Matthew L Foster wrote:
> It's true I don't know much about git, what is the difference between
> a changeset and a snapshot?
I think Linus' explanation covered what I meant, but please ask for
clarification if there was something that didn't make sense.
> Are you saying timestamps should be tracked separately or tracked by
> an scm system built on top of git? Does/should git care about the
> when of a snapshot?
Yes, they could be tracked separately. My point was that git deals in
immutable snapshot objects (commits) and you don't want to change the
commit objects after the fact. You could certainly make an external
mapping of "this commit object entered the repo at local time T" but I
doubt it would be of much use. See below.
> Perhaps my question is directed more toward gitweb.cgi, it seems to me
> the timestamp of when a snapshot was merged into this repository
> should somehow be tracked and that is what gitweb.cgi should default
> to display. For example, if someone wants to know if security bugfix X
> was merged into linus' kernel tree they also want to know when that
> happened, don't they?
Right. So you really want to know not "when did this commit enter this
repo" but rather "when did this head/branch first contain this commit"
(since there may be multiple branches within a repo). We can find out
"does commit X contain commit Y" by looking at the commit graph. The
reflog system records "head H contained commit X at time T" so between
the two you can find the answer to your question (but it takes some
computation).
I think Junio's email explained this better than I could, but again,
please ask if something is unclear.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: David Rientjes @ 2006-09-27 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jan Engelhardt, Linus Torvalds, Adrian Bunk
In-Reply-To: <7vfyeejakq.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Sep 2006, Junio C Hamano wrote:
> @@ -574,10 +585,11 @@ static void show_graph(char ch, int cnt,
> static void show_stats(struct diffstat_t* data, struct diff_options *options)
> {
> int i, len, add, del, total, adds = 0, dels = 0;
> - int max_change = 0, max_len = 0;
> + int max_change = 0, max_len = 0, min_change = 0;
> int total_files = data->nr;
> int width, name_width;
> const char *reset, *set, *add_c, *del_c;
> + int non_linear_scale = 0;
>
> if (data->nr == 0)
> return;
> @@ -620,6 +632,8 @@ static void show_stats(struct diffstat_t
> continue;
> if (max_change < change)
> max_change = change;
> + if (0 < change && (!min_change || change < min_change))
> + min_change = change;
> }
Again with the constant placement in a comparison expression.
> @@ -684,6 +704,11 @@ static void show_stats(struct diffstat_t
>
> if (max_change < width)
> ;
> + else if (non_linear_scale) {
> + total = scale_non_linear(total, width, max_change);
> + add = scale_linear(add, total, add + del);
> + del = total - add;
> + }
> else {
> total = scale_linear(total, width, max_change);
> add = scale_linear(add, width, max_change);
>
if (...)
;
else if {
...
}
is _never_ necessary.
David
^ permalink raw reply
* Re: apply-mbox claiming corrupt patch.
From: Dave Jones @ 2006-09-27 3:14 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <200609262301.12235.len.brown@intel.com>
On Tue, Sep 26, 2006 at 11:01:12PM -0400, Len Brown wrote:
> I ran into a similar problem recently -- though looking
> at the patch below I can't prove it is the exact same problem.
>
> Patch appears to put a space, + or - on each line.
> Somebody edited their patch with kate, and that automatically
> "cleaned up" the lines with just a space on them -- leaving
> them completely blank.
>
> patch ate the result, but git-am (and git-apply) did not.
> fixed it by refreshing with quilt.
Through some more trial and error, it turned out that chopping
off the footer of the email (the last two lines here..)
> > @@ -716,7 +739,7 @@ static int __init longhaul_cpu_init(stru
> > return 0;
> >
> > err_acpi:
> > - printk(KERN_ERR PFX "No ACPI support for CPU frequency changes.\n");
> > + printk(KERN_ERR PFX "No ACPI support. No VT8601 or VT8623 northbridge. Aborting.\n");
> > return -ENODEV;
> > }
> >
> >
> > ----------------------------------------------------------------------
> > Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
Made it all work.
Very strange.
Dave
^ permalink raw reply
* Re: [PATCH 1/3] diff --stat: allow custom diffstat output width.
From: David Rientjes @ 2006-09-27 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adrian Bunk, Linus Torvalds
In-Reply-To: <7vr6xyjal0.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Sep 2006, Junio C Hamano wrote:
> +static void show_graph(char ch, int cnt)
> +{
> + if (!cnt)
> + return;
> + while (cnt--)
> + putchar(ch);
> +}
> +
'if (cnt <= 0)' or 'while (cnt-- > 0)' is a better API./
> +static void show_stats(struct diffstat_t* data, struct diff_options *options)
> {
> int i, len, add, del, total, adds = 0, dels = 0;
> - int max, max_change = 0, max_len = 0;
> + int max_change = 0, max_len = 0;
> int total_files = data->nr;
> + int width, name_width;
>
> if (data->nr == 0)
> return;
>
> + width = options->stat_width ? options->stat_width : 80;
> + name_width = options->stat_name_width ? options->stat_name_width : 50;
> +
> + /* Sanity: give at least 5 columns to the graph,
> + * but leave at least 10 columns for the name.
> + */
> + if (width < name_width + 15) {
> + if (25 < name_width)
> + name_width = width - 15;
> + else
> + width = name_width + 15;
> + }
> +
Constants go on the right side of comparison expressions.
> + /* Find the longest filename and max number of changes */
> for (i = 0; i < data->nr; i++) {
> struct diffstat_file *file = data->files[i];
> + int change = file->added + file->deleted;
> +
> + if (0 < (len = quote_c_style(file->name, NULL, NULL, 0))) {
> + char *qname = xmalloc(len + 1);
> + quote_c_style(file->name, qname, NULL, 0);
> + free(file->name);
> + file->name = qname;
> + }
Same.
> @@ -623,27 +664,34 @@ static void show_stats(struct diffstat_t
> goto free_diffstat_file;
> }
>
> + /*
> + * scale the add/delete
> + */
> add = added;
> del = deleted;
> total = add + del;
> adds += add;
> dels += del;
>
> - if (max_change > 0) {
> - total = (total * max + max_change / 2) / max_change;
> - add = (add * max + max_change / 2) / max_change;
> + if (max_change < width)
> + ;
> + else {
> + total = scale_linear(total, width, max_change);
> + add = scale_linear(add, width, max_change);
> del = total - add;
> }
if (max_change >= width)
> diff --git a/diff.h b/diff.h
> index b60a02e..e06d0f4 100644
> --- a/diff.h
> +++ b/diff.h
> @@ -69,6 +69,9 @@ struct diff_options {
> const char *stat_sep;
> long xdl_opts;
>
> + int stat_width;
> + int stat_name_width;
> +
Can you use unsigned char here instead?
David
^ permalink raw reply
* [PATCH] gitweb: Decode long title for link tooltips
From: Yasushi SHOJI @ 2006-09-27 3:04 UTC (permalink / raw)
To: git
In-Reply-To: <871wpyt3ch.wl@mail2.atmark-techno.com>
This is a simple one liner to decode long title string in perl's
internal form to utf-8 for link tooltips.
This is not crucial if the commit message is all in ASCII, however, if
you decide to use other encoding, such as UTF-8, tooltips ain't
readable any more.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 66be619..597d29f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -617,7 +617,7 @@ sub format_subject_html {
if (length($short) < length($long)) {
return $cgi->a({-href => $href, -class => "list subject",
- -title => $long},
+ -title => decode("utf8", $long, Encode::FB_DEFAULT)},
esc_html($short) . $extra);
} else {
return $cgi->a({-href => $href, -class => "list subject"},
--
1.4.2.1.g83915
^ permalink raw reply related
* Re: [PATCH] gitweb: Escape long title for link tooltips
From: Yasushi SHOJI @ 2006-09-27 3:06 UTC (permalink / raw)
To: git
In-Reply-To: <873baet4ka.wl@mail2.atmark-techno.com>
At Wed, 27 Sep 2006 11:38:10 +0900,
Yasushi SHOJI wrote:
>
> This is a simple one liner to fix the bug not escaping title string
> for link tooltips.
Please void the patch. I'm sending new one.
--
yashi
^ permalink raw reply
* Re: apply-mbox claiming corrupt patch.
From: Len Brown @ 2006-09-27 3:01 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20060927024628.GA29182@redhat.com>
I ran into a similar problem recently -- though looking
at the patch below I can't prove it is the exact same problem.
Patch appears to put a space, + or - on each line.
Somebody edited their patch with kate, and that automatically
"cleaned up" the lines with just a space on them -- leaving
them completely blank.
patch ate the result, but git-am (and git-apply) did not.
fixed it by refreshing with quilt.
-Len
On Tuesday 26 September 2006 22:46, Dave Jones wrote:
> I tried to apply the mail below to my cpufreq.git tree on master.kernel.org,
> and got ..
>
> $ git-applymbox -k mbox
> 1 patch(es) to process.
>
> Applying '[CPUFREQ] Longhaul - Disable arbiter CLE266'
>
> fatal: corrupt patch at line 99
>
> I don't see what the problem is. It applies fine with patch...
>
> (22:44:48:davej@hera:cpufreq)$ cat 1 | patch -p1 --dry-run
> patching file arch/i386/kernel/cpu/cpufreq/longhaul.c
> (22:44:53:davej@hera:cpufreq)$
>
> I'm guessing it didn't like one of the headers, but chopping
> some of them out hasn't seemed to improve things.
>
> Dave
>
>
> >From davej@redhat.com Sun Sep 24 18:31:11 2006
> Return-Path: <davej@redhat.com>
> Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
> by hera.kernel.org (8.13.7/8.13.7) with ESMTP id k8OIUhQv017025
> for <davej@kernel.org>; Sun, 24 Sep 2006 18:31:08 GMT
> Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
> by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k8OIUh5D022511
> for <davej@kernel.org>; Sun, 24 Sep 2006 14:30:43 -0400
> Received: from pressure.kernelslacker.org (vpn-248-6.boston.redhat.com [10.13.248.6])
> by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k8OIUgGp026807
> for <davej@kernel.org>; Sun, 24 Sep 2006 14:30:42 -0400
> Received: from pressure.kernelslacker.org (localhost.localdomain [127.0.0.1])
> by pressure.kernelslacker.org (8.13.8/8.13.8) with ESMTP id k8OIUfs6013171
> for <davej@kernel.org>; Sun, 24 Sep 2006 14:30:41 -0400
> Received: (from davej@localhost)
> by pressure.kernelslacker.org (8.13.8/8.13.8/Submit) id k8OIUfjO013170
> for davej@kernel.org; Sun, 24 Sep 2006 14:30:41 -0400
> Resent-Message-Id: <200609241830.k8OIUfjO013170@pressure.kernelslacker.org>
> X-Authentication-Warning: pressure.kernelslacker.org: davej set sender to davej@redhat.com using -f
> X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on hera.kernel.org
> X-Spam-Level:
> X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
> FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.3
> Received: from pobox.devel.redhat.com [10.11.255.8]
> by pressure.kernelslacker.org with IMAP (fetchmail-6.3.4)
> for <davej@localhost> (single-drop); Sun, 24 Sep 2006 14:19:33 -0400 (EDT)
> Received: from pobox.devel.redhat.com ([unix socket])
> by pobox.devel.redhat.com (Cyrus v2.2.12-Invoca-RPM-2.2.12-3.RHEL4.1) with LMTPA;
> Sun, 24 Sep 2006 14:19:00 -0400
> X-Sieve: CMU Sieve 2.2
> Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
> by pobox.devel.redhat.com (8.13.1/8.13.1) with ESMTP id k8OIIxSA032250
> for <davej@pobox.devel.redhat.com>; Sun, 24 Sep 2006 14:19:00 -0400
> Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32])
> by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k8OIIxG3022438
> for <davej@redhat.com>; Sun, 24 Sep 2006 14:18:59 -0400
> Received: from smtp4.poczta.interia.pl (smtp11.poczta.interia.pl [80.48.65.11])
> by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k8OIIpQq020496
> for <davej@redhat.com>; Sun, 24 Sep 2006 14:18:51 -0400
> Received: by smtp4.poczta.interia.pl (INTERIA.PL, from userid 502)
> id 85328D228F; Sun, 24 Sep 2006 20:18:50 +0200 (CEST)
> Received: from poczta.interia.pl (mi02.poczta.interia.pl [10.217.12.2])
> by smtp4.poczta.interia.pl (INTERIA.PL) with ESMTP id DFEF4D2265;
> Sun, 24 Sep 2006 20:18:49 +0200 (CEST)
> Received: by poczta.interia.pl (INTERIA.PL, from userid 502)
> id D1C072BD043; Sun, 24 Sep 2006 20:18:49 +0200 (CEST)
> Received: from [172.16.5.114] (unknown [81.15.157.150])
> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> (No client certificate requested)
> by poczta.interia.pl (INTERIA.PL) with ESMTP id ECF6C2BD0BC;
> Sun, 24 Sep 2006 20:18:45 +0200 (CEST)
> Message-ID: <4516CE3D.5050101@interia.pl>
> Date: Sun, 24 Sep 2006 20:28:13 +0200
> From: =?ISO-8859-2?Q?Rafa=B3_Bilski?= <rafalbilski@interia.pl>
> User-Agent: Thunderbird 1.5.0.5 (X11/20060805)
> MIME-Version: 1.0
> To: Dave Jones <davej@redhat.com>
> Cc: cpufreq@lists.linux.org.uk
> Subject: [CPUFREQ] Longhaul - Disable arbiter CLE266
> X-Enigmail-Version: 0.94.0.0
> Content-Type: text/plain; charset=ISO-8859-2
> Content-Transfer-Encoding: 8bit
> X-EMID: d25b6acc
> X-RedHat-Spam-Score: 0
> Resent-From: davej@redhat.com
> Resent-Date: Sun, 24 Sep 2006 14:30:41 -0400
> Resent-To: davej@kernel.org
> X-Virus-Scanned: ClamAV 0.88.4/1931/Sun Sep 24 07:51:08 2006 on hera.kernel.org
> X-Virus-Status: Clean
> Status: RO
> Content-Length: 3399
> Lines: 114
>
> Please ignore previous message.
>
> This patch is adding support for CPU connected to CLE266
> chipset. For older CPU this is only way. For "Powersaver"
> processor this way will be used if ACPI C3 isn't supported.
>
> I have tested it. It seems to work exacly like ACPI.
> But it is less safe. On CLE266 chipset port 0x22 is
> blocking processor access to PCI bus too.
>
> Signed-off-by: Rafa³ Bilski <rafalbilski@interia.pl>
> Signed-off-by: Dave Jones <davej@redhat.com>
>
> ---
>
> diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
> --- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
> +++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
> @@ -178,11 +178,17 @@ static void do_powersaver(int cx_address
> safe_halt();
> /* Change frequency on next halt or sleep */
> wrmsrl(MSR_VIA_LONGHAUL, longhaul.val);
> - ACPI_FLUSH_CPU_CACHE();
> - /* Invoke C3 */
> - inb(cx_address);
> - /* Dummy op - must do something useless after P_LVL3 read */
> - t = inl(acpi_fadt.xpm_tmr_blk.address);
> + if (port22_en) {
> + ACPI_FLUSH_CPU_CACHE();
> + /* Invoke C1 */
> + halt();
> + } else {
> + ACPI_FLUSH_CPU_CACHE();
> + /* Invoke C3 */
> + inb(cx_address);
> + /* Dummy op - must do something useless after P_LVL3 read */
> + t = inl(acpi_fadt.xpm_tmr_blk.address);
> + }
>
> /* Disable bus ratio bit */
> local_irq_disable();
> @@ -567,16 +573,23 @@ static acpi_status longhaul_walk_callbac
> static int enable_arbiter_disable(void)
> {
> struct pci_dev *dev;
> + int reg;
> u8 pci_cmd;
>
> /* Find PLE133 host bridge */
> + reg = 0x78;
> dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8601_0, NULL);
> + /* Find CLE266 host bridge */
> + if (dev == NULL) {
> + dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_862X_0, NULL);
> + reg = 0x76;
> + }
> if (dev != NULL) {
> /* Enable access to port 0x22 */
> - pci_read_config_byte(dev, 0x78, &pci_cmd);
> + pci_read_config_byte(dev, reg, &pci_cmd);
> if ( !(pci_cmd & 1<<7) ) {
> pci_cmd |= 1<<7;
> - pci_write_config_byte(dev, 0x78, pci_cmd);
> + pci_write_config_byte(dev, reg, pci_cmd);
> }
> return 1;
> }
> @@ -681,19 +694,29 @@ static int __init longhaul_cpu_init(stru
> /* Check ACPI support for C3 state */
> cx = &pr->power.states[ACPI_STATE_C3];
> if (cx->address == 0 ||
> - (cx->latency > 1000 && ignore_latency == 0) )
> - goto err_acpi;
> + (cx->latency > 1000 && ignore_latency == 0) ) {
> + if (enable_arbiter_disable()) {
> + port22_en = 1;
> + } else {
> + goto err_acpi;
> + }
> + }
>
> } else {
> /* Check ACPI support for bus master arbiter disable */
> if (!pr->flags.bm_control) {
> - if (!enable_arbiter_disable()) {
> - printk(KERN_ERR PFX "No ACPI support. No VT8601 host bridge. Aborting.\n");
> - return -ENODEV;
> - } else
> + if (enable_arbiter_disable()) {
> port22_en = 1;
> + } else {
> + goto err_acpi;
> + }
> }
> }
> + if (!port22_en) {
> + printk (KERN_INFO PFX "Using ACPI support.\n");
> + } else {
> + printk (KERN_INFO PFX "Using northbridge support.\n");
> + }
>
> ret = longhaul_get_ranges();
> if (ret != 0)
> @@ -716,7 +739,7 @@ static int __init longhaul_cpu_init(stru
> return 0;
>
> err_acpi:
> - printk(KERN_ERR PFX "No ACPI support for CPU frequency changes.\n");
> + printk(KERN_ERR PFX "No ACPI support. No VT8601 or VT8623 northbridge. Aborting.\n");
> return -ENODEV;
> }
>
>
> ----------------------------------------------------------------------
> Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* apply-mbox claiming corrupt patch.
From: Dave Jones @ 2006-09-27 2:46 UTC (permalink / raw)
To: git
I tried to apply the mail below to my cpufreq.git tree on master.kernel.org,
and got ..
$ git-applymbox -k mbox
1 patch(es) to process.
Applying '[CPUFREQ] Longhaul - Disable arbiter CLE266'
fatal: corrupt patch at line 99
I don't see what the problem is. It applies fine with patch...
(22:44:48:davej@hera:cpufreq)$ cat 1 | patch -p1 --dry-run
patching file arch/i386/kernel/cpu/cpufreq/longhaul.c
(22:44:53:davej@hera:cpufreq)$
I'm guessing it didn't like one of the headers, but chopping
some of them out hasn't seemed to improve things.
Dave
From davej@redhat.com Sun Sep 24 18:31:11 2006
Return-Path: <davej@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
by hera.kernel.org (8.13.7/8.13.7) with ESMTP id k8OIUhQv017025
for <davej@kernel.org>; Sun, 24 Sep 2006 18:31:08 GMT
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k8OIUh5D022511
for <davej@kernel.org>; Sun, 24 Sep 2006 14:30:43 -0400
Received: from pressure.kernelslacker.org (vpn-248-6.boston.redhat.com [10.13.248.6])
by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k8OIUgGp026807
for <davej@kernel.org>; Sun, 24 Sep 2006 14:30:42 -0400
Received: from pressure.kernelslacker.org (localhost.localdomain [127.0.0.1])
by pressure.kernelslacker.org (8.13.8/8.13.8) with ESMTP id k8OIUfs6013171
for <davej@kernel.org>; Sun, 24 Sep 2006 14:30:41 -0400
Received: (from davej@localhost)
by pressure.kernelslacker.org (8.13.8/8.13.8/Submit) id k8OIUfjO013170
for davej@kernel.org; Sun, 24 Sep 2006 14:30:41 -0400
Resent-Message-Id: <200609241830.k8OIUfjO013170@pressure.kernelslacker.org>
X-Authentication-Warning: pressure.kernelslacker.org: davej set sender to davej@redhat.com using -f
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on hera.kernel.org
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.3
Received: from pobox.devel.redhat.com [10.11.255.8]
by pressure.kernelslacker.org with IMAP (fetchmail-6.3.4)
for <davej@localhost> (single-drop); Sun, 24 Sep 2006 14:19:33 -0400 (EDT)
Received: from pobox.devel.redhat.com ([unix socket])
by pobox.devel.redhat.com (Cyrus v2.2.12-Invoca-RPM-2.2.12-3.RHEL4.1) with LMTPA;
Sun, 24 Sep 2006 14:19:00 -0400
X-Sieve: CMU Sieve 2.2
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
by pobox.devel.redhat.com (8.13.1/8.13.1) with ESMTP id k8OIIxSA032250
for <davej@pobox.devel.redhat.com>; Sun, 24 Sep 2006 14:19:00 -0400
Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32])
by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k8OIIxG3022438
for <davej@redhat.com>; Sun, 24 Sep 2006 14:18:59 -0400
Received: from smtp4.poczta.interia.pl (smtp11.poczta.interia.pl [80.48.65.11])
by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k8OIIpQq020496
for <davej@redhat.com>; Sun, 24 Sep 2006 14:18:51 -0400
Received: by smtp4.poczta.interia.pl (INTERIA.PL, from userid 502)
id 85328D228F; Sun, 24 Sep 2006 20:18:50 +0200 (CEST)
Received: from poczta.interia.pl (mi02.poczta.interia.pl [10.217.12.2])
by smtp4.poczta.interia.pl (INTERIA.PL) with ESMTP id DFEF4D2265;
Sun, 24 Sep 2006 20:18:49 +0200 (CEST)
Received: by poczta.interia.pl (INTERIA.PL, from userid 502)
id D1C072BD043; Sun, 24 Sep 2006 20:18:49 +0200 (CEST)
Received: from [172.16.5.114] (unknown [81.15.157.150])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by poczta.interia.pl (INTERIA.PL) with ESMTP id ECF6C2BD0BC;
Sun, 24 Sep 2006 20:18:45 +0200 (CEST)
Message-ID: <4516CE3D.5050101@interia.pl>
Date: Sun, 24 Sep 2006 20:28:13 +0200
From: =?ISO-8859-2?Q?Rafa=B3_Bilski?= <rafalbilski@interia.pl>
User-Agent: Thunderbird 1.5.0.5 (X11/20060805)
MIME-Version: 1.0
To: Dave Jones <davej@redhat.com>
Cc: cpufreq@lists.linux.org.uk
Subject: [CPUFREQ] Longhaul - Disable arbiter CLE266
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 8bit
X-EMID: d25b6acc
X-RedHat-Spam-Score: 0
Resent-From: davej@redhat.com
Resent-Date: Sun, 24 Sep 2006 14:30:41 -0400
Resent-To: davej@kernel.org
X-Virus-Scanned: ClamAV 0.88.4/1931/Sun Sep 24 07:51:08 2006 on hera.kernel.org
X-Virus-Status: Clean
Status: RO
Content-Length: 3399
Lines: 114
Please ignore previous message.
This patch is adding support for CPU connected to CLE266
chipset. For older CPU this is only way. For "Powersaver"
processor this way will be used if ACPI C3 isn't supported.
I have tested it. It seems to work exacly like ACPI.
But it is less safe. On CLE266 chipset port 0x22 is
blocking processor access to PCI bus too.
Signed-off-by: Rafa³ Bilski <rafalbilski@interia.pl>
Signed-off-by: Dave Jones <davej@redhat.com>
---
diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -178,11 +178,17 @@ static void do_powersaver(int cx_address
safe_halt();
/* Change frequency on next halt or sleep */
wrmsrl(MSR_VIA_LONGHAUL, longhaul.val);
- ACPI_FLUSH_CPU_CACHE();
- /* Invoke C3 */
- inb(cx_address);
- /* Dummy op - must do something useless after P_LVL3 read */
- t = inl(acpi_fadt.xpm_tmr_blk.address);
+ if (port22_en) {
+ ACPI_FLUSH_CPU_CACHE();
+ /* Invoke C1 */
+ halt();
+ } else {
+ ACPI_FLUSH_CPU_CACHE();
+ /* Invoke C3 */
+ inb(cx_address);
+ /* Dummy op - must do something useless after P_LVL3 read */
+ t = inl(acpi_fadt.xpm_tmr_blk.address);
+ }
/* Disable bus ratio bit */
local_irq_disable();
@@ -567,16 +573,23 @@ static acpi_status longhaul_walk_callbac
static int enable_arbiter_disable(void)
{
struct pci_dev *dev;
+ int reg;
u8 pci_cmd;
/* Find PLE133 host bridge */
+ reg = 0x78;
dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8601_0, NULL);
+ /* Find CLE266 host bridge */
+ if (dev == NULL) {
+ dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_862X_0, NULL);
+ reg = 0x76;
+ }
if (dev != NULL) {
/* Enable access to port 0x22 */
- pci_read_config_byte(dev, 0x78, &pci_cmd);
+ pci_read_config_byte(dev, reg, &pci_cmd);
if ( !(pci_cmd & 1<<7) ) {
pci_cmd |= 1<<7;
- pci_write_config_byte(dev, 0x78, pci_cmd);
+ pci_write_config_byte(dev, reg, pci_cmd);
}
return 1;
}
@@ -681,19 +694,29 @@ static int __init longhaul_cpu_init(stru
/* Check ACPI support for C3 state */
cx = &pr->power.states[ACPI_STATE_C3];
if (cx->address == 0 ||
- (cx->latency > 1000 && ignore_latency == 0) )
- goto err_acpi;
+ (cx->latency > 1000 && ignore_latency == 0) ) {
+ if (enable_arbiter_disable()) {
+ port22_en = 1;
+ } else {
+ goto err_acpi;
+ }
+ }
} else {
/* Check ACPI support for bus master arbiter disable */
if (!pr->flags.bm_control) {
- if (!enable_arbiter_disable()) {
- printk(KERN_ERR PFX "No ACPI support. No VT8601 host bridge. Aborting.\n");
- return -ENODEV;
- } else
+ if (enable_arbiter_disable()) {
port22_en = 1;
+ } else {
+ goto err_acpi;
+ }
}
}
+ if (!port22_en) {
+ printk (KERN_INFO PFX "Using ACPI support.\n");
+ } else {
+ printk (KERN_INFO PFX "Using northbridge support.\n");
+ }
ret = longhaul_get_ranges();
if (ret != 0)
@@ -716,7 +739,7 @@ static int __init longhaul_cpu_init(stru
return 0;
err_acpi:
- printk(KERN_ERR PFX "No ACPI support for CPU frequency changes.\n");
+ printk(KERN_ERR PFX "No ACPI support. No VT8601 or VT8623 northbridge. Aborting.\n");
return -ENODEV;
}
----------------------------------------------------------------------
Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-27 2:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Lang, git
In-Reply-To: <7vhcyukpkc.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Sep 2006 19:31:47 -0700
Junio C Hamano <junkio@cox.net> wrote:
> Only when somebody is interested in the particular question
> "when did this commit has become part of this branch" it becomes
> relevant. And do not get me wrong. I am in principle agreeing
> with you that this is an extra information for most of the time
> -- I even doubt "when did this commit has become part of this
> branch" is all that useful.
It is interesting information for some people though. For instance
someone wondering how long ago Linus published a certain security fix.
To be able to say to easily query gitweb and be able to report,
"Linus published that security fix X day ago etc.."
Of course, I agree with you that also knowing the revision number
such a commit appeared in is at least if not more important. But
still I don't dismiss this date/time based question as completely
as you do. The very fact that a gitweb user has brought this issue
forward (and this isn't the first time) suggests the information
is at least of casual interest to some people.
Sean
^ permalink raw reply
* [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: Junio C Hamano @ 2006-09-27 2:40 UTC (permalink / raw)
To: git; +Cc: Jan Engelhardt, Linus Torvalds, Adrian Bunk
When some files have big changes and others are touched only
slightly, diffstat graph did not show differences among smaller
changes that well. This changes the graph scaling to non-linear
algorithm in such a case.
Without this, "git show --stat fd88d9c" gives:
.gitignore | 1
Documentation/git-tar-tree.txt | 3 +
Documentation/git-upload-tar.txt | 39 -----------
Documentation/git.txt | 4 -
Makefile | 1
builtin-tar-tree.c | 130 +++++++++++++++-----------------------
builtin-upload-tar.c | 74 ----------------------
git.c | 1
8 files changed, 53 insertions(+), 200 deletions(-)
while with this, it shows:
.gitignore | 1
Documentation/git-tar-tree.txt | 3 +++++++++
Documentation/git-upload-tar.txt | 39 -----------------------------
Documentation/git.txt | 4 -----------
Makefile | 1
builtin-tar-tree.c | 130 +++++++++++++++-----------------------
builtin-upload-tar.c | 74 ----------------------------------
git.c | 1
8 files changed, 53 insertions(+), 200 deletions(-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Jan Engelhardt wondered about doing non-linear scaling on the
kernel list and this is an experimental patch to do so. I do
not seriously consider this for inclusion but it is more of a
"see if people like it" patch.
Makefile | 2 +-
diff.c | 29 +++++++++++++++++++++++++++--
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 28091d6..0fc59c4 100644
--- a/Makefile
+++ b/Makefile
@@ -304,7 +304,7 @@ BUILTIN_OBJS = \
builtin-write-tree.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
-LIBS = $(GITLIBS) -lz
+LIBS = $(GITLIBS) -lz -lm
#
# Platform specific tweaks
diff --git a/diff.c b/diff.c
index 13aac2d..163ef48 100644
--- a/diff.c
+++ b/diff.c
@@ -4,6 +4,7 @@
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>
+#include <math.h>
#include "cache.h"
#include "quote.h"
#include "diff.h"
@@ -555,6 +556,16 @@ static int scale_linear(int it, int widt
return (it * width * 2 + max_change) / (max_change * 2);
}
+static int scale_non_linear(int it, int width, int max_change)
+{
+ /*
+ * round(width * log(it)/log(max_change))
+ */
+ if (!it || !max_change)
+ return 0;
+ return (int)(0.5 + width * log(it) / log(max_change));
+}
+
static void show_name(const char *prefix, const char *name, int len,
const char *reset, const char *set)
{
@@ -574,10 +585,11 @@ static void show_graph(char ch, int cnt,
static void show_stats(struct diffstat_t* data, struct diff_options *options)
{
int i, len, add, del, total, adds = 0, dels = 0;
- int max_change = 0, max_len = 0;
+ int max_change = 0, max_len = 0, min_change = 0;
int total_files = data->nr;
int width, name_width;
const char *reset, *set, *add_c, *del_c;
+ int non_linear_scale = 0;
if (data->nr == 0)
return;
@@ -595,12 +607,12 @@ static void show_stats(struct diffstat_t
width = name_width + 15;
}
- /* Find the longest filename and max number of changes */
reset = diff_get_color(options->color_diff, DIFF_RESET);
set = diff_get_color(options->color_diff, DIFF_PLAIN);
add_c = diff_get_color(options->color_diff, DIFF_FILE_NEW);
del_c = diff_get_color(options->color_diff, DIFF_FILE_OLD);
+ /* Find the longest filename and max/min number of changes */
for (i = 0; i < data->nr; i++) {
struct diffstat_file *file = data->files[i];
int change = file->added + file->deleted;
@@ -620,6 +632,8 @@ static void show_stats(struct diffstat_t
continue;
if (max_change < change)
max_change = change;
+ if (0 < change && (!min_change || change < min_change))
+ min_change = change;
}
/* Compute the width of the graph part;
@@ -635,6 +649,12 @@ static void show_stats(struct diffstat_t
else
width = max_change;
+ /* See if the minimum change is shown with the normal scale
+ * and if not switch to non-linear scale
+ */
+ if (min_change && !scale_linear(min_change, width, max_change))
+ non_linear_scale = 1;
+
for (i = 0; i < data->nr; i++) {
const char *prefix = "";
char *name = data->files[i]->name;
@@ -684,6 +704,11 @@ static void show_stats(struct diffstat_t
if (max_change < width)
;
+ else if (non_linear_scale) {
+ total = scale_non_linear(total, width, max_change);
+ add = scale_linear(add, total, add + del);
+ del = total - add;
+ }
else {
total = scale_linear(total, width, max_change);
add = scale_linear(add, width, max_change);
--
1.4.2.1.gf80a
^ permalink raw reply related
* [PATCH 2/3] diff --stat: color output.
From: Junio C Hamano @ 2006-09-27 2:40 UTC (permalink / raw)
To: git
Under --color option, diffstat shows '+' and '-' in the graph
the same color as added and deleted lines.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is unsolicited but while I was touching the vicinity of
the code I thought some people might find it cool.
diff.c | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/diff.c b/diff.c
index 6101365..13aac2d 100644
--- a/diff.c
+++ b/diff.c
@@ -555,17 +555,20 @@ static int scale_linear(int it, int widt
return (it * width * 2 + max_change) / (max_change * 2);
}
-static void show_name(const char *prefix, const char *name, int len)
+static void show_name(const char *prefix, const char *name, int len,
+ const char *reset, const char *set)
{
- printf(" %s%-*s |", prefix, len, name);
+ printf(" %s%s%-*s%s |", set, prefix, len, name, reset);
}
-static void show_graph(char ch, int cnt)
+static void show_graph(char ch, int cnt, const char *set, const char *reset)
{
if (!cnt)
return;
+ printf("%s", set);
while (cnt--)
putchar(ch);
+ printf("%s", reset);
}
static void show_stats(struct diffstat_t* data, struct diff_options *options)
@@ -574,6 +577,7 @@ static void show_stats(struct diffstat_t
int max_change = 0, max_len = 0;
int total_files = data->nr;
int width, name_width;
+ const char *reset, *set, *add_c, *del_c;
if (data->nr == 0)
return;
@@ -592,6 +596,11 @@ static void show_stats(struct diffstat_t
}
/* Find the longest filename and max number of changes */
+ reset = diff_get_color(options->color_diff, DIFF_RESET);
+ set = diff_get_color(options->color_diff, DIFF_PLAIN);
+ add_c = diff_get_color(options->color_diff, DIFF_FILE_NEW);
+ del_c = diff_get_color(options->color_diff, DIFF_FILE_OLD);
+
for (i = 0; i < data->nr; i++) {
struct diffstat_file *file = data->files[i];
int change = file->added + file->deleted;
@@ -649,12 +658,12 @@ static void show_stats(struct diffstat_t
}
if (data->files[i]->is_binary) {
- show_name(prefix, name, len);
+ show_name(prefix, name, len, reset, set);
printf(" Bin\n");
goto free_diffstat_file;
}
else if (data->files[i]->is_unmerged) {
- show_name(prefix, name, len);
+ show_name(prefix, name, len, reset, set);
printf(" Unmerged\n");
goto free_diffstat_file;
}
@@ -680,18 +689,18 @@ static void show_stats(struct diffstat_t
add = scale_linear(add, width, max_change);
del = total - add;
}
- show_name(prefix, name, len);
+ show_name(prefix, name, len, reset, set);
printf("%5d ", added + deleted);
- show_graph('+', add);
- show_graph('-', del);
+ show_graph('+', add, add_c, reset);
+ show_graph('-', del, del_c, reset);
putchar('\n');
free_diffstat_file:
free(data->files[i]->name);
free(data->files[i]);
}
free(data->files);
- printf(" %d files changed, %d insertions(+), %d deletions(-)\n",
- total_files, adds, dels);
+ printf("%s %d files changed, %d insertions(+), %d deletions(-)%s\n",
+ set, total_files, adds, dels, reset);
}
struct checkdiff_t {
--
1.4.2.1.gf80a
^ permalink raw reply related
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