* Re: Stupid quoting...
From: Junio C Hamano @ 2007-06-20 6:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0706200307070.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I don't see our discourse leading anywhere: the points have been made.
>
> I would really, really, really like to see a solution. Alas, I cannot
> think of one, other than _forcing_ the developers to use ASCII-only
> filenames.
>
> Note that there is no convention yet in Git to state which encoding your
> filenames are supposed to use. And in fact, we already had a fine example
> in git.git why this is particularly difficult. MacOSX is too clever to be
> true, in that it gladly takes filenames in one encoding, but reads those
> filenames out in _another_ encoding. Thus, a "git add <filename>" can well
> end up in git-status saying that a file was deleted, and another file
> (actually the same, but in a different encoding) is untracked.
By the way, the pathname quoting done by "diff" does not even
attempt to tackle that. I already explained why in the thread
so I would not repeat myself.
Having said that, the absolute minimum that needs to be quoted
are double-quote (because it is used by quoting as agreed with
GNU diff/patch maintainer), backslash (used to introduce C-like
quoting), newline and horizontal tab (makes "patch" confused, as
it would make it ambiguous where the pathname ends), so I am not
opposed to a patch that introduces a new mode, probably on by
default _unless_ we are generating --format=email, that does not
quote high byte values. That would solve "My UTF-8 filenames
are unreadable on my terminal" problem.
^ permalink raw reply
* Re: [PATCH 1/3] Accept root <tree-ish> in 'git-svn commit-diff'
From: Eric Wong @ 2007-06-20 6:25 UTC (permalink / raw)
To: Sergey Yanovich; +Cc: git, J.Sixt, masterdriverz
In-Reply-To: <cff8d32813e43d9e1c75ad50824d95dbcd6f669c.1182235491.git.ynvich@gmail.com>
Sergey Yanovich <ynvich@gmail.com> wrote:
> Experiments with Subversion (my version is 1.4.2) show that it is
> not necessary to call 'svn import' before the first commit. Contrarily
> to the Subversion documentation, first commit may be done even when
> Subversion repository is at revision 0.
>
> This allow export the whole git branch to a Subversion repo using only
> 'git-svn commit-diff'. Before this patch, however, 'git-svn' had
> no means to operate on root commits.
Cool.
> Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
> ---
> git-svn.perl | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 50128d7..8ad291b 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -2572,7 +2572,12 @@ sub generate_diff {
> }
> push @diff_tree, '--find-copies-harder' if $_find_copies_harder;
> push @diff_tree, "-l$_rename_limit" if defined $_rename_limit;
> - push @diff_tree, $tree_a, $tree_b;
> + if ($tree_a eq '0000000000000000000000000000000000000000') {
You can make this more legible by using '0' x40 instead of repeating
40 '0' characters. Also, it might be a good idea to support --root
directly for git-svn so the user won't have to type 40 zeroes in the
command-line :)
> + push @diff_tree, '--root';
> + } else {
> + push @diff_tree, $tree_a;
> + }
> + push @diff_tree, $tree_b;
> my ($diff_fh, $ctx) = command_output_pipe(@diff_tree);
> local $/ = "\0";
> my $state = 'meta';
> @@ -2606,6 +2611,8 @@ sub generate_diff {
> }
> $x->{file_b} = $_;
> $state = 'meta';
> + } elsif ($state eq 'meta' && $_ eq $tree_b &&
> + $tree_a eq '0000000000000000000000000000000000000000') {
Same here with '0' x40
> } else {
> croak "Error parsing $_\n";
> }
> --
> 1.5.2.1
>
--
Eric Wong
^ permalink raw reply
* Re: Finally implement "git log --follow"
From: Marco Costalba @ 2007-06-20 6:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706191358180.3593@woody.linux-foundation.org>
On 6/19/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Ok, I've really held off doing this too damn long, because I'm lazy, and I
> was always hoping that somebody else would do it.
>
> But no, people keep asking for it, but nobody actually did anything, so I
> decided I might as well bite the bullet, and instead of telling people
> they could add a "--follow" flag to "git log" to do what they want to do,
> I decided that it looks like I just have to do it for them..
>
Thanks,
now I have one more reason to switch from using git-rev-list to
git-log in qgit, file history annotation, that is currently based on
git-rev-list, will automatically gain a powerful feature.
Marco
P.S: The only thing that is still missing in git-log against
git-rev-list is a --stdin option. This is needed because with 40 chars
SHA the command line could became very long in case of repos with many
tags/branches or when loading StGIT unapplied patches (one sha per
patch) and one git-rev-list call to loading them all.
Without --stdin we break easily on _some_ OS and in the worst cases (a
lot of unapplied patches) *even* under Linux.
^ permalink raw reply
* Re: [PATCH 2/3] 'git-svndump'
From: Eric Wong @ 2007-06-20 6:40 UTC (permalink / raw)
To: Sergey Yanovich; +Cc: git, J.Sixt, masterdriverz
In-Reply-To: <7d5543ebd8ac45e49a6d3f300e988189561512f1.1182235492.git.ynvich@gmail.com>
Sergey Yanovich <ynvich@gmail.com> wrote:
> A git tool to keep a subversion mirror
>
> git-svndump is essentially a wrapper around 'git-svn commit-diff'. It
> will work only when it is the sole method of committing to the
> Subversion repository.
We could probably just implement this directly in git-svn. I'll try to
find time to take a closer look at it this weekend or the next if I
don't have time. If you or anybody else feel comfortable doing more
work in Perl, feel free to go ahead with it.
> It is designed to export a linear git branch. However, thanks to the way
> 'git' handles source code, 'git-svndump' seems to work in other
> conditions. For example, when branches are switched or merged.
>
> git-svndump provides a solution when you need to export your source code
> in Subversion format (who would need this with git :), but do not want
> to have all the shackles that 'git-svn init' puts on your repository.
> Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
> ---
> Documentation/git-svndump.txt | 97 ++++++++++++++++++++++++++++++++++++++++
> Makefile | 1 +
> git-svndump-init.sh | 85 +++++++++++++++++++++++++++++++++++
> git-svndump-sync.sh | 98 +++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 281 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/git-svndump.txt
> create mode 100755 git-svndump-init.sh
> create mode 100755 git-svndump-sync.sh
I'm really not excited about having even more shell scripts in git.
--
Eric Wong
^ permalink raw reply
* post-update script to update wc - suggestions welcome
From: Sam Vilain @ 2007-06-20 6:21 UTC (permalink / raw)
To: git
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, make this file executable by "chmod +x post-update".
git-update-server-info
ref=$1
active=`git-symbolic-ref HEAD`
if [ "$ref" = "$active" ]
then
echo "Pushing to checked out branch - updating working copy" >&2
export GIT_DIR=`cd $GIT_DIR; pwd`
cd ..
success=
if git-diff-files
then
git-diff-index -z -R --name-status HEAD | perl -n0 -le \
'if ($z^=1) {
$status=$_;
}
else {
$filename=$_;
printf STDERR "$status\t$filename\n";
if($status eq "D"){
unlink($filename)
or die("unlink($filename) failed; $!")
}
}' &&
git-reset --hard HEAD && success=1
fi
if [ -z "$success" ]
then
(
echo "Non-bare repository checkout is not clean - not updating it"
echo "However I AM going to update the index. Any in-progress commit"
echo "happening in that checkout will be thrown away, but on the bright"
echo "side this is probably the least confusing thing for us to do and"
echo "at least we're not throwing any files somebody has changed away"
git-reset --mixed HEAD
echo
echo "This is the new status of the upstream working copy:"
git-status
) >&2
fi
fi
^ permalink raw reply
* Re: [PATCH] git-svn: allow dcommit to retain local merge information
From: Eric Wong @ 2007-06-20 6:56 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <1181754781.30670.323.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:
> > dcommit will still rewrite the HEAD commit and the history of the first
> > parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.
> >
> > However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be
> > preserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN
> > with dcommit. Commits written to SVN will still not have any merge
> > information besides anything in the commit message.
> >
> > Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm
> > for explanations, feedback, examples and test case.
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
> > ---
> >
> > This is a better patch that replaces the previous one.
> >
> > Junio:
> > This one is a big change and should probably sit in pu or next
> > for a bit. Double-checking the logic in linearize_history()
> > would be greatly appreciated, too.
> >
> > I don't think there are any regressions for the
> > already-linear-history case besides slightly reduced performance for
> > new calls to cat-file.
> >
> > Joakim/Steven:
> > Any further testing and test cases would be appreciated. Be very
> > careful with real-world repositories, and run dcommit with the
> > '-n' flag before actually committing to verify the diffs are sane.
> >
> > Thanks
> >
>
> Did a little testing and so far it looks good :)
>
> Sidenote:
> Doing this
> git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo
> git-svn fetch --quiet
> makes git svn fetch stop for rather long periods in do_update:
> Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2
> Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8
> Following parent with do_update
> Successfully followed parent
>
> Is it possible to speed up do_update?
Use a do_switch()-enabled SVN to avoid do_update(). do_update will
redownload everything. I have patched 1.4.3 debian packages with source
and a diff here: http://git-svn.bogomips.org/svn. SVN 1.4.4 claims to
have fixed the bindings, but 1.4.3 claimed the same thing, too...
Confirmation of it working in SVN 1.4.4 would be nice.
> Lastly, when adding the above u-boot svn repo into a fresh u-boot
> clone from WD, can I attach the svn tree to git u-boot tree without
> using a graft?
Not with the current version. The 1.5.0 (or previous, I forget) allowed
forced-parenting with: "git-svn fetch <rev>=<commit>" but I figured
nobody was using it, and it would be difficult to get working since
fetch can now works on multiple trees and the same revision numbers can
appear in multiple trees.
> I want to be able to recreate my own git repo by cloning the orginal
> u-boot repo and the svn repo.
--
Eric Wong
^ permalink raw reply
* Re: post-update script to update wc - suggestions welcome
From: Sam Vilain @ 2007-06-20 7:03 UTC (permalink / raw)
To: git
In-Reply-To: <E1I0tZY-0001Uz-00@www.watts.utsl.gen.nz>
Sam Vilain wrote:
> #!/bin/sh
> #
> # An example hook script to prepare a packed repository for use over
> # dumb transports.
> #
> # To enable this hook, make this file executable by "chmod +x post-update".
>
> git-update-server-info
>
> ref=$1
In particular, if anyone can think of a clever and reliable way to
detect whether the repository is bare or not (perhaps the presence of
$GIT_DIR/index ?), then this could conceivably become the default
example hook script, by making the below bit conditional on whether this
looks like a non-bare repository.
Sam.
> active=`git-symbolic-ref HEAD`
> if [ "$ref" = "$active" ]
> then
> echo "Pushing to checked out branch - updating working copy" >&2
> export GIT_DIR=`cd $GIT_DIR; pwd`
> cd ..
> success=
> if git-diff-files
> then
> git-diff-index -z -R --name-status HEAD | perl -n0 -le \
> 'if ($z^=1) {
> $status=$_;
> }
> else {
> $filename=$_;
> printf STDERR "$status\t$filename\n";
> if($status eq "D"){
> unlink($filename)
> or die("unlink($filename) failed; $!")
> }
> }' &&
> git-reset --hard HEAD && success=1
> fi
> if [ -z "$success" ]
> then
> (
> echo "Non-bare repository checkout is not clean - not updating it"
> echo "However I AM going to update the index. Any in-progress commit"
> echo "happening in that checkout will be thrown away, but on the bright"
> echo "side this is probably the least confusing thing for us to do and"
> echo "at least we're not throwing any files somebody has changed away"
> git-reset --mixed HEAD
> echo
> echo "This is the new status of the upstream working copy:"
> git-status
> ) >&2
> fi
> fi
> -
> 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
* Re: [PATCH] git-svn: allow dcommit to retain local merge information
From: Eric Wong @ 2007-06-20 7:04 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <1181776659.30670.340.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> On Wed, 2007-06-13 at 19:13 +0200, Joakim Tjernlund wrote:
> > On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:
> > > dcommit will still rewrite the HEAD commit and the history of the first
> > > parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.
> > >
> > > However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be
> > > preserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN
> > > with dcommit. Commits written to SVN will still not have any merge
> > > information besides anything in the commit message.
> > >
> > > Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm
> > > for explanations, feedback, examples and test case.
> > >
> > > Signed-off-by: Eric Wong <normalperson@yhbt.net>
> > > ---
> > >
> > > This is a better patch that replaces the previous one.
> > >
> > > Junio:
> > > This one is a big change and should probably sit in pu or next
> > > for a bit. Double-checking the logic in linearize_history()
> > > would be greatly appreciated, too.
> > >
> > > I don't think there are any regressions for the
> > > already-linear-history case besides slightly reduced performance for
> > > new calls to cat-file.
> > >
> > > Joakim/Steven:
> > > Any further testing and test cases would be appreciated. Be very
> > > careful with real-world repositories, and run dcommit with the
> > > '-n' flag before actually committing to verify the diffs are sane.
> > >
> > > Thanks
> > >
> >
> > Did a little testing and so far it looks good :)
> >
> > Sidenote:
> > Doing this
> > git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo
> > git-svn fetch --quiet
> > makes git svn fetch stop for rather long periods in do_update:
> > Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2
> > Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8
> > Following parent with do_update
> > Successfully followed parent
> >
> > Is it possible to speed up do_update?
> >
> >
> > Lastly, when adding the above u-boot svn repo into a fresh u-boot clone from WD,
> > can I attach the svn tree to git u-boot tree without using a graft?
> >
> > I want to be able to recreate my own git repo by cloning the orginal u-boot
> > repo and the svn repo.
> >
> > Jocke
>
> Tried using --no-metadata(git svn clone --no-metadata) in my little test
> script I sent earlier and got
> "Unable to determine upstream SVN information from HEAD history"
> when dcommiting, -i trunk didn't help either.
>
> It is not entierly clear to me what --no-metadata means to me.
> Does git-svn still rewrite commits?
--no-metadata is really only useful for people doing one-shot imports
and abandoning SVN. It leaves out the git-svn-id: lines at the bottom
of commit messages, but still sets the committer/author names/email/date
to what is in the SVN repository.
> I can't rebuild rev_db file, if lost, but I guess I could still
> do a new git-svn clone and restore my repo? I guess I lose something
> if I do that but what?
If you lose your rev_db file with no-metadata, you'll have to redo the
git-svn clone
> Also don't really understand why git-svn log doesn't work, can't it get
> that info from the svn repo?
Getting git-svn log working with --no-metadata would require radically
different code. dcommit would be very different, too. So yes, they
don't work because I'm lazy.
--
Eric Wong
^ permalink raw reply
* Re: git-svn strangeness with tags and Squirrelmail repo
From: Eric Wong @ 2007-06-20 7:24 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90706192205y71a77f5al5ca199b3ac382d71@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> First -- kudos to Eric Wong and company: git-svn can deal with the odd
> errors and invalid chunks of XML or UTF-8 that SVN spits at me every
> once in a while. And it "just works" in 99% of the situation. Great
> stuff.
You're welcome. At the same time I'm not reallu sure what you mean by
"odd errors and invalid chunks of XML or UTF-8 that SVN spits at me"
unless it's some joke about SVN I'm not getting :)
> Now... on to my 1% where it doesn't "just work"... I am trying to get
> a working svn to git gateway for Squirrelmail, and getting in trouble
> with the tags setting...
>
> git --version
> git version 1.5.2.2.238.g7cbf2f2
>
> For starters - it "just works" if I run
> git svn init -T trunk -t tags -b branches \
> http://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail
> git svn fetch
>
> However, every tree (for tags, branches and trunk) is prefixed with
> "squirrelmail" and commits to the toplevel "plugins" directory get in
> the way. Also, I want the branches and tags to appear in more natural
> places, so after init, and before fetch, I change .git/config to say:
>
> [svn-remote "svn"]
> url = http://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail
> fetch = trunk/squirrelmail:refs/heads/svn/trunk
> branches = branches/*/squirrelmail:refs/heads/svn/*
> tags = tags/*/squirrelmail:refs/tags/svn/*
git-svn expects 'refs/remotes/' in the local ref name. Otherwise,
the left-hand side is correct.
> and when I do that -- trunk and branches do what I want, but tags
> aren't imported anymore. :-/
Now its odd to me that trunks and branches even works with those ref
names.
--
Eric Wong
^ permalink raw reply
* Re: merge into branch currently not active / checked out
From: Karl Hasselström @ 2007-06-20 7:54 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Junio C Hamano, GIT
In-Reply-To: <20070617101635.GK23473@cip.informatik.uni-erlangen.de>
On 2007-06-17 12:16:35 +0200, Thomas Glanzmann wrote:
> the problem is. Getting a patch into mutt takes several years. At
> least it took for the hcache. So what I do is keep my patches
> up2date on top of there HEAD. So I prefer topic branches. And my
> patches throw _once_ in 4 years a conflict that was not
> automatically resolved. I used bitkeeper before, now I use git.
For this use case, I'd say rebasing is the right thing to do --
otherwise you accumulate a 4-year-long history of uninteresting
merges, as Junio warned.
There are two cases where rebasing is worse than a "real" branch
that's merged instead of rebased:
1. Other people base their work on yours, and need to be able to
pull. They want a stable foundation to build on, one that doesn't
move.
2. Your work is large enough that it's too much work to rebase it.
(This also implies that when you merge, you get interesting
conflicts, since for the case of autoresolved conflicts, rebasing
isn't that much more expensive than merging.)
Since you describe your work as "a patch", I'm guessing neither excuse
applies to you. :-)
> I don't push my work other than in patches that is, so I am going to
> give it a try. I always wanted to try rebase, but I never actually
> did try it.
<advertisement>
You could also try StGIT. Rebasing a patch series on top of a git
branch is what it does.
</advertisement>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Stupid quoting...
From: David Kastrup @ 2007-06-20 7:49 UTC (permalink / raw)
To: git
In-Reply-To: <7vd4zrw3k4.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> I don't see our discourse leading anywhere: the points have been made.
>>
>> I would really, really, really like to see a solution. Alas, I
>> cannot think of one, other than _forcing_ the developers to use
>> ASCII-only filenames.
And ASCII-only files. Just eradicate that dreaded Bit 7 from the world.
>> Note that there is no convention yet in Git to state which encoding
>> your filenames are supposed to use. And in fact, we already had a
>> fine example in git.git why this is particularly difficult. MacOSX
>> is too clever to be true, in that it gladly takes filenames in one
>> encoding, but reads those filenames out in _another_
>> encoding. Thus, a "git add <filename>" can well end up in
>> git-status saying that a file was deleted, and another file
>> (actually the same, but in a different encoding) is untracked.
>
> Having said that, the absolute minimum that needs to be quoted are
> double-quote (because it is used by quoting as agreed with GNU
> diff/patch maintainer), backslash (used to introduce C-like
> quoting),
> newline and horizontal tab (makes "patch" confused, as it would make
> it ambiguous where the pathname ends), so I am not opposed to a
> patch that introduces a new mode, probably on by default _unless_ we
> are generating --format=email, that does not quote high byte values.
I think it would be ok to quote non-graphic characters with octal
escape sequences. On ASCII-based systems, those are the characters
0x00 to 0x1f. They don't have a visual representation of their own,
anyway. _IF_ they appear in filenames, it is certainly a case
involved with excessive cleverness and/or garbage. I'd leave the rest
alone.
> That would solve "My UTF-8 filenames are unreadable on my terminal"
> problem.
But there is no point if the most primitive of mail readers does a
better job than listing the directory will.
7-Bit terminals are the wrong thing to use for manipulating
8-bit-encoded files, period. And the escape sequences for 8-bit
terminals are quite certain to start with characters in the 0x00 to
0x1f range.
--
David Kastrup
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2.2
From: Jakub Narebski @ 2007-06-20 8:34 UTC (permalink / raw)
To: git
In-Reply-To: <7vodjf1gxl.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano wrote:
> - git-gui is shipped with its updated blame interface. It is
> rumored that the older one was not just unusable but was
> active health hazard, but this one is actually pretty.
> Please see for yourself.
I like the new interface very much, especially the info about who
made the change, and who moved the change to present place.
It would be nice though to have git-gui(1) man page describing 'blame'
subcommand of git-gui,, or have "git blame --gui" invoke "git gui blame".
gitk has it's manpage, why not git-gui? AFAICT there is currently no way to
discover this wonderfull tool given only manpages and git-gui help.
Perhaps file browser in git-gui should have "Blame"/"Annotate" button?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Stupid quoting...
From: Jakub Narebski @ 2007-06-20 8:40 UTC (permalink / raw)
To: git
In-Reply-To: <86y7ifoykt.fsf@lola.quinscape.zz>
David Kastrup wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>>> I don't see our discourse leading anywhere: the points have been made.
>>>
>>> I would really, really, really like to see a solution. Alas, I
>>> cannot think of one, other than _forcing_ the developers to use
>>> ASCII-only filenames.
>>> Note that there is no convention yet in Git to state which encoding
>>> your filenames are supposed to use. And in fact, we already had a
>>> fine example in git.git why this is particularly difficult. MacOSX
>>> is too clever to be true, in that it gladly takes filenames in one
>>> encoding, but reads those filenames out in _another_
>>> encoding. Thus, a "git add <filename>" can well end up in
>>> git-status saying that a file was deleted, and another file
>>> (actually the same, but in a different encoding) is untracked.
>>
>> Having said that, the absolute minimum that needs to be quoted are
>> double-quote (because it is used by quoting as agreed with GNU
>> diff/patch maintainer), backslash (used to introduce C-like
>> quoting),
>> newline and horizontal tab (makes "patch" confused, as it would make
>> it ambiguous where the pathname ends), so I am not opposed to a
>> patch that introduces a new mode, probably on by default _unless_ we
>> are generating --format=email, that does not quote high byte values.
>
> I think it would be ok to quote non-graphic characters with octal
> escape sequences. On ASCII-based systems, those are the characters
> 0x00 to 0x1f. They don't have a visual representation of their own,
> anyway. _IF_ they appear in filenames, it is certainly a case
> involved with excessive cleverness and/or garbage. I'd leave the rest
> alone.
By the way, ls(1) has its --quoting-style=WORD option, why shouldn't
git-diff and friends (including git-format-patch) have the same? And we
could change the default later on...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Debugging strange "corrupt pack" errors on SuSE 9
From: Jakub Narebski @ 2007-06-20 8:46 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.99.0706192313290.20596@xanadu.home>
Nicolas Pitre wrote:
> But because you push to a local repository (a mounted USB stick is
> considered a local repo) then you don't get to negociate the pack
> capabilities of the final destination, and therefore more "bad" delta
> objects might sneak in again.
So if he pushes over ssh (ssh localhost) he would get capabilities
negotiation, at the cost of being slower?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: post-update script to update wc - suggestions welcome
From: Junio C Hamano @ 2007-06-20 8:52 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Matthias Lederhofer
In-Reply-To: <E1I0tZY-0001Uz-00@www.watts.utsl.gen.nz>
Sam Vilain <samv@utsl.gen.nz> writes:
> #!/bin/sh
> #
> # An example hook script to prepare a packed repository for use over
> # dumb transports.
> #
> # To enable this hook, make this file executable by "chmod +x post-update".
>
> git-update-server-info
>
> ref=$1
> active=`git-symbolic-ref HEAD`
> if [ "$ref" = "$active" ]
post-update hook takes list of refs that have been updated, so
the above check is bogus, I think.
Better do something like:
case " $* " in
*" $active "*)
: current branch was updated...
;;
*)
: do not have to worry about this one
exit 0
;;
esac
# ... rest of the code here ...
Also you would want to see if the thing is bare.
Unfortunately, git-sh-setup's is_bare_repository does a wrong
thing because receive-pack already runs GIT_DIR set to '.' after
chdir to it. Matthias's long set of patches currently parked in
'pu' is supposed to clarify the semantics of bare/non-bare, so
it may help though (it has "rev-parse --is-bare-repository).
I think 80% of the time (because other 20% of bare repositories
are initialized, following an often repeated incorrect procedure
of making a worktree-full repository and moving its .git/ to
another place, $name.git --- that is wrong for at least three
reasons), if $GIT_DIR/index exists, you can treat it as a
non-bare repository.
So in short, I would follow the above quoted one with:
test -f "$GIT_DIR/index" || exit 0
to ignore bare repositories.
Matthias, do you know if your patchset correctly handle this
case? That is:
$ git push site:my.git set of refs
will:
(1) spawn git-receive-pack with my.git as its
argument;
(2) git-receive-pack finds the repository and chdir()'s
to the directory that has refs/ and HEAD in it
(i.e. if my.git is bare, the directory itself, if
my.git has my.git/.git and possibly a checkout in
my.git/{Makefile,README,...}, then it chdir()'s to
my.git/.git);
(3) then it sets GIT_DIR=. and exports it.
and from that environment, post-update hook is called.
I think Matthias's patch series may need to (conditionally) set
GIT_WORK_TREE environment when it finds the repository and see
if there is an associated work tree at its natural place (that
is, if $something/.git is found in (2) and $something/.git/index
exists, then worktree should be rooted at $something/, unless
core.worktree is set) .
> then
> echo "Pushing to checked out branch - updating working copy" >&2
> export GIT_DIR=`cd $GIT_DIR; pwd`
... and Matthias's patch series probably needs to update this
part of your patch as well.
> cd ..
> success=
> if git-diff-files
> then
I would suggest running update-index --refresh before running
diff-files. The user may have cache-dirty file and only that.
> git-diff-index -z -R --name-status HEAD | perl -n0 -le \
> 'if ($z^=1) {
> $status=$_;
> }
> else {
> $filename=$_;
> printf STDERR "$status\t$filename\n";
> if($status eq "D"){
> unlink($filename)
> or die("unlink($filename) failed; $!")
> }
> }' &&
With "--name-only --diff-filter=D" you would not have to do most
of the above ;-) Use --diff-filter=A without -R, perhaps, to
make it even shorter.
> git-reset --hard HEAD && success=1
> fi
Wouldn't "reset --hard HEAD" pretty much unconditionally nuke
your local changes, including added files to the index? For
example, if I do this:
$ >foo && git add foo && git reset --hard HEAD
it would remove the newly added 'foo' from both the index and
the working tree. So I am not quite sure what you are trying to
achieve with "diff-index | perl" magic.
> if [ -z "$success" ]
> then
> (
> echo "Non-bare repository checkout is not clean - not updating it"
> echo "However I AM going to update the index. Any in-progress commit"
> echo "happening in that checkout will be thrown away, but on the bright"
> echo "side this is probably the least confusing thing for us to do and"
> echo "at least we're not throwing any files somebody has changed away"
> git-reset --mixed HEAD
> echo
> echo "This is the new status of the upstream working copy:"
> git-status
> ) >&2
> fi
> fi
I'll cook up an alternative patch perhaps tomorrow.
^ permalink raw reply
* Re: Stupid quoting...
From: David Kastrup @ 2007-06-20 8:59 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <f5ap5r$sj7$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way, ls(1) has its --quoting-style=WORD option, why shouldn't
> git-diff and friends (including git-format-patch) have the same? And
> we could change the default later on...
Because interpreting a diff means interpreting both file names as well
as contents. It does not make much sense to use different forms of
escaping (\01a and similar) here, though in the diff command line,
some additional quoting might be called for.
It is also worth noting that bash's echo -e can interpret octal
escapes only when they start with \0, and the quoted 3-character forms
of 0x00-0x1f incidentally do start in this manner. There is still
potential for misinterpretation if an escaped character is immediately
followed by a digit. Since octal ASCII digits are in the range 060 to
067, one can get around this problem by continuing to escape
characters until one hits a non-octal-digit. So there is at least a
reasonable builtin way for bash scripts to translate the three-digit
octal escapes for 0x00 to 0x1f uniquely into the proper corresponding
strings.
With regard to escaping: unless used unarmored in Email (a bad idea)
or on a terminal, it might be easiest (for post-processors) to
completely refrain from escaping (in effect ignoring the
non-printability of characters) and just apply a minimal level of
quoting on the file names.
--
David Kastrup
^ permalink raw reply
* Re: git-svn strangeness with tags and Squirrelmail repo
From: Martin Langhoff @ 2007-06-20 9:13 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List
In-Reply-To: <20070620072446.GC25010@muzzle>
On 6/20/07, Eric Wong <normalperson@yhbt.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > First -- kudos to Eric Wong and company: git-svn can deal with the odd
> > errors and invalid chunks of XML or UTF-8 that SVN spits at me every
> > once in a while. And it "just works" in 99% of the situation. Great
> > stuff.
>
> You're welcome. At the same time I'm not reallu sure what you mean by
> "odd errors and invalid chunks of XML or UTF-8 that SVN spits at me"
> unless it's some joke about SVN I'm not getting :)
Oh - the Squirrelmail SVN repo is one of those that have commits that
SVN itself cannot read due to invalid data. So git-svnimport, by
virtue of using the Perl SVN bindings, fails to import it.
git-svn, by some other virtue, imports it perfectly ;-)
> > [svn-remote "svn"]
> > url = http://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail
> > fetch = trunk/squirrelmail:refs/heads/svn/trunk
> > branches = branches/*/squirrelmail:refs/heads/svn/*
> > tags = tags/*/squirrelmail:refs/tags/svn/*
>
> git-svn expects 'refs/remotes/' in the local ref name. Otherwise,
> the left-hand side is correct.
Good to know!
> > and when I do that -- trunk and branches do what I want, but tags
> > aren't imported anymore. :-/
>
> Now its odd to me that trunks and branches even works with those ref
> names.
I'm lucky then ;-)
My reason for the "alternative" locations is to match a bit better the
v1.5.0 behaviour re branches, tags and remotes, and to run the import
directly into a bare repo on git.catalyst.net.nz
- Tags, by virtue of landing under refs/remotes are being treated as
heads rather than tags. That's why I want to have them in
refs/tags/<bla>/*
- If branches + trunk end up in refs/remotes then my bare repo /
gateway doesn't work well - -refs/remotes aren't cloned or fetched
- gitweb refuses to show those heads/tags (maybe it's because it's an
old version?)
cheers,
martin
^ permalink raw reply
* Re: [PATCH 1/3] Accept root <tree-ish> in 'git-svn commit-diff'
From: Sergey Yanovich @ 2007-06-20 9:20 UTC (permalink / raw)
To: Eric Wong; +Cc: git, J.Sixt, masterdriverz
In-Reply-To: <20070620062548.GA25840@muzzle>
Eric Wong wrote:
>> - push @diff_tree, $tree_a, $tree_b;
>> + if ($tree_a eq '0000000000000000000000000000000000000000') {
>
> You can make this more legible by using '0' x40 instead of repeating
> 40 '0' characters. Also, it might be a good idea to support --root
> directly for git-svn so the user won't have to type 40 zeroes in the
> command-line :)
>
Sorry, I am not a perl expert or even user.
I did try to process '--root' in 'git-svn', but in vain. And I can
explain, why 40 '0'. That is the only reference to root commit as an
object that I managed to find in git - in the output of 'git-rev-list'.
If 40 '0' is not good, then it may worth to introduce a shorthand for
it, just as we have one for 'HEAD'. 'NULL' or 'ROOT' may be. If this is
implemented in 'git-rev-list', there will be no need to change 'git-svn'
at all.
^ permalink raw reply
* Re: [PATCH 2/3] 'git-svndump'
From: Sergey Yanovich @ 2007-06-20 9:47 UTC (permalink / raw)
To: Eric Wong; +Cc: git, J.Sixt, masterdriverz
In-Reply-To: <20070620064015.GB25840@muzzle>
Eric Wong wrote:
> We could probably just implement this directly in git-svn. I'll try to
> find time to take a closer look at it this weekend or the next if I
> don't have time. If you or anybody else feel comfortable doing more
> work in Perl, feel free to go ahead with it.
I would be happy to help, but I don't speak fluent perl. I had real
trouble introducing a global variable, when patching 'git-svn' for root
commit.
>> Documentation/git-svndump.txt | 97 ++++++++++++++++++++++++++++++++++++++++
>> Makefile | 1 +
>> git-svndump-init.sh | 85 +++++++++++++++++++++++++++++++++++
>> git-svndump-sync.sh | 98 +++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 281 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/git-svndump.txt
>> create mode 100755 git-svndump-init.sh
>> create mode 100755 git-svndump-sync.sh
>
> I'm really not excited about having even more shell scripts in git.
The first name for this scripts was 'git-svndumb'. They don't do
anything themselves. They just call 'git-svn'. It works like decoupling
in object-oriented design. Old UNIX philosophy of 'big number of small
tools'.
If you decide to incorporate then in 'git-svn', you'll need to
contaminate it with knowledge of 'svndumb'. I am afraid, you'll need to
peruse the whole file, putting 'if's here and there.
But, it doesn't really matter, which you way you go. I would be happy
just to see this functionality in some future release of git.
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Johannes Schindelin @ 2007-06-20 10:31 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Junio C Hamano, Git Mailing List, Jakub Narebski
In-Reply-To: <20070619172619.GH19725@planck.djpig.de>
Hi,
On Tue, 19 Jun 2007, Frank Lichtenheld wrote:
> On Tue, Jun 19, 2007 at 04:57:21PM +0100, Johannes Schindelin wrote:
> > [foo "bar\nbaz"]
> > key = value
> > gives
> >
> > foo.barbaz.key=value
>
> for me this gives
>
> foo.barnbaz.key=value
Yes, of course I had to have a typo in my message. *sigh*
The point is, that I would not expect a "\" to be _ignored_. Either
interpreted, or throwing an error, but just ignored?
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn strangeness with tags and Squirrelmail repo
From: Peter Baumann @ 2007-06-20 10:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Eric Wong, Git Mailing List
In-Reply-To: <46a038f90706200213p2d1e3ba3nf58107584afe4901@mail.gmail.com>
On Wed, Jun 20, 2007 at 09:13:18PM +1200, Martin Langhoff wrote:
[...]
> > > [svn-remote "svn"]
> > > url = http://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail
> > > fetch = trunk/squirrelmail:refs/heads/svn/trunk
> > > branches = branches/*/squirrelmail:refs/heads/svn/*
> > > tags = tags/*/squirrelmail:refs/tags/svn/*
> >
> > git-svn expects 'refs/remotes/' in the local ref name. Otherwise,
> > the left-hand side is correct.
>
> Good to know!
>
> > > and when I do that -- trunk and branches do what I want, but tags
> > > aren't imported anymore. :-/
> >
> > Now its odd to me that trunks and branches even works with those ref
> > names.
>
> I'm lucky then ;-)
>
> My reason for the "alternative" locations is to match a bit better the
> v1.5.0 behaviour re branches, tags and remotes, and to run the import
> directly into a bare repo on git.catalyst.net.nz
>
> - Tags, by virtue of landing under refs/remotes are being treated as
> heads rather than tags. That's why I want to have them in
> refs/tags/<bla>/*
>
But Tags are just heads in SVN. There are many repos where a tag changes
in time and so tags are often used as they were branches where you
develop on.
> - If branches + trunk end up in refs/remotes then my bare repo /
> gateway doesn't work well - -refs/remotes aren't cloned or fetched
>
> - gitweb refuses to show those heads/tags (maybe it's because it's an
> old version?)
>
[ Not sure about this, but could it be that gitweb never shows branches
under refs/remotes ? ]
-Peter
^ permalink raw reply
* git-send-email (Fw: Delivery reports about your email [FAILED(1)])
From: David Miller @ 2007-06-20 10:42 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: Text/Plain, Size: 182 bytes --]
Looks like at least some mailers don't like the Message-Id's
being spit out by the version of git-send-email this person
is using.
Just FYI from your friendly vger postmaster. :-)
[-- Attachment #2: Type: Message/Rfc822, Size: 29313 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 4254 bytes --]
This is a collection of reports about email delivery
process concerning a message you originated.
Some explanations/translations for these reports
can be found at:
http://www.zmailer.org/delivery-report-decoding.html
Generic VGER note: Joining/leaving VGER's lists thru server:
majordomo@vger.kernel.org
Reporting-MTA: dns; vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>
Arrival-Date: Wed, 20 Jun 2007 06:36:19 -0400
Local-Spool-ID: S1763440AbXFTKgT
FAILED:
Original Recipient:
rfc822;jan.kromel@lynx.sk
Final Recipient:
RFC822;jan.kromel@lynx.sk
Status:
5.0.0
Remote MTA:
dns; ke.lynx.sk (85.159.105.18|25|209.132.176.167|35055)
Last Attempt Date:
Wed, 20 Jun 2007 06:36:35 -0400
X-ZTAID:
smtp[23596]
Diagnostic Code:
smtp; 553 (Message-Id header line format error)
Control data:
smtp lynx.sk jan.kromel@lynx.sk 99
Diagnostic texts:
<<- MAIL From:<linux-kernel-owner+jan.kromel=40lynx.sk-S1763440AbXFTKgT@vger.kernel.org> BODY=8BITMIME SIZE=23117
->> 250 2.1.0 <linux-kernel-owner+jan.kromel=40lynx.sk-S1763440AbXFTKgT@vger.kernel.org>... Sender ok
<<- RCPT To:<jan.kromel@lynx.sk> NOTIFY=FAILURE ORCPT=rfc822;jan.kromel@lynx.sk
->> 250 2.1.5 <jan.kromel@lynx.sk>... Recipient ok
<<- DATA
->> 354 Enter mail, end with "." on a line by itself
<<- .
->> 553 5.0.0 Message-Id header line format error
Following is a copy of MESSAGE/DELIVERY-STATUS format section below.
It is copied here in case your email client is unable to show it to you.
The information here below is in Internet Standard format designed to
assist automatic, and accurate presentation and usage of said information.
In case you need human assistance from the Postmaster(s) of the system which
sent you this report, please include this information in your question!
Virtually Yours,
Automatic Email Delivery Software
Reporting-MTA: dns; vger.kernel.org
Arrival-Date: Wed, 20 Jun 2007 06:36:19 -0400
Local-Spool-ID: S1763440AbXFTKgT
Original-Recipient: rfc822;jan.kromel@lynx.sk
Final-Recipient: RFC822;jan.kromel@lynx.sk
Action: failed
Status: 5.0.0
Remote-MTA: dns; ke.lynx.sk (85.159.105.18|25|209.132.176.167|35055)
Last-Attempt-Date: Wed, 20 Jun 2007 06:36:35 -0400
Diagnostic-Code: smtp; 553 (Message-Id header line format error)
Following is copy of the message headers. Original message content may
be in subsequent parts of this MESSAGE/DELIVERY-STATUS structure.
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1763440AbXFTKgT; Wed, 20 Jun 2007 06:36:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761052AbXFTKfu
(ORCPT <rfc822;linux-kernel-outgoing>);
Wed, 20 Jun 2007 06:35:50 -0400
Received: from mail.gmx.net ([213.165.64.20]:40751 "HELO mail.gmx.net"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP
id S1758129AbXFTKft (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
Wed, 20 Jun 2007 06:35:49 -0400
Received: (qmail invoked by alias); 20 Jun 2007 10:35:45 -0000
Received: from i577B9F78.versanet.de (EHLO localhost) [87.123.159.120]
by mail.gmx.net (mp052) with SMTP; 20 Jun 2007 12:35:45 +0200
X-Authenticated: #5039886
X-Provags-ID: V01U2FsdGVkX19FuG9DlANFUAB1y6743T/D78UN2sHlxVX5/236jp
MRleI9FWyt5fy+
From: =?utf-8?q?Bj=C3=B6rn=20Steinbrink?= <B.Steinbrink@gmx.de>
To: eranian@hpl.hp.com
Cc: oprofile-list@lists.sourceforge.net, wcohen@redhat.com, ak@suse.de,
perfmon@napali.hpl.hp.com, linux-kernel@vger.kernel.org,
levon@movementarian.org, akpm@linux-foundation.org, mingo@elte.hu,
=?utf-8?q?Bj=C3=B6rn=20Steinbrink?= <B.Steinbrink@gmx.de>
Subject: [PATCH 2/2] Finish separation of the performance counter allocator from the NMI watchdog
Date: Wed, 20 Jun 2007 12:35:57 +0200
Message-Id: <11823357623688-git-send-email->
X-Mailer: git-send-email 1.5.2.2
In-Reply-To: <11823357591180-git-send-email->
References: <20070618103214.GA12045@atjola.homenet>
<11823357571842-git-send-email->
<11823357591180-git-send-email->
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
[-- Attachment #2.1.2: Type: message/delivery-status, Size: 419 bytes --]
[-- Attachment #2.1.3: Type: Text/Plain, Size: 22834 bytes --]
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand=
id S1763440AbXFTKgT; Wed, 20 Jun 2007 06:36:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761052AbX=
FTKfu
(ORCPT <rfc822;linux-kernel-outgoing>);
Wed, 20 Jun 2007 06:35:50 -0400
Received: from mail.gmx.net ([213.165.64.20]:40751 "HELO mail.gmx.net"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP
id S1758129AbXFTKft (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
Wed, 20 Jun 2007 06:35:49 -0400
Received: (qmail invoked by alias); 20 Jun 2007 10:35:45 -0000
Received: from i577B9F78.versanet.de (EHLO localhost) [87.123.159.120]
by mail.gmx.net (mp052) with SMTP; 20 Jun 2007 12:35:45 +0200
X-Authenticated: #5039886
X-Provags-ID: V01U2FsdGVkX19FuG9DlANFUAB1y6743T/D78UN2sHlxVX5/236jp
MRleI9FWyt5fy+
From: =3D?utf-8?q?Bj=3DC3=3DB6rn=3D20Steinbrink?=3D <B.Steinbrink@gmx.d=
e>
To: eranian@hpl.hp.com
Cc: oprofile-list@lists.sourceforge.net, wcohen@redhat.com, ak@suse.de,=
perfmon@napali.hpl.hp.com, linux-kernel@vger.kernel.org,
levon@movementarian.org, akpm@linux-foundation.org, mingo@elte.hu,
=3D?utf-8?q?Bj=3DC3=3DB6rn=3D20Steinbrink?=3D <B.Steinbrink@gmx.de>
Subject: [PATCH 2/2] Finish separation of the performance counter alloc=
ator from the NMI watchdog
Date: Wed, 20 Jun 2007 12:35:57 +0200
Message-Id: <11823357623688-git-send-email->
X-Mailer: git-send-email 1.5.2.2
In-Reply-To: <11823357591180-git-send-email->
References: <20070618103214.GA12045@atjola.homenet>
<11823357571842-git-send-email->
<11823357591180-git-send-email->
MIME-Version: 1.0
Content-Type: text/plain; charset=3Dutf-8
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
From: Bj=C3=B6rn Steinbrink <B.Steinbrink@gmx.de>
Remove the nmi part from all names in the performance counter allocator=
and move all declarations into their own header file.
Signed-off-by: Bj=C3=B6rn Steinbrink <B.Steinbrink@gmx.de>
---
arch/i386/kernel/apic.c | 1 +
arch/i386/kernel/cpu/perfctr-watchdog.c | 27 +++++++-------
arch/i386/kernel/cpu/perfctr.c | 58 +++++++++++++++--------=
-------
arch/i386/oprofile/nmi_int.c | 4 +-
arch/i386/oprofile/op_model_athlon.c | 10 +++---
arch/i386/oprofile/op_model_p4.c | 28 +++++++-------
arch/i386/oprofile/op_model_ppro.c | 10 +++---
arch/x86_64/kernel/apic.c | 1 +
arch/x86_64/kernel/time.c | 12 +++---
include/asm-i386/nmi.h | 7 ----
include/asm-i386/perfctr.h | 15 ++++++++
include/asm-x86_64/nmi.h | 7 ----
include/asm-x86_64/perfctr.h | 15 ++++++++
13 files changed, 107 insertions(+), 88 deletions(-)
create mode 100644 include/asm-i386/perfctr.h
create mode 100644 include/asm-x86_64/perfctr.h
diff --git a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
index 88b74e3..16a5140 100644
--- a/arch/i386/kernel/apic.c
+++ b/arch/i386/kernel/apic.c
@@ -38,6 +38,7 @@
#include <asm/hpet.h>
#include <asm/i8253.h>
#include <asm/nmi.h>
+#include <asm/perfctr.h>
=
#include <mach_apic.h>
#include <mach_apicdef.h>
diff --git a/arch/i386/kernel/cpu/perfctr-watchdog.c b/arch/i386/kernel=
/cpu/perfctr-watchdog.c
index 2ae39eb..d8fabd2 100644
--- a/arch/i386/kernel/cpu/perfctr-watchdog.c
+++ b/arch/i386/kernel/cpu/perfctr-watchdog.c
@@ -13,6 +13,7 @@
#include <linux/nmi.h>
#include <asm/apic.h>
#include <asm/intel_arch_perfmon.h>
+#include <asm/perfctr.h>
=
struct nmi_watchdog_ctlblk {
unsigned int cccr_msr;
@@ -165,11 +166,11 @@ static void single_msr_stop_watchdog(void)
=
static int single_msr_reserve(void)
{
- if (!reserve_perfctr_nmi(wd_ops->perfctr))
+ if (!reserve_perfctr(wd_ops->perfctr))
return 0;
=
- if (!reserve_evntsel_nmi(wd_ops->evntsel)) {
- release_perfctr_nmi(wd_ops->perfctr);
+ if (!reserve_evntsel(wd_ops->evntsel)) {
+ release_perfctr(wd_ops->perfctr);
return 0;
}
return 1;
@@ -177,8 +178,8 @@ static int single_msr_reserve(void)
=
static void single_msr_unreserve(void)
{
- release_evntsel_nmi(wd_ops->evntsel);
- release_perfctr_nmi(wd_ops->perfctr);
+ release_evntsel(wd_ops->evntsel);
+ release_perfctr(wd_ops->perfctr);
}
=
static void single_msr_rearm(struct nmi_watchdog_ctlblk *wd, unsigned =
nmi_hz)
@@ -352,23 +353,23 @@ static void stop_p4_watchdog(void)
=
static int p4_reserve(void)
{
- if (!reserve_perfctr_nmi(MSR_P4_IQ_PERFCTR0))
+ if (!reserve_perfctr(MSR_P4_IQ_PERFCTR0))
return 0;
#ifdef CONFIG_SMP
- if (smp_num_siblings > 1 && !reserve_perfctr_nmi(MSR_P4_IQ_PERFCTR1))=
+ if (smp_num_siblings > 1 && !reserve_perfctr(MSR_P4_IQ_PERFCTR1))
goto fail1;
#endif
- if (!reserve_evntsel_nmi(MSR_P4_CRU_ESCR0))
+ if (!reserve_evntsel(MSR_P4_CRU_ESCR0))
goto fail2;
/* RED-PEN why is ESCR1 not reserved here? */
return 1;
fail2:
#ifdef CONFIG_SMP
if (smp_num_siblings > 1)
- release_perfctr_nmi(MSR_P4_IQ_PERFCTR1);
+ release_perfctr(MSR_P4_IQ_PERFCTR1);
fail1:
#endif
- release_perfctr_nmi(MSR_P4_IQ_PERFCTR0);
+ release_perfctr(MSR_P4_IQ_PERFCTR0);
return 0;
}
=
@@ -376,10 +377,10 @@ static void p4_unreserve(void)
{
#ifdef CONFIG_SMP
if (smp_num_siblings > 1)
- release_perfctr_nmi(MSR_P4_IQ_PERFCTR1);
+ release_perfctr(MSR_P4_IQ_PERFCTR1);
#endif
- release_evntsel_nmi(MSR_P4_CRU_ESCR0);
- release_perfctr_nmi(MSR_P4_IQ_PERFCTR0);
+ release_evntsel(MSR_P4_CRU_ESCR0);
+ release_perfctr(MSR_P4_IQ_PERFCTR0);
}
=
static void p4_rearm(struct nmi_watchdog_ctlblk *wd, unsigned nmi_hz)
diff --git a/arch/i386/kernel/cpu/perfctr.c b/arch/i386/kernel/cpu/perf=
ctr.c
index fece4fc..cbf57ce 100644
--- a/arch/i386/kernel/cpu/perfctr.c
+++ b/arch/i386/kernel/cpu/perfctr.c
@@ -35,14 +35,14 @@ static struct perfctr_base_regs arch_perfmon_base_r=
egs =3D {
*/
#define NMI_MAX_COUNTER_BITS 66
=
-/* perfctr_nmi_owner tracks the ownership of the perfctr registers:
- * evtsel_nmi_owner tracks the ownership of the event selection
+/* perfctr_owner tracks the ownership of the perfctr registers:
+ * evtsel_owner tracks the ownership of the event selection
* - different performance counters/ event selection may be reserved f=
or
* different subsystems this reservation system just tries to coordi=
nate
* things a little
*/
-static DECLARE_BITMAP(perfctr_nmi_owner, NMI_MAX_COUNTER_BITS);
-static DECLARE_BITMAP(evntsel_nmi_owner, NMI_MAX_COUNTER_BITS);
+static DECLARE_BITMAP(perfctr_owner, NMI_MAX_COUNTER_BITS);
+static DECLARE_BITMAP(evntsel_owner, NMI_MAX_COUNTER_BITS);
=
void __devinit probe_performance_counters(void)
{
@@ -77,102 +77,102 @@ void __devinit probe_performance_counters(void)
}
=
/* converts an msr to an appropriate reservation bit */
-static inline unsigned int nmi_perfctr_msr_to_bit(unsigned int msr)
+static inline unsigned int perfctr_msr_to_bit(unsigned int msr)
{
return msr - perfctr_base_regs->perfctr;
}
=
/* converts an msr to an appropriate reservation bit */
/* returns the bit offset of the event selection register */
-static inline unsigned int nmi_evntsel_msr_to_bit(unsigned int msr)
+static inline unsigned int evntsel_msr_to_bit(unsigned int msr)
{
return msr - perfctr_base_regs->evntsel;
}
=
/* checks for a bit availability (hack for oprofile) */
-int avail_to_resrv_perfctr_nmi_bit(unsigned int counter)
+int avail_to_resrv_perfctr_bit(unsigned int counter)
{
if (!perfctr_base_regs)
return 0;
=
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
=
- return (!test_bit(counter, perfctr_nmi_owner));
+ return (!test_bit(counter, perfctr_owner));
}
=
/* checks the an msr for availability */
-int avail_to_resrv_perfctr_nmi(unsigned int msr)
+int avail_to_resrv_perfctr(unsigned int msr)
{
unsigned int counter;
=
if (!perfctr_base_regs)
return 0;
=
- counter =3D nmi_perfctr_msr_to_bit(msr);
+ counter =3D perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
=
- return (!test_bit(counter, perfctr_nmi_owner));
+ return (!test_bit(counter, perfctr_owner));
}
=
-int reserve_perfctr_nmi(unsigned int msr)
+int reserve_perfctr(unsigned int msr)
{
unsigned int counter;
=
if (!perfctr_base_regs)
return 0;
=
- counter =3D nmi_perfctr_msr_to_bit(msr);
+ counter =3D perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
=
- if (!test_and_set_bit(counter, perfctr_nmi_owner))
+ if (!test_and_set_bit(counter, perfctr_owner))
return 1;
return 0;
}
=
-void release_perfctr_nmi(unsigned int msr)
+void release_perfctr(unsigned int msr)
{
unsigned int counter;
=
if (!perfctr_base_regs)
return;
=
- counter =3D nmi_perfctr_msr_to_bit(msr);
+ counter =3D perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
=
- clear_bit(counter, perfctr_nmi_owner);
+ clear_bit(counter, perfctr_owner);
}
=
-int reserve_evntsel_nmi(unsigned int msr)
+int reserve_evntsel(unsigned int msr)
{
unsigned int counter;
=
if (!perfctr_base_regs)
return 0;
=
- counter =3D nmi_evntsel_msr_to_bit(msr);
+ counter =3D evntsel_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
=
- if (!test_and_set_bit(counter, evntsel_nmi_owner))
+ if (!test_and_set_bit(counter, evntsel_owner))
return 1;
return 0;
}
=
-void release_evntsel_nmi(unsigned int msr)
+void release_evntsel(unsigned int msr)
{
unsigned int counter;
=
if (!perfctr_base_regs)
return;
=
- counter =3D nmi_evntsel_msr_to_bit(msr);
+ counter =3D evntsel_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
=
- clear_bit(counter, evntsel_nmi_owner);
+ clear_bit(counter, evntsel_owner);
}
=
-EXPORT_SYMBOL(avail_to_resrv_perfctr_nmi);
-EXPORT_SYMBOL(avail_to_resrv_perfctr_nmi_bit);
-EXPORT_SYMBOL(reserve_perfctr_nmi);
-EXPORT_SYMBOL(release_perfctr_nmi);
-EXPORT_SYMBOL(reserve_evntsel_nmi);
-EXPORT_SYMBOL(release_evntsel_nmi);
+EXPORT_SYMBOL(avail_to_resrv_perfctr);
+EXPORT_SYMBOL(avail_to_resrv_perfctr_bit);
+EXPORT_SYMBOL(reserve_perfctr);
+EXPORT_SYMBOL(release_perfctr);
+EXPORT_SYMBOL(reserve_evntsel);
+EXPORT_SYMBOL(release_evntsel);
diff --git a/arch/i386/oprofile/nmi_int.c b/arch/i386/oprofile/nmi_int.=
c
index 11b7a51..b00ae99 100644
--- a/arch/i386/oprofile/nmi_int.c
+++ b/arch/i386/oprofile/nmi_int.c
@@ -15,7 +15,7 @@
#include <linux/slab.h>
#include <linux/moduleparam.h>
#include <linux/kdebug.h>
-#include <asm/nmi.h>
+#include <asm/perfctr.h>
#include <asm/msr.h>
#include <asm/apic.h>
=
@@ -324,7 +324,7 @@ static int nmi_create_files(struct super_block * sb=
, struct dentry * root)
* NOTE: assumes 1:1 mapping here (that counters are organized
* sequentially in their struct assignment).
*/
- if (unlikely(!avail_to_resrv_perfctr_nmi_bit(i)))
+ if (unlikely(!avail_to_resrv_perfctr_bit(i)))
continue;
=
snprintf(buf, sizeof(buf), "%d", i);
diff --git a/arch/i386/oprofile/op_model_athlon.c b/arch/i386/oprofile/=
op_model_athlon.c
index 3057a19..b1e9902 100644
--- a/arch/i386/oprofile/op_model_athlon.c
+++ b/arch/i386/oprofile/op_model_athlon.c
@@ -13,7 +13,7 @@
#include <linux/oprofile.h>
#include <asm/ptrace.h>
#include <asm/msr.h>
-#include <asm/nmi.h>
+#include <asm/perfctr.h>
=
#include "op_x86_model.h"
#include "op_counter.h"
@@ -45,14 +45,14 @@ static void athlon_fill_in_addresses(struct op_msrs=
* const msrs)
int i;
=
for (i=3D0; i < NUM_COUNTERS; i++) {
- if (reserve_perfctr_nmi(MSR_K7_PERFCTR0 + i))
+ if (reserve_perfctr(MSR_K7_PERFCTR0 + i))
msrs->counters[i].addr =3D MSR_K7_PERFCTR0 + i;
else
msrs->counters[i].addr =3D 0;
}
=
for (i=3D0; i < NUM_CONTROLS; i++) {
- if (reserve_evntsel_nmi(MSR_K7_EVNTSEL0 + i))
+ if (reserve_evntsel(MSR_K7_EVNTSEL0 + i))
msrs->controls[i].addr =3D MSR_K7_EVNTSEL0 + i;
else
msrs->controls[i].addr =3D 0;
@@ -160,11 +160,11 @@ static void athlon_shutdown(struct op_msrs const =
* const msrs)
=
for (i =3D 0 ; i < NUM_COUNTERS ; ++i) {
if (CTR_IS_RESERVED(msrs,i))
- release_perfctr_nmi(MSR_K7_PERFCTR0 + i);
+ release_perfctr(MSR_K7_PERFCTR0 + i);
}
for (i =3D 0 ; i < NUM_CONTROLS ; ++i) {
if (CTRL_IS_RESERVED(msrs,i))
- release_evntsel_nmi(MSR_K7_EVNTSEL0 + i);
+ release_evntsel(MSR_K7_EVNTSEL0 + i);
}
}
=
diff --git a/arch/i386/oprofile/op_model_p4.c b/arch/i386/oprofile/op_m=
odel_p4.c
index 4792592..6ba5856 100644
--- a/arch/i386/oprofile/op_model_p4.c
+++ b/arch/i386/oprofile/op_model_p4.c
@@ -14,7 +14,7 @@
#include <asm/ptrace.h>
#include <asm/fixmap.h>
#include <asm/apic.h>
-#include <asm/nmi.h>
+#include <asm/perfctr.h>
=
#include "op_x86_model.h"
#include "op_counter.h"
@@ -413,7 +413,7 @@ static void p4_fill_in_addresses(struct op_msrs * c=
onst msrs)
for (i =3D 0; i < num_counters; ++i) {
addr =3D p4_counters[VIRT_CTR(stag, i)].counter_address;
cccraddr =3D p4_counters[VIRT_CTR(stag, i)].cccr_address;
- if (reserve_perfctr_nmi(addr)){
+ if (reserve_perfctr(addr)){
msrs->counters[i].addr =3D addr;
msrs->controls[i].addr =3D cccraddr;
}
@@ -422,7 +422,7 @@ static void p4_fill_in_addresses(struct op_msrs * c=
onst msrs)
/* 43 ESCR registers in three or four discontiguous group */
for (addr =3D MSR_P4_BSU_ESCR0 + stag;
addr < MSR_P4_IQ_ESCR0; ++i, addr +=3D addr_increment()) {
- if (reserve_evntsel_nmi(addr))
+ if (reserve_evntsel(addr))
msrs->controls[i].addr =3D addr;
}
=
@@ -431,32 +431,32 @@ static void p4_fill_in_addresses(struct op_msrs *=
const msrs)
if (boot_cpu_data.x86_model >=3D 0x3) {
for (addr =3D MSR_P4_BSU_ESCR0 + stag;
addr <=3D MSR_P4_BSU_ESCR1; ++i, addr +=3D addr_increment()) {
- if (reserve_evntsel_nmi(addr))
+ if (reserve_evntsel(addr))
msrs->controls[i].addr =3D addr;
}
} else {
for (addr =3D MSR_P4_IQ_ESCR0 + stag;
addr <=3D MSR_P4_IQ_ESCR1; ++i, addr +=3D addr_increment()) {
- if (reserve_evntsel_nmi(addr))
+ if (reserve_evntsel(addr))
msrs->controls[i].addr =3D addr;
}
}
=
for (addr =3D MSR_P4_RAT_ESCR0 + stag;
addr <=3D MSR_P4_SSU_ESCR0; ++i, addr +=3D addr_increment()) {
- if (reserve_evntsel_nmi(addr))
+ if (reserve_evntsel(addr))
msrs->controls[i].addr =3D addr;
}
=
for (addr =3D MSR_P4_MS_ESCR0 + stag;
addr <=3D MSR_P4_TC_ESCR1; ++i, addr +=3D addr_increment()) { =
- if (reserve_evntsel_nmi(addr))
+ if (reserve_evntsel(addr))
msrs->controls[i].addr =3D addr;
}
=
for (addr =3D MSR_P4_IX_ESCR0 + stag;
addr <=3D MSR_P4_CRU_ESCR3; ++i, addr +=3D addr_increment()) { =
- if (reserve_evntsel_nmi(addr))
+ if (reserve_evntsel(addr))
msrs->controls[i].addr =3D addr;
}
=
@@ -464,21 +464,21 @@ static void p4_fill_in_addresses(struct op_msrs *=
const msrs)
=
if (num_counters =3D=3D NUM_COUNTERS_NON_HT) { =
/* standard non-HT CPUs handle both remaining ESCRs*/
- if (reserve_evntsel_nmi(MSR_P4_CRU_ESCR5))
+ if (reserve_evntsel(MSR_P4_CRU_ESCR5))
msrs->controls[i++].addr =3D MSR_P4_CRU_ESCR5;
- if (reserve_evntsel_nmi(MSR_P4_CRU_ESCR4))
+ if (reserve_evntsel(MSR_P4_CRU_ESCR4))
msrs->controls[i++].addr =3D MSR_P4_CRU_ESCR4;
=
} else if (stag =3D=3D 0) {
/* HT CPUs give the first remainder to the even thread, as
the 32nd control register */
- if (reserve_evntsel_nmi(MSR_P4_CRU_ESCR4))
+ if (reserve_evntsel(MSR_P4_CRU_ESCR4))
msrs->controls[i++].addr =3D MSR_P4_CRU_ESCR4;
=
} else {
/* and two copies of the second to the odd thread,
for the 22st and 23nd control registers */
- if (reserve_evntsel_nmi(MSR_P4_CRU_ESCR5)) {
+ if (reserve_evntsel(MSR_P4_CRU_ESCR5)) {
msrs->controls[i++].addr =3D MSR_P4_CRU_ESCR5;
msrs->controls[i++].addr =3D MSR_P4_CRU_ESCR5;
}
@@ -684,7 +684,7 @@ static void p4_shutdown(struct op_msrs const * cons=
t msrs)
=
for (i =3D 0 ; i < num_counters ; ++i) {
if (CTR_IS_RESERVED(msrs,i))
- release_perfctr_nmi(msrs->counters[i].addr);
+ release_perfctr(msrs->counters[i].addr);
}
/* some of the control registers are specially reserved in
* conjunction with the counter registers (hence the starting offset)=
.=
@@ -692,7 +692,7 @@ static void p4_shutdown(struct op_msrs const * cons=
t msrs)
*/
for (i =3D num_counters ; i < num_controls ; ++i) {
if (CTRL_IS_RESERVED(msrs,i))
- release_evntsel_nmi(msrs->controls[i].addr);
+ release_evntsel(msrs->controls[i].addr);
}
}
=
diff --git a/arch/i386/oprofile/op_model_ppro.c b/arch/i386/oprofile/op=
_model_ppro.c
index c554f52..5dfd93a 100644
--- a/arch/i386/oprofile/op_model_ppro.c
+++ b/arch/i386/oprofile/op_model_ppro.c
@@ -14,7 +14,7 @@
#include <asm/ptrace.h>
#include <asm/msr.h>
#include <asm/apic.h>
-#include <asm/nmi.h>
+#include <asm/perfctr.h>
=
#include "op_x86_model.h"
#include "op_counter.h"
@@ -47,14 +47,14 @@ static void ppro_fill_in_addresses(struct op_msrs *=
const msrs)
int i;
=
for (i=3D0; i < NUM_COUNTERS; i++) {
- if (reserve_perfctr_nmi(MSR_P6_PERFCTR0 + i))
+ if (reserve_perfctr(MSR_P6_PERFCTR0 + i))
msrs->counters[i].addr =3D MSR_P6_PERFCTR0 + i;
else
msrs->counters[i].addr =3D 0;
}
=
for (i=3D0; i < NUM_CONTROLS; i++) {
- if (reserve_evntsel_nmi(MSR_P6_EVNTSEL0 + i))
+ if (reserve_evntsel(MSR_P6_EVNTSEL0 + i))
msrs->controls[i].addr =3D MSR_P6_EVNTSEL0 + i;
else
msrs->controls[i].addr =3D 0;
@@ -171,11 +171,11 @@ static void ppro_shutdown(struct op_msrs const * =
const msrs)
=
for (i =3D 0 ; i < NUM_COUNTERS ; ++i) {
if (CTR_IS_RESERVED(msrs,i))
- release_perfctr_nmi(MSR_P6_PERFCTR0 + i);
+ release_perfctr(MSR_P6_PERFCTR0 + i);
}
for (i =3D 0 ; i < NUM_CONTROLS ; ++i) {
if (CTRL_IS_RESERVED(msrs,i))
- release_evntsel_nmi(MSR_P6_EVNTSEL0 + i);
+ release_evntsel(MSR_P6_EVNTSEL0 + i);
}
}
=
diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 892ebf8..c08cf0f 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
@@ -33,6 +33,7 @@
#include <asm/pgalloc.h>
#include <asm/mach_apic.h>
#include <asm/nmi.h>
+#include <asm/perfctr.h>
#include <asm/idle.h>
#include <asm/proto.h>
#include <asm/timex.h>
diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
index 4a0895b..d145547 100644
--- a/arch/x86_64/kernel/time.c
+++ b/arch/x86_64/kernel/time.c
@@ -43,7 +43,7 @@
#include <asm/apic.h>
#include <asm/hpet.h>
#include <asm/mpspec.h>
-#include <asm/nmi.h>
+#include <asm/perfctr.h>
=
static char *timename =3D NULL;
=
@@ -261,7 +261,7 @@ static unsigned int __init tsc_calibrate_cpu_khz(vo=
id)
unsigned long flags;
=
for (i =3D 0; i < 4; i++)
- if (avail_to_resrv_perfctr_nmi_bit(i))
+ if (avail_to_resrv_perfctr_bit(i))
break;
no_ctr_free =3D (i =3D=3D 4);
if (no_ctr_free) {
@@ -270,8 +270,8 @@ static unsigned int __init tsc_calibrate_cpu_khz(vo=
id)
wrmsrl(MSR_K7_EVNTSEL3, 0);
rdmsrl(MSR_K7_PERFCTR3, pmc3);
} else {
- reserve_perfctr_nmi(MSR_K7_PERFCTR0 + i);
- reserve_evntsel_nmi(MSR_K7_EVNTSEL0 + i);
+ reserve_perfctr(MSR_K7_PERFCTR0 + i);
+ reserve_evntsel(MSR_K7_EVNTSEL0 + i);
}
local_irq_save(flags);
/* start meauring cycles, incrementing from 0 */
@@ -289,8 +289,8 @@ static unsigned int __init tsc_calibrate_cpu_khz(vo=
id)
wrmsrl(MSR_K7_PERFCTR3, pmc3);
wrmsrl(MSR_K7_EVNTSEL3, evntsel3);
} else {
- release_perfctr_nmi(MSR_K7_PERFCTR0 + i);
- release_evntsel_nmi(MSR_K7_EVNTSEL0 + i);
+ release_perfctr(MSR_K7_PERFCTR0 + i);
+ release_evntsel(MSR_K7_EVNTSEL0 + i);
}
=
return pmc_now * tsc_khz / (tsc_now - tsc_start);
diff --git a/include/asm-i386/nmi.h b/include/asm-i386/nmi.h
index 736af6f..e189531 100644
--- a/include/asm-i386/nmi.h
+++ b/include/asm-i386/nmi.h
@@ -18,13 +18,6 @@
int do_nmi_callback(struct pt_regs *regs, int cpu);
=
extern int nmi_watchdog_enabled;
-extern void probe_performance_counters(void);
-extern int avail_to_resrv_perfctr_nmi_bit(unsigned int);
-extern int avail_to_resrv_perfctr_nmi(unsigned int);
-extern int reserve_perfctr_nmi(unsigned int);
-extern void release_perfctr_nmi(unsigned int);
-extern int reserve_evntsel_nmi(unsigned int);
-extern void release_evntsel_nmi(unsigned int);
=
extern void setup_apic_nmi_watchdog (void *);
extern void stop_apic_nmi_watchdog (void *);
diff --git a/include/asm-i386/perfctr.h b/include/asm-i386/perfctr.h
new file mode 100644
index 0000000..fbd4993
--- /dev/null
+++ b/include/asm-i386/perfctr.h
@@ -0,0 +1,15 @@
+/*
+ * linux/include/asm-i386/perfctr.h
+ */
+#ifndef ASM_PERFCTR_H
+#define ASM_PERFCTR_H
+
+extern void probe_performance_counters(void);
+extern int avail_to_resrv_perfctr_bit(unsigned int);
+extern int avail_to_resrv_perfctr(unsigned int);
+extern int reserve_perfctr(unsigned int);
+extern void release_perfctr(unsigned int);
+extern int reserve_evntsel(unsigned int);
+extern void release_evntsel(unsigned int);
+
+#endif /* ASM_PERFCTR_H */
diff --git a/include/asm-x86_64/nmi.h b/include/asm-x86_64/nmi.h
index d45fc62..666462c 100644
--- a/include/asm-x86_64/nmi.h
+++ b/include/asm-x86_64/nmi.h
@@ -46,13 +46,6 @@ extern int unknown_nmi_panic;
extern int nmi_watchdog_enabled;
=
extern int check_nmi_watchdog(void);
-extern void probe_performance_counters(void);
-extern int avail_to_resrv_perfctr_nmi_bit(unsigned int);
-extern int avail_to_resrv_perfctr_nmi(unsigned int);
-extern int reserve_perfctr_nmi(unsigned int);
-extern void release_perfctr_nmi(unsigned int);
-extern int reserve_evntsel_nmi(unsigned int);
-extern void release_evntsel_nmi(unsigned int);
=
extern void setup_apic_nmi_watchdog (void *);
extern void stop_apic_nmi_watchdog (void *);
diff --git a/include/asm-x86_64/perfctr.h b/include/asm-x86_64/perfctr.=
h
new file mode 100644
index 0000000..9ff5c2d
--- /dev/null
+++ b/include/asm-x86_64/perfctr.h
@@ -0,0 +1,15 @@
+/*
+ * linux/include/asm-x86_64/perfctr.h
+ */
+#ifndef ASM_PERFCTR_H
+#define ASM_PERFCTR_H
+
+extern void probe_performance_counters(void);
+extern int avail_to_resrv_perfctr_bit(unsigned int);
+extern int avail_to_resrv_perfctr(unsigned int);
+extern int reserve_perfctr(unsigned int);
+extern void release_perfctr(unsigned int);
+extern int reserve_evntsel(unsigned int);
+extern void release_evntsel(unsigned int);
+
+#endif /* ASM_PERFCTR_H */
-- =
1.5.2.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/=
^ permalink raw reply related
* filenames with " b" in them create confusing git diff-tree output
From: Paul Mackerras @ 2007-06-20 11:15 UTC (permalink / raw)
To: Junio C Hamano, git
While trying to improve gitk's handling of filenames with spaces, I
realised that the header line in git diff-tree's output can be
inherently ambiguous, since it doesn't put quotes around filenames
with spaces (although it does for filenames with other special
characters in them).
For example:
paulus@quango:~/gitk/testrepo$ mkdir "test b"
paulus@quango:~/gitk/testrepo$ cat >"test b/foo"
stuff
paulus@quango:~/gitk/testrepo$ git add "test b/foo"
paulus@quango:~/gitk/testrepo$ git commit -a
Created commit 71a3074: Add a "test b" directory
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 test b/foo
paulus@quango:~/gitk/testrepo$ git diff-tree -r -p -C HEAD
71a3074e723c3e5eb599e6b3c47e3267a3cac3bc
diff --git a/test b/foo b/test b/foo
new file mode 100644
index 0000000..f2e4113
--- /dev/null
+++ b/test b/foo
@@ -0,0 +1 @@
+stuff
Note how there appear to be 4 filenames on the "diff --git" line. At
present gitk will interpret that as a diff between "test" and
"foo b/test b/foo", since it looks for " a/" and " b/" to delimit the
filenames. Of course if the file got renamed it could get even more
confusing. :)
Would there be any ill effects from quoting filenames with spaces, do
you think? It seems the simplest fix to me (and I will make gitk
handle quoted filenames, which it doesn't at present :).
Paul.
^ permalink raw reply related
* [PATCH] git-send-email: RFC2822 compliant Message-ID
From: Michael Hendricks @ 2007-06-20 13:25 UTC (permalink / raw)
To: git; +Cc: Michael Hendricks
RFC 2822 section 3.6.4 suggests that a "good method" for generating a
Message-ID is to put the domain name of the host on the right-side of
the "@" character. Use Perl's Sys::Hostname to do the heavy lifting.
This module has been in the Perl core since version 5.
---
git-send-email.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 7c0c90b..2259f4b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -21,6 +21,7 @@ use warnings;
use Term::ReadLine;
use Getopt::Long;
use Data::Dumper;
+use Sys::Hostname;
use Git;
package FakeTerm;
@@ -411,9 +412,9 @@ sub extract_valid_address {
# a random number to the end, in case we are called quicker than
# 1 second since the last time we were called.
-# We'll setup a template for the message id, using the "from" address:
-my $message_id_from = extract_valid_address($from);
-my $message_id_template = "<%s-git-send-email-$message_id_from>";
+# We'll setup a template for the message id, using the hostname:
+my $hostname = hostname();
+my $message_id_template = "<%s-git-send-email\@$hostname>";
sub make_message_id
{
--
1.5.2.2.238.g7cbf2f2
^ permalink raw reply related
* Re: Finally implement "git log --follow"
From: Linus Torvalds @ 2007-06-20 16:47 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550706192327l187b30eblb5bd5e4e76b3eab6@mail.gmail.com>
On Wed, 20 Jun 2007, Marco Costalba wrote:
>
> now I have one more reason to switch from using git-rev-list to
> git-log in qgit, file history annotation, that is currently based on
> git-rev-list, will automatically gain a powerful feature.
Well, note my other email about how "--follow" does *not* play together
with "--parents", because the two do totally different kinds of filtering
of the commits. So yes, you can use it for file history annotation, but
not for the "graphical history" part that depends on parenthood etc.
That said, you really would be better off using
git blame -M --incremental
for the history annotation. It does the rename following *and* so much
more.
Linus
^ 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