[PATCH] Define a shell function to check tree cleanness.
This would be used in places where we require a clean tree, such
as reverting and rebasing.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
git-sh-setup-script | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
1de6046ded332e2278320be314f7a5e31a431e14
diff --git a/git-sh-setup-script b/git-sh-setup-script
--- a/git-sh-setup-script
+++ b/git-sh-setup-script
@@ -11,6 +11,17 @@ die() {
exit 1
}
+check_clean_tree() {
+dirty1_=`git-update-cache -q --refresh` {
+dirty2_=`git-diff-cache --name-only --cached HEAD`
+case $dirty2_ in '') : ;; *) (exit 1) ;; esac
+} || {
+ echo 2 $dirty1_
+ echo $dirty2_ | sed 2 -e 's/^/modified: /'
+ (exit 1)
+}
+}
+
[ -d $GIT_DIR ]
[ -d $GIT_DIR/refs ]
[ -d $GIT_OBJECT_DIRECTORY ]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merges without bases
On 8/26/05, Junio C Hamano [EMAIL PROTECTED] wrote: their core GIT tools come from. But how would _I_ pull from that My Project, if I did not want to pull unrelated stuff in? and then... What I think _might_ deserve a bit more support would be a merge of a foreign project as a subdirectory of a project. Linus tla has an interesting implementation (and horrible name) for something like this. In Arch-speak, they are called 'configurations', a versioned control file that describes that in subdirectory foo we import from this other repo#branch. In cvs, you just do nested checkouts, and trust a `cvs update` done at the top will do the right thing; and in fact recent cvs versions do. After using cvs and arch for a while, my opinion is that all this stuff is _bad_, and you want a makefile that pulls the projects together when you build them. Different projects are going to use different SCMs anyway, and you'll have to live with how to tag a release across repositories/scms, and I haven't seen any answer I like. cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Looking at multiple ancestors in merge
Daniel Barkalow [EMAIL PROTECTED] writes: I've started this, and have gotten as far as having read-tree accept 3 trees and ignore everything but the last 3. Am I correct in assuming that if I break read-tree in any way, some test will fail? If some test fails you would know you broke it, but the inverse is probably not always true. I think the current read-tree test suite has reasonably wide coverage of all the interesting cases. But the definition of interesting was derived from the current world order (IOW, the test suite was designed around the way we do things right now as a whitebox test, not a blackbox test). I would not be surprised if some of them did not catch breakage you may introduce during the development. I wonder however if extending the current way of doing things in the cache is the right thing. Right now we use two bits out of the top four bits for recording stage, one bit for the update bit, so you have only one extra bit to extend the number of stages, which means you could hold at most 7 trees at once. You ignore things but the last 3, so this may not be too much of a problem, but I am a bit puzzled what you meant by it though. Are you talking about reading more than 3 trees and keeping only the 3 to be merged, discarding the rest, doing the selection per path? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
SVN import issue
Hi,
I'm off to the beach for the next two weeks, so if somebody wants to
munge cvs2git into svn2git, here's the basics on how to pull from a
remote SVN repo:
#!/usr/bin/perl
use strict;
use warnings;
use SVN::Core;
use SVN::Ra;
my(@new,@del,@mod);
sub show_log {
my ($changed_paths, $revision, $author, $date, $message, $pool) = @_;
$author = 'unknown' unless defined $author;
@new = (); @del = (); @mod = ();
(my $pmessage = $message) =~ s/\n/\n/g;
print *** $revision: $author \@ $date:\n $pmessage\n;
print Files:\n;
while(my($path,$action) = each %$changed_paths) {
my $act = $action-action;
my $oldpath = $action-copyfrom_path;
my $oldrev = $action-copyfrom_rev;
$oldrev = undef if defined $oldrev and $oldrev = 0;
$oldpath = undef if defined $oldpath and ($oldpath eq or
$oldpath eq $path);
print $act $path;
print - if $oldpath or $oldrev;
print $oldpath if defined $oldpath;
print $oldrev if defined $oldrev;
print \n;
if($act eq A) {
push(@new,$path);
} elsif($act eq D) {
push(@del,$path);
} else {
push(@mod,$path);
}
}
}
my $ra = SVN::Ra-new(svn://cvs.gnupg.org/gnupg);
my $latest = $ra-get_latest_revnum();
my $n = 1;
while($n = $latest) {
$ra-get_log(/,$n,$n,$n,1,1,\show_log,);
foreach my $path(@new,@mod) {
print Reading $path, $n...\n;
open(F,/tmp/foo); # ( OK, so use tempfile() here ;-)
eval {
$ra-get_file($path,$n,\*F);
};
close(F);
if ($@) {
print ... not a file\n;
next;
}
my $sz = (stat(/tmp/foo))[7];
print ... done, $sz bytes\n.;
}
} continue {
$n++;
}
Paths in SVN are usually prefixed /trunk/ (main branch) or
/branches/foo/ (branch foo); tagging is done by creating /tags/bar,
with the trunk (or branch) revision it is pointing to as its parent.
So a branch point looks like this:
*** 350: unknown @ 1999-09-18T11:04:00.00Z:
This commit was manufactured by cvs2svn to create branch
'STABLE-BRANCH-1-0'.
Files:
A /branches/STABLE-BRANCH-1-0/cipher/rndw32.c - /trunk/cipher/rndw32.c 349
A /branches/STABLE-BRANCH-1-0 - /trunk 348
(and of *course* it may have changes from other revisions in it,
anything else would simply be too easy I guess...). Tags look like they
do, see tag 1-0-0 in the above repo; that seems to happen because their
CVS importer couldn't find a sane branchpoint. cvsps reports the same thing.
I haven't yet examined what a SVN merge looks like.
Nothing stops a SVN check-in from touching multiple branches at the same
time, though in practice that doesn't happen.
The mapping of SVN revision numbers to git SHA1s could get a bit
annoying because incremental imports need to work. Personally I'd use a
.svnmap file which has svnid sha1 lines inside. The last line
obviously would not have a sha1 because we can't know that before
checking in the file...
So, if I find a working SVN importer when I come back I'll be happy ;-)
(munging cvs2git shouldn't be particularly difficult), otherwise I'll do
it myself, in a month or so.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I had been driving my car for 40 years when I fell asleep at the wheel and
had an accident.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git bugfixes and cleanups, mainly Debian things
Make the git deb conflict with cogito versions prior to 0.13, as those
versions used to contain git. Suggest cogito.
Signed-off-by: Tommi Virtanen [EMAIL PROTECTED]
---
commit 62e16702fdb0cdc13822470f3a19b36956fd0d78
tree bf96bcbdf1ca99390e6d6cb894da8384270c585f
parent c87030106cfbe39f0ab2ed095f30f576235328fc
author Tommi Virtanen [EMAIL PROTECTED] Fri, 26 Aug 2005 12:32:27 +0300
committer Tommi Virtanen [EMAIL PROTECTED] Fri, 26 Aug 2005 12:32:27 +0300
debian/control |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,8 @@ Package: git-core
Architecture: any
Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, patch, rcs
Recommends: rsync, curl, ssh, libmail-sendmail-perl, libemail-valid-perl
-Conflicts: git
+Suggests: cogito
+Conflicts: git, cogito ( 0.13)
Description: The git content addressable filesystem
GIT comes in two layers. The bottom layer is merely an extremely fast
and flexible filesystem-based database designed to store directory trees
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cogito bugfixes and cleanups, mainly Debian things
Ignore more generated files. Signed-off-by: Tommi Virtanen [EMAIL PROTECTED] --- commit 91aeeed108292bb42f7b133da13ec6881cf84a9e tree fd0dc430a655fde2a21a9634c914b22db0ee96ce parent c1970992d81e2c26d2d85ad65b0e2e90fbeee7f1 author Tommi Virtanen [EMAIL PROTECTED] Fri, 26 Aug 2005 13:34:07 +0300 committer Tommi Virtanen [EMAIL PROTECTED] Fri, 26 Aug 2005 13:34:07 +0300 .gitignore |2 ++ Documentation/.gitignore |1 + 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore --- a/.gitignore +++ b/.gitignore @@ -1 +1,3 @@ cg-version +build-stamp +configure-stamp diff --git a/Documentation/.gitignore b/Documentation/.gitignore --- a/Documentation/.gitignore +++ b/Documentation/.gitignore @@ -1,2 +1,3 @@ *.html cogito.txt +*.[1-9] - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb - XMMS2 project customisations
On Fri, Aug 26, 2005 at 07:16:05PM +0800, Sham Chukoury wrote: G'day. I figured you folks might be interested in a number of modifications the XMMS2 team have made to gitweb. All the changes can be seen at http://git.xmms.se 1) Navbar refactoring (gitweb-xmms2navbar.diff) 3) Snapshot integration (gitweb-xmms2snapshots.diff snapshot.cgi) I've sent similar patches to the git mailing list almost two months ago, but Kay didn't take them. Maybe you could compare with my version http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary (I'll be mostly offline for the next couple of days.) skimo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix pulling into the same branch.
Hi, On Thu, 25 Aug 2005, Junio C Hamano wrote: This patch is to show my current thinking. Please let me know what you think. I like it. As Linus stated, the index originally had a different role from what it has now, so it really should be an internal git thing, i.e. the git user should not expect the index not to change when pulling. Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Storing state in $GIT_DIR
Martin Langhoff [EMAIL PROTECTED] writes: On 8/26/05, Eric W. Biederman [EMAIL PROTECTED] wrote: Thinking about it going from arch to git should be just a matter of checking sha1 hashes, possibly back to the beginning of the arch tree. Yup, though actually replaying the tree to compute the hashes is something I just _won't_ do ;) I guess if you have the tla branch names it won't be necessary. If you are careful how you do the import you can have two parallel imports of the same data and produce exactly the same git tree. That is largely why I care about a stable algorithm for the hashes. Going from git to arch is the trickier mapping, because you need to know the full repo--category--branch--version--patch mapping. My plan doesn't include git-arch support... yet... One of my interests, and if I get the time to worry about it is to get a scm that is a sufficient superset of what other scms do so it can serve as a bidirectional gateway. git is fairly close to what is needed to implement that. Hmm. I wonder if a git metadata branch in general is sufficient to store information that does not map to git natively? Hmm. Thinking about arch from a git perspective arch tags every commit. So the really sane thing to do (I think) is to create a git tag object for every arch commit. Now I like that interesting idea. It doesn't solve all my problems, but is a reasonable mapping point. Will probably do it. With patch trading (Martin I think I know what you are refering to) arch does seem to have a concept that does not map very well to git, and this I think is a failing in git. I won't get into _that_ flamewar ;) pouts No flamewar /pouts My plan for merges is to detect when two branches up until what point branches are fully merged, and mark that in git -- because that is what git considers a merge. The rest will be known to the importer, but nothing else. I looked at least back to the StGit announcement and it helped to clarify my thinking. A patch is equivalent to a branch with just one change. This makes cherry picking a single patch roughly equivalent to describing that patch as a single commit branch at the fork point from the common ancestor of the two branches, and then having the single commit merged. The fact that the original branch that was cherry picked from can really only be represented as a an graft. Like the original linux kernel history. The shortcoming I see in git-applypatch is that it doesn't attempt to find the original base of a patch and instead simply assumes it is against the current tree. There is a similar short coming in git-diff-tree where it reports the commit that you are on when take the diff, but it does not report the commit the diff is against. .. Thinking a little more there is also a connection with reverting patches. Cherry picking changes from a branch may also be thought of as reverting all of the other changes from a branch and then merging the branch. The practical impact of all of these things is there a form that will allow future merges to realize the same change has already been applied so it can skip it the second time. Inter-operating with darcs, tla, quilt, and raw diff/patch brings up these issues. So my practical questions are: - What information can a current git merge algorithms and more sophisticated merge algorithms use to avoid having conflicts when the same changes are merged into the same branch multiple times? - Is the git meta data sufficient to represent the history sophisticated merge algorithms can use. - Is the git meta data sufficient to represent the result of sufficient meta data operations. - Is the current representation of a reverted change sufficient for the merge algorithms, or could they do a better job if they new a change was revert of a previous change. I'm just trying to think through the issues that working with patch based systems bring up. Eric - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] GIT 0.99.5
Junio C Hamano [EMAIL PROTECTED] writes: Documentation - A nit but possibly an important for 1.0 there are quite a few git commands that don't have man pages or whose man pages are currently very poor. Getting the code sane and stable of course comes first but if people can't figure out how to use git... Eric - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] GIT 0.99.5
[EMAIL PROTECTED] (Eric W. Biederman) writes: A nit but possibly an important for 1.0 there are quite a few git commands that don't have man pages or whose man pages are currently very poor. Getting the code sane and stable of course comes first but if people can't figure out how to use git... I have been worried about that since I posted my first last mile message. My excuse is that there are only 24 hours in a day. Patches welcome. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix pulling into the same branch.
Johannes Schindelin [EMAIL PROTECTED] writes: I like it. As Linus stated, the index originally had a different role from what it has now, so it really should be an internal git thing, i.e. the git user should not expect the index not to change when pulling. Actually the issue and the way patch addresses it is not limited to the index file. The problem is that the relashionship between your working tree and the $GIT_DIR/HEAD commit changes unexpectedly (from the POV of the working tree) when the ref being updated by the push in reverse machinery happens to be the head of the branch you are currently on. The working tree is supposed to be based on $GIT_DIR/HEAD, but after the push in reverse. This fix is about fast forwarding the working tree, including the checked out files on the filesystem, to the updated head when it happens. I am tempted to move this logic to git fetch instead, because it has the same issue. Tony's linus branch example has been updated to do a git fetch instead of git pull from the earlier description in his howto, but if he happens to be on the linus branch, he would still have this same problem. Of course, doing this in git fetch needs to be done a bit more carefully than in git pull, because by definition pull is a fetch followed by merging into the working tree, implying that the repository has an associated working tree. But fetch by itself can be used for a naked repository [*1*], and we should not unconditionally attempt to update the working tree that may not exist. I am planning to use the lack of index file for this detection, but I've seen some people made an rsync copy of their private repository as a whole to publish, so this heuristic may probabaly break. Maybe the lack of $GIT_DIR/index and $GIT_DIR not ending with /.git and not being .git? I am undecided. In the meantime, warning the user about the issue and suggesting how to do the fast-forwarding of the working tree himself in the warning message might be the safest and the most sensible thing to do. [Footnote] *1* Do we want a term in the glossary to mean repositories like linux-2.6.git and git.git that do not have associated working trees? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fix pulling into the same branch.
I am tempted to move this logic to git fetch instead, because it has the same issue. Tony's linus branch example has been updated to do a git fetch instead of git pull from the earlier description in his howto, but if he happens to be on the linus branch, he would still have this same problem. I don't spend much time on the linus branch (just to build an updated cscope database, etc.). I never want to check anything in on that branch [sometime I should figure out how use the hooks to keep me from shooting myself in the foot here]. In the meantime, warning the user about the issue and suggesting how to do the fast-forwarding of the working tree himself in the warning message might be the safest and the most sensible thing to do. Yes please ... a big fat warning with coloured flashing lights and explosions from the sound card. -Tony - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix: remove generated template files
Marco Costalba [EMAIL PROTECTED] writes: 01168c6044e7ebb570e851b4707b4fe0c7f40c15 diff --git a/templates/blt/description b/templates/blt/description Could I please see output of the following command in your repository? $ git whatchanged 01168c6044e7ebb570e851b4707b4fe0c7f40c15 templates/ - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] A new merge algorithm (EXPERIMENTAL)
On Fri, Aug 26, 2005 at 04:48:32PM -0400, Daniel Barkalow wrote: On Fri, 26 Aug 2005, Fredrik Kuivinen wrote: I will try to describe how the algorithm works. The problem with the usual 3-way merge algorithm is that we sometimes do not have a unique common ancestor. In [1] B and C seems to be equally good. What this algorithm does is to _merge_ the common ancestors, in this case B and C, into a temporary tree lets call it T. It does then use this temporary tree T as the common ancestor for D and E to produce the final merge result. In the case described in [1] this will work out fine and we get a clean merge with the expected result. The only problem I can see with this is that it's likely to generate conflicts between the shared heads, and the user is going to be confused trying to resolve them, because the files with the conflicts will be missing all of the more recent changes. I don't actually think that conflicts between shared heads is a problem. Given the criss-cross case (we want to merge A and B into M): M |\ | \ A B |\/| |/\| C D | / |/ E Lets assume there is a merge conflict if we try to merge C and D (which are the two shared heads). Then both A and B must resolve this conflict. If they have done it in the same way we wont get a merge conflict at M, if they have resolved it differently we will get a merge conflict. In the first case there is no merge conflict at M, in the second case the user has to pick which one of the two different resolutions she wants. Note that the algorithm will happily write non-clean merge results to the object database during the merge shared heads stage. Hence, when we are merging C and D internally we will _not_ ask the user to resolve any eventual merge conflicts. Other than that, I think it should give the right answer, although it will presumably involve a lot of ancient history doing the internal merge. (Which would probably be really painful if you've got two branches that cross-merge regularly and never actually completely sync) The expensive part is the repeated merging. But as I wrote in my mail multiple shared heads seems to be pretty uncommon. As far as I can tell there is no reason for the number of shared heads to increase as a repository grows larger. However, this do probably depend on usage patterns. But it is certainly possible to construct cases with an arbitrary number of shared heads. In which case the algorithm will be a bit slow, at least if there are real content merges going on which are handled by merge(1). I'm getting pretty close to having a version of read-tree that does the trivial merge portion based comparing the sides against all of the shared heads. I think yours will be better for the cases we've identified, giving the correct answer for Tony's case rather than reporting a conflict, but it's clearly more complicated. I think my changes are worthwhile anyway, since they make the merging logic more central, but obviously insufficient. I've been thinking that could be useful to have read-tree figure out the history itself, instead of being passed ancestors, in which case it could use your method, except more efficiently (and only look further at the history when needed). It will be interesting to have a look at the code when you are done. I find the Git architecture with respect to merging to be quite nice. A core which handles the simple cases _fast_ and let the more complicated cases be handled by someone else. - Fredrik - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] A new merge algorithm (EXPERIMENTAL)
On Fri, 26 Aug 2005, Fredrik Kuivinen wrote: In real numbers it is as follows: In Linus' kernel tree there are 5996 commits. 400 of those have more than one parent. Of those 400 merge commits 4 have more than one shared head. Ok, that's already interesting in itself. I was wanting to re-run all the merges with the new git-merge-base -a to see which merges might have had different merge bases, and you've actually done that. Interesting to see the numbers. * Is it worth it? That is, is the added complexity in the merge logic worth the advantages of correctly handling some strange (but real life) merge cases? I am of two minds on this. I hate the notion of a more complex merge. But at the same time, it clearly is a very interesting case when we do have multiple possible shared parents, and I think that at the very least we should warn the user. And using a more complex merge algorithm when it happens seems to be a very valid thing to do. Also, it's possible that other developers see more of the criss-crossing merges than I do - iow, they're probably more likely to happen in the throw-away trees than in some of the main trees. Neither of the two cases we've seen and had issues were merges I did, for example. Which means that your 1% of all merges number is probably low. Of course, it's quite likely that in most cases, the pick either one approach will give the exact same result as the more complex merge. Using python, which people have less exposure to, sounds like an additional thorny issue.. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] A new merge algorithm (EXPERIMENTAL)
Linus Torvalds [EMAIL PROTECTED] writes: On Fri, 26 Aug 2005, Fredrik Kuivinen wrote: In real numbers it is as follows: In Linus' kernel tree there are 5996 commits. 400 of those have more than one parent. Of those 400 merge commits 4 have more than one shared head. Ok, that's already interesting in itself. I was wanting to re-run all the merges with the new git-merge-base -a to see which merges might have had different merge bases, and you've actually done that. Interesting to see the numbers. Fredrik, mind giving us the commit ID of those four for us to take a look at them? I am of two minds on this. I hate the notion of a more complex merge. But at the same time, it clearly is a very interesting case when we do have multiple possible shared parents, and I think that at the very least we should warn the user. And using a more complex merge algorithm when it happens seems to be a very valid thing to do. I agree. GIT is lightening fast for trivial cases and we can afford to spend more time to handle more complex ones carefully, at the same time telling the user what we are doing is a good thing. Using python, which people have less exposure to, sounds like an additional thorny issue.. Not too big a problem for me to follow the patch ;-). - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove git-apply-patch-script.
Now the rebase is rewritten to use git cherry-pick, there is no user
for that ancient script. I've checked Cogito and StGIT to make sure
they do not use it.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
Documentation/git-apply-patch-script.txt | 32
Documentation/git.txt |3
.../howto/rebase-from-internal-branch.txt |2
Makefile |2
git-apply-patch-script | 144
git-cherry | 14 --
6 files changed, 4 insertions(+), 193 deletions(-)
delete mode 100644 Documentation/git-apply-patch-script.txt
delete mode 100755 git-apply-patch-script
ad3f5eb30999095f276f8d4664f3e7884296c797
diff --git a/Documentation/git-apply-patch-script.txt
b/Documentation/git-apply-patch-script.txt
deleted file mode 100644
--- a/Documentation/git-apply-patch-script.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-git-apply-patch-script(1)
-=
-v0.99.4, May 2005
-
-NAME
-
-git-apply-patch-script - Sample script to apply the diffs from git-diff-*
-
-
-SYNOPSIS
-
-'git-apply-patch-script'
-
-DESCRIPTION
-This is a sample script to be used via the 'GIT_EXTERNAL_DIFF'
-environment variable to apply the differences that the git-diff-*
-family of commands report to the current work tree.
-
-
-Author
---
-Written by Junio C Hamano [EMAIL PROTECTED]
-
-Documentation
---
-Documentation by David Greaves, Junio C Hamano and the git-list
git@vger.kernel.org.
-
-GIT
-Part of the link:git.html[git] suite
-
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -242,9 +242,6 @@ Ancillary Commands
--
Manipulators:
-link:git-apply-patch-script.html[git-apply-patch-script]::
- Sample script to apply the diffs from git-diff-*
-
link:git-convert-cache.html[git-convert-cache]::
Converts old-style GIT repository
diff --git a/Documentation/howto/rebase-from-internal-branch.txt
b/Documentation/howto/rebase-from-internal-branch.txt
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -38,7 +38,7 @@ ancestry graph looked like this:
So I started from master, made a bunch of edits, and committed:
$ git checkout master
-$ cd Documentation; ed git.txt git-apply-patch-script.txt ...
+$ cd Documentation; ed git.txt ...
$ cd ..; git add Documentation/*.txt
$ git commit -s -v
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -57,7 +57,7 @@ SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powe
-SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \
+SCRIPTS=git git-merge-one-file-script git-prune-script \
git-pull-script git-tag-script git-resolve-script git-whatchanged \
git-fetch-script git-status-script git-commit-script \
git-log-script git-shortlog git-cvsimport-script git-diff-script \
diff --git a/git-apply-patch-script b/git-apply-patch-script
deleted file mode 100755
--- a/git-apply-patch-script
+++ /dev/null
@@ -1,144 +0,0 @@
-#!/bin/sh
-# Copyright (C) 2005 Junio C Hamano
-#
-# Applying diff between two trees to the work tree can be
-# done with the following single command:
-#
-# GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p $tree1 $tree2
-#
-
-case $# in
-1)
-echo 2 cannot handle unmerged diff on path $1.
-exit 1 ;;
-8 | 9)
-echo 2 cannot handle rename diff between $1 and $8 yet.
-exit 1 ;;
-esac
-name=$1 tmp1=$2 hex1=$3 mode1=$4 tmp2=$5 hex2=$6 mode2=$7
-
-type1=f
-case $mode1 in
-*120???) type1=l ;;
-*1007??) mode1=+x ;;
-*1006??) mode1=-x ;;
-.) type1=- ;;
-esac
-
-type2=f
-case $mode2 in
-*120???) type2=l ;;
-*1007??) mode2=+x ;;
-*1006??) mode2=-x ;;
-.) type2=- ;;
-esac
-
-case $type1,$type2 in
-
--,?)
-dir=$(dirname $name)
-case $dir in '' | .) ;; *) mkdir -p $dir ;; esac || {
- echo 2 cannot create leading path for $name.
- exit 1
-}
-if test -e $name
-then
- echo 2 path $name to be created already exists.
- exit 1
-fi
-case $type2 in
-f)
-# creating a regular file
- cat $tmp2 $name || {
- echo 2 cannot create a regular file $name.
- exit 1
- }
- case $mode2 in
- +x)
- echo 2 created a regular file $name with mode +x.
- chmod $mode2 $name
- ;;
- -x)
- echo 2 created a regular file $name.
-;;
-esac
- ;;
-l)
-# creating a symlink
-ln -s $(cat $tmp2) $name || {
- echo 2 cannot create a symbolic link $name.
- exit 1
- }
- echo 2 created a symbolic link $name.
-;;
-*)
-echo 2 do not know how to create $name of type $type2.
- exit 1
-
[HOWTO] Using post-update hook
The pages under http://www.kernel.org/pub/software/scm/git/docs/ are built from Documentation/ directory of the git.git project and needed to be kept up-to-date. The www.kernel.org/ servers are mirrored and I was told that the origin of the mirror is on the machine master.kernel.org, on which I was given an account when I took over git maintainership from Linus. The directories relevant to this how-to are these two: /pub/scm/git/git.git/ The public git repository. /pub/software/scm/git/docs/ The HTML documentation page. So I made a repository to generate the documentation under my home directory over there. $ cd $ mkdir doc-git cd doc-git $ git clone /pub/scm/git/git.git/ docgen What needs to happen is to update the $HOME/doc-git/docgen/ working tree, build HTML docs there and install the result in /pub/software/scm/git/docs/ directory. So I wrote a little script: $ cat dododoc.sh \EOF #!/bin/sh cd $HOME/doc-git/docgen || exit unset GIT_DIR git pull /pub/scm/git/git.git/ master cd Documentation make install-webdoc EOF Initially I used to run this by hand whenever I push into the public git repository. Then I did a cron job that ran twice a day. The current round uses the post-update hook mechanism, like this: $ cat /pub/scm/git/git.git/hooks/post-update \EOF #!/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. case $* in *' refs/heads/master '*) echo $HOME/doc-git/dododoc.sh | at now ;; esac exec git-update-server-info EOF $ chmod +x /pub/scm/git/git.git/hooks/post-update There are three things worth mentioning: - The update-hook is run after the repository accepts a git push, under my user privilege. It is given the full names of refs that have been updated as arguments. My post-update runs the dododoc.sh script only when the master head is updated. - When update-hook is run, GIT_DIR is set to '.' by the calling receive-pack. This is inherited by the dododoc.sh run via the at command, and needs to be unset; otherwise, git pull it does into $HOME/doc-git/docgen/ repository would not work correctly. - This is still crude and does not protect against simultaneous make invocations stomping on each other. I would need to add some locking mechanism for this. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Subject: [PATCH] Add some documentation.
Add some documentation. Text taken from the the commit messages and the command sources. --- I made no attempt to use the proper terminology, as defined by the new glossary, but instead used the text from the original commit messages and/or the program source. These are some of the easy ones. Some others (like git-diff-script) will require real effort to adequately document. Hopefully I followed my own instructions correctly and will avoid being hit by the shiny blue bat. :-) Documentation/git-add-script.txt | 17 ++--- Documentation/git-branch-script.txt| 19 ++- Documentation/git-cherry.txt | 22 +- Documentation/git-count-objects-script.txt | 18 -- Documentation/git-patch-id.txt | 19 +-- Documentation/git-rebase-script.txt| 17 +++-- Documentation/git-relink-script.txt| 19 +-- Documentation/git-revert-script.txt| 18 +++--- Documentation/git-sh-setup-script.txt | 18 +++--- Documentation/git-verify-tag-script.txt| 16 +--- 10 files changed, 77 insertions(+), 106 deletions(-) a02a9ef2a347e4fac8088fb289dd24c7110c4ee4 diff --git a/Documentation/git-add-script.txt b/Documentation/git-add-script.txt --- a/Documentation/git-add-script.txt +++ b/Documentation/git-add-script.txt @@ -3,26 +3,21 @@ git-add-script(1) NAME -git-add-script - Some git command not yet documented. - +git-add-script - Add files to the cache. SYNOPSIS -'git-add-script' [ --option ] args... +'git-add-script' [file]\+ DESCRIPTION --- -Does something not yet documented. - +A simple wrapper to git-update-cache to add files to the cache for people used +to do cvs add. OPTIONS --- ---option:: - Some option not yet documented. - -args...:: - Some argument not yet documented. - +file:: + Files to add to the cache. Author -- diff --git a/Documentation/git-branch-script.txt b/Documentation/git-branch-script.txt --- a/Documentation/git-branch-script.txt +++ b/Documentation/git-branch-script.txt @@ -3,26 +3,27 @@ git-branch-script(1) NAME -git-branch-script - Some git command not yet documented. - +git-branch-script - Create a new branch. SYNOPSIS -'git-branch-script' [ --option ] args... +'git-branch-script' [branchname [start-point]] DESCRIPTION --- -Does something not yet documented. +If no argument is provided, show available branches and mark current +branch with star. Otherwise, create a new branch of name branchname. +If a starting point is also specified, that will be where the branch is +created, otherwise it will be created at the current HEAD. OPTIONS --- ---option:: - Some option not yet documented. - -args...:: - Some argument not yet documented. +branchname:: + The name of the branch to create. +start-point:: + Where to make the branch; defaults to HEAD. Author -- diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt --- a/Documentation/git-cherry.txt +++ b/Documentation/git-cherry.txt @@ -3,26 +3,30 @@ git-cherry(1) NAME -git-cherry - Some git command not yet documented. - +git-cherry - Find commits not merged upstream. SYNOPSIS -'git-cherry' [ --option ] args... +'git-cherry' [-v] upstream [head] DESCRIPTION --- -Does something not yet documented. - +Each commit between the fork-point and head is examined, and compared against +the change each commit between the fork-point and upstream introduces. +Commits already included in upstream are prefixed with '-' (meaning drop from +my local pull), while commits missing from upstream are prefixed with '+' +(meaning add to the updated upstream). OPTIONS --- ---option:: - Some option not yet documented. +-v:: + Verbose. -args...:: - Some argument not yet documented. +upstream:: + Upstream branch to compare against. +head:: + Working branch; defaults to HEAD. Author -- diff --git a/Documentation/git-count-objects-script.txt b/Documentation/git-count-objects-script.txt --- a/Documentation/git-count-objects-script.txt +++ b/Documentation/git-count-objects-script.txt @@ -3,26 +3,16 @@ git-count-objects-script(1) NAME -git-count-objects-script - Some git command not yet documented. - +git-count-objects-script - Reports on unpacked objects. SYNOPSIS -'git-count-objects-script' [ --option ] args... +'git-count-objects-script' DESCRIPTION --- -Does something not yet documented. - - -OPTIONS ---option:: - Some option not yet documented. - -args...:: - Some argument not yet documented. - +This counts the number of unpacked object files and disk space consumed by +them, to help you decide when it is a good time to repack. Author -- diff --git
[PATCH] Redo revert using three-way merge machinery.
The reverse patch application using git apply sometimes is too
rigid. Since the user would get used to resolving conflicting merges
by hand during the normal merge experience, using the same machinery
would be more helpful rather than just giving up.
Cherry-picking and reverting are essentially the same operation.
You pick one commit, and apply the difference that commit introduces
to its own commit ancestry chain to the current tree. Revert applies
the diff in reverse while cherry-pick applies it forward. They share
the same logic, just different messages and merge direction.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
* I've reorganized some patches and merged a couple into one.
* An earlier version of this patch was already sent to the
* list, but this is a rework.
Makefile|1
git-revert-script | 185 +++
git-sh-setup-script | 11 +++
3 files changed, 167 insertions(+), 30 deletions(-)
0fa9fd414efbf73f1394b983d0f643b60d383ce0
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -215,6 +215,7 @@ check:
install: $(PROG) $(SCRIPTS)
$(INSTALL) -m755 -d $(DESTDIR)$(bindir)
$(INSTALL) $(PROG) $(SCRIPTS) $(DESTDIR)$(bindir)
+ $(INSTALL) git-revert-script $(DESTDIR)$(bindir)/git-cherry-pick-script
$(MAKE) -C templates install
$(MAKE) -C tools install
diff --git a/git-revert-script b/git-revert-script
--- a/git-revert-script
+++ b/git-revert-script
@@ -1,37 +1,162 @@
#!/bin/sh
+#
+# Copyright (c) 2005 Linus Torvalds
+# Copyright (c) 2005 Junio C Hamano
+#
. git-sh-setup-script || die Not a git archive
-# We want a clean tree and clean index to be able to revert.
-status=$(git status)
-case $status in
-'nothing to commit') ;;
+case $0 in
+*-revert-* )
+ me=revert ;;
+*-cherry-pick-* )
+ me=cherry-pick ;;
+esac
+
+usage () {
+ case $me in
+ cherry-pick)
+ die usage git $me [-n] [-r] commit-ish
+ ;;
+ revert)
+ die usage git $me [-n] commit-ish
+ ;;
+ esac
+}
+
+no_commit= replay=
+while case $# in 0) break ;; esac
+do
+ case $1 in
+ -n|--n|--no|--no-|--no-c|--no-co|--no-com|--no-comm|\
+ --no-commi|--no-commit)
+ no_commit=t
+ ;;
+ -r|--r|--re|--rep|--repl|--repla|--replay)
+ replay=t
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+done
+
+test $me,$replay = revert,t usage
+
+case $no_commit in
+t)
+ # We do not intend to commit immediately. We just want to
+ # merge the differences in.
+ head=$(git-write-tree) ||
+ die Your index file is unmerged.
+ ;;
*)
- echo $status
- die Your working tree is dirty; cannot revert a previous patch. ;;
+ check_clean_tree || die Cannot run $me from a dirty tree.
+ head=$(git-rev-parse --verify HEAD) ||
+ die You do not have a valid HEAD
+ ;;
esac
rev=$(git-rev-parse --verify $@)
-commit=$(git-rev-parse --verify $rev^0) || exit
-if git-diff-tree -R -M -p $commit | git-apply --index
- msg=$(git-rev-list --pretty=oneline --max-count=1 $commit)
-then
-{
-echo $msg | sed -e '
- s/^[^ ]* /Revert /
- s/$//'
-echo
-echo This reverts $commit commit.
-test $rev = $commit ||
-echo (original 'git revert' arguments: $@)
-} | git commit -F -
-else
-# Now why did it fail?
-parents=`git-cat-file commit $commit 2/dev/null |
-sed -ne '/^$/q;/^parent /p' |
-wc -l`
-case $parents in
-0) die Cannot revert the root commit nor non commit-ish. ;;
-1) die The patch does not apply. ;;
-*) die Cannot revert a merge commit. ;;
-esac
-fi
+commit=$(git-rev-parse --verify $rev^0) ||
+ die Not a single commit $@
+prev=$(git-rev-parse --verify $commit^1 2/dev/null) ||
+ die Cannot run $me a root commit
+git-rev-parse --verify $commit^2 /dev/null 21
+ die Cannot run $me a multi-parent commit.
+
+# commit is an existing commit. We would want to apply
+# the difference it introduces since its first parent prev
+# on top of the current HEAD if we are cherry-pick. Or the
+# reverse of it if we are revert.
+
+case $me in
+revert)
+ git-rev-list --pretty=oneline --max-count=1 $commit |
+ sed -e '
+ s/^[^ ]* /Revert /
+ s/$//'
+ echo
+ echo This reverts $commit commit.
+ test $rev = $commit ||
+ echo (original 'git revert' arguments: $@)
+ base=$commit next=$prev
+ ;;
+
+cherry-pick)
+ pick_author_script='
+ /^author /{
+ h
+ s/^author \([^]*\) [^]* .*$/\1/
+
[PATCH] Use git cherry-pick in git rebase
Rewrite git rebase using git cherry-pick.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
git-rebase-script | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
913404ae6371857c21c696cc3d8b0a04421fdeb2
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -37,7 +37,7 @@ git-rev-parse --verify $upstream^0 $
tmp=.rebase-tmp$$
fail=$tmp-fail
-trap rm -rf $tmp-* 0 1 2 3 15
+trap rm -rf $tmp-* 1 2 3 15
$fail
@@ -48,14 +48,18 @@ do
-) continue ;;
esac
S=`cat $GIT_DIR/HEAD`
-GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p $commit
- git-commit-script -C $commit || {
+ git-cherry-pick-script --replay $commit || {
+ echo 2 * Not applying the patch and continuing.
echo $commit $fail
- git-read-tree --reset -u $S
+ git-reset-script --hard $S
}
done
if test -s $fail
then
- echo Some commits could not be rebased, check by hand:
- cat $fail
+ echo 2 Some commits could not be rebased, check by hand:
+ cat 2 $fail
+ echo 2 (the same list of commits are found in $tmp)
+ exit 1
+else
+ rm -f $fail
fi
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] A new merge algorithm (EXPERIMENTAL)
On Fri, Aug 26, 2005 at 06:08:33PM -0700, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: On Fri, 26 Aug 2005, Fredrik Kuivinen wrote: In real numbers it is as follows: In Linus' kernel tree there are 5996 commits. 400 of those have more than one parent. Of those 400 merge commits 4 have more than one shared head. Ok, that's already interesting in itself. I was wanting to re-run all the merges with the new git-merge-base -a to see which merges might have had different merge bases, and you've actually done that. Interesting to see the numbers. Fredrik, mind giving us the commit ID of those four for us to take a look at them? Sure, they are: 467ca22d3371f132ee225a5591a1ed0cd518cb3d which has two shared heads 7e2987503dda95a5f80290bb8c06279009c2419e and eff910a91ac04ab1d9e210d4f721484af3b39c8d 0e396ee43e445cb7c215a98da4e76d0ce354d9d7 with the heads 462cee296476278acaa54c41925b3273e0e4dd40 and 8be3de3fd8469154a2b3e18a4712032dac5b4a53 3190186362466658f01b2e354e639378ce07e1a9 with 38d84c3bd6dd22bdb1f797c87006931133d71aea and 46906c4415f88cebfad530917bada0835d651824 and finally da28c12089dfcfb8695b6b555cdb8e03dda2b690 with 9e566d8bd61f939b7f5d7d969f5b178571471cf9 and 18190cc08d70a6ec8ef69f0f6ede021f7cb3f9b8 (The script which finds those commits also prints out the commit id of any octopus commits. There is one commit with more than two parents in the kernel repository, 13e652800d1644dfedcd0d59ac95ef0beb7f3165. However, it only looks like that commit has three parents, two of them are actually identical.) I am of two minds on this. I hate the notion of a more complex merge. But at the same time, it clearly is a very interesting case when we do have multiple possible shared parents, and I think that at the very least we should warn the user. And using a more complex merge algorithm when it happens seems to be a very valid thing to do. I agree. GIT is lightening fast for trivial cases and we can afford to spend more time to handle more complex ones carefully, at the same time telling the user what we are doing is a good thing. Using python, which people have less exposure to, sounds like an additional thorny issue.. Not too big a problem for me to follow the patch ;-). Good to know :) I mainly wanted to try the idea with the new algorithm, so some kind of high level language seemed like a good choice. - Fredrik - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix pulling into the same branch.
Luck, Tony [EMAIL PROTECTED] writes: In the meantime, warning the user about the issue and suggesting how to do the fast-forwarding of the working tree himself in the warning message might be the safest and the most sensible thing to do. Yes please ... a big fat warning with coloured flashing lights and explosions from the sound card. Yeah, but what to do afterwards? I can see this as an compromise: * git fetch, just like the updated git pull, reads $GIT_DIR/HEAD before it starts its work, and compares it with $GIT_DIR/HEAD after it is done. If the --update-head-ok flag is not given on the command line, and if the HEAD changed, then barf and exit with non-zero status after reverting $GIT_DIR/HEAD to its original value. If --update-head-ok is given, none of the above check and revert happens. * git pull calls git fetch with the extra flag, and does its thing the current way. So if you are calling from the command line, git fetch linus, when you were still on linus branch (which you do not normally do but just to prevent mistakes), it would trigger the check and your $GIT_DIR/HEAD would stay intact. If you stayed on your own branch, git fetch linus would continue to just fast forward linus head without touching the working tree. Come to think of it, it may be cleaner to simply forbid fast-forward fetching into the current repository (whether it is git fetch or git pull). At least in your workflow you do not do that ever anyway. Johannes, what do you think, as the original advocate of push in reverse? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of Mac OS/X ports of git and cogito?
John Ellson [EMAIL PROTECTED] writes: Do git and cogito build easily on Mac OS/X now? Are there binaries available anywhere? Not that I know of. We used to get portability patches from Darwin folks, but I haven't seen any lately. I am somewhat interested in what portability glitches we still have, but not having an access to a machine, it is more of a curiosity rather than a necessity for me. Are Darwin folks on the list happy with the current codebase, or have you given up because it is too GNU/Linux specific? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[FIB_TRIE]: Don't ignore negative results from fib_semantic_match
tree 01d66754d441b84cb09fe28f875cbb47b3b9fb0c
parent 0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf
author Patrick McHardy [EMAIL PROTECTED] Wed, 24 Aug 2005 12:06:09 -0700
committer David S. Miller [EMAIL PROTECTED] Wed, 24 Aug 2005 12:06:09 -0700
[FIB_TRIE]: Don't ignore negative results from fib_semantic_match
When a semantic match occurs either success, not found or an error
(for matching unreachable routes/blackholes) is returned. fib_trie
ignores the errors and looks for a different matching route. Treat
results other than no match as success and end lookup.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
net/ipv4/fib_trie.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1333,9 +1333,9 @@ err:;
}
static inline int check_leaf(struct trie *t, struct leaf *l, t_key key, int
*plen, const struct flowi *flp,
-struct fib_result *res, int *err)
+struct fib_result *res)
{
- int i;
+ int err, i;
t_key mask;
struct leaf_info *li;
struct hlist_head *hhead = l-list;
@@ -1348,18 +1348,18 @@ static inline int check_leaf(struct trie
if (l-key != (key mask))
continue;
- if (((*err) = fib_semantic_match(li-falh, flp, res, l-key,
mask, i)) == 0) {
+ if ((err = fib_semantic_match(li-falh, flp, res, l-key,
mask, i)) = 0) {
*plen = i;
#ifdef CONFIG_IP_FIB_TRIE_STATS
t-stats.semantic_match_passed++;
#endif
- return 1;
+ return err;
}
#ifdef CONFIG_IP_FIB_TRIE_STATS
t-stats.semantic_match_miss++;
#endif
}
- return 0;
+ return 1;
}
static int
@@ -1386,7 +1386,7 @@ fn_trie_lookup(struct fib_table *tb, con
/* Just a leaf? */
if (IS_LEAF(n)) {
- if (check_leaf(t, (struct leaf *)n, key, plen, flp, res, ret))
+ if ((ret = check_leaf(t, (struct leaf *)n, key, plen, flp,
res)) = 0)
goto found;
goto failed;
}
@@ -1508,7 +1508,7 @@ fn_trie_lookup(struct fib_table *tb, con
continue;
}
if (IS_LEAF(n)) {
- if (check_leaf(t, (struct leaf *)n, key, plen, flp,
res, ret))
+ if ((ret = check_leaf(t, (struct leaf *)n, key, plen,
flp, res)) = 0)
goto found;
}
backtrace:
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[TG3]: Fix ethtool loopback test lockup
tree 3984a1dc8378d7a976be60523021036c8265a167 parent 06c7427021f1cc83703f14659d8405ca773ba1ef author Michael Chan [EMAIL PROTECTED] Fri, 26 Aug 2005 05:31:41 -0700 committer David S. Miller [EMAIL PROTECTED] Fri, 26 Aug 2005 05:31:41 -0700 [TG3]: Fix ethtool loopback test lockup The tg3_abort_hw() call in tg3_test_loopback() is causing lockups on some devices. tg3_abort_hw() disables the memory arbiter, causing tg3_reset_hw() to hang when it tries to write the pre-reset signature. tg3_abort_hw() should only be called after the pre-reset signature has been written. This is all done in tg3_reset_hw() so the tg3_abort_hw() call is unnecessary and can be removed. [ Also bump driver version and release date. -DaveM ] Signed-off-by: Michael Chan [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] drivers/net/tg3.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -66,8 +66,8 @@ #define DRV_MODULE_NAMEtg3 #define PFX DRV_MODULE_NAME: -#define DRV_MODULE_VERSION 3.36 -#define DRV_MODULE_RELDATE August 19, 2005 +#define DRV_MODULE_VERSION 3.37 +#define DRV_MODULE_RELDATE August 25, 2005 #define TG3_DEF_MAC_MODE 0 #define TG3_DEF_RX_MODE0 @@ -7865,8 +7865,6 @@ static int tg3_test_loopback(struct tg3 err = -EIO; - tg3_abort_hw(tp, 1); - tg3_reset_hw(tp); mac_mode = (tp-mac_mode ~MAC_MODE_PORT_MODE_MASK) | - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix oops in fs/locks.c on close of file with pending locks
tree 2fff144b1b85cdf362c1a774e77b34f204b93ebf parent fd589e0b662c1ea8cfb1e0d20d60a2510979865b author Steve French [EMAIL PROTECTED] Sat, 27 Aug 2005 00:42:59 -0500 committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 06:05:35 -0700 [PATCH] Fix oops in fs/locks.c on close of file with pending locks The recent change to locks_remove_flock code in fs/locks.c changes how byte range locks are removed from closing files, which shows up a bug in cifs. The assumption in the cifs code was that the close call sent to the server would remove any pending locks on the server on this file, but that is no longer safe as the fs/locks.c code on the client wants unlock of 0 to PATH_MAX to remove all locks (at least from this client, it is not possible AFAIK to remove all locks from other clients made to the server copy of the file). Note that cifs locks are different from posix locks - and it is not possible to map posix locks perfectly on the wire yet, due to restrictions of the cifs network protocol, even to Samba without adding a new request type to the network protocol (which we plan to do for Samba 3.0.21 within a few months), but the local client will have the correct, posix view, of the lock in most cases. The correct fix for cifs for this would involve a bigger change than I would like to do this late in the 2.6.13-rc cycle - and would involve cifs keeping track of all unmerged (uncoalesced) byte range locks for each remote inode and scanning that list to remove locks that intersect or fall wholly within the range - locks that intersect may have to be reaquired with the smaller, remaining range. Signed-off-by: Steve French [EMAIL PROTECTED] Signed-off-by: Dave Kleikamp [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] fs/cifs/file.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/file.c b/fs/cifs/file.c --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -643,7 +643,7 @@ int cifs_lock(struct file *file, int cmd netfid, length, pfLock-fl_start, numUnlock, numLock, lockType, wait_flag); - if (rc == 0 (pfLock-fl_flags FL_POSIX)) + if (pfLock-fl_flags FL_POSIX) posix_lock_file_wait(file, pfLock); FreeXid(xid); return rc; - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/hwmon/*: kfree() correct pointers
tree 0db3419ab73cabed542a18cd5c7da50b03df896c
parent d634cc15e8f2038dc9c078beae79f9382ada
author Alexey Dobriyan [EMAIL PROTECTED] Fri, 26 Aug 2005 01:49:14 +0400
committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 06:30:30 -0700
[PATCH] drivers/hwmon/*: kfree() correct pointers
The adm9240 driver, in adm9240_detect(), allocates a structure. The
error path attempts to kfree() -client field of it (second one),
resulting in an oops (or slab corruption) if the hardware is not present.
-client field in adm1026, adm1031, smsc47b397 and smsc47m1 is the first in
${HWMON}_data structure, but fix them too.
Signed-off-by: Jonathan Corbet [EMAIL PROTECTED]
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
drivers/hwmon/adm1026.c|2 +-
drivers/hwmon/adm1031.c|2 +-
drivers/hwmon/adm9240.c|2 +-
drivers/hwmon/smsc47b397.c |2 +-
drivers/hwmon/smsc47m1.c |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hwmon/adm1026.c b/drivers/hwmon/adm1026.c
--- a/drivers/hwmon/adm1026.c
+++ b/drivers/hwmon/adm1026.c
@@ -1691,7 +1691,7 @@ int adm1026_detect(struct i2c_adapter *a
/* Error out and cleanup code */
exitfree:
- kfree(new_client);
+ kfree(data);
exit:
return err;
}
diff --git a/drivers/hwmon/adm1031.c b/drivers/hwmon/adm1031.c
--- a/drivers/hwmon/adm1031.c
+++ b/drivers/hwmon/adm1031.c
@@ -834,7 +834,7 @@ static int adm1031_detect(struct i2c_ada
return 0;
exit_free:
- kfree(new_client);
+ kfree(data);
exit:
return err;
}
diff --git a/drivers/hwmon/adm9240.c b/drivers/hwmon/adm9240.c
--- a/drivers/hwmon/adm9240.c
+++ b/drivers/hwmon/adm9240.c
@@ -616,7 +616,7 @@ static int adm9240_detect(struct i2c_ada
return 0;
exit_free:
- kfree(new_client);
+ kfree(data);
exit:
return err;
}
diff --git a/drivers/hwmon/smsc47b397.c b/drivers/hwmon/smsc47b397.c
--- a/drivers/hwmon/smsc47b397.c
+++ b/drivers/hwmon/smsc47b397.c
@@ -298,7 +298,7 @@ static int smsc47b397_detect(struct i2c_
return 0;
error_free:
- kfree(new_client);
+ kfree(data);
error_release:
release_region(addr, SMSC_EXTENT);
return err;
diff --git a/drivers/hwmon/smsc47m1.c b/drivers/hwmon/smsc47m1.c
--- a/drivers/hwmon/smsc47m1.c
+++ b/drivers/hwmon/smsc47m1.c
@@ -495,7 +495,7 @@ static int smsc47m1_detect(struct i2c_ad
return 0;
error_free:
- kfree(new_client);
+ kfree(data);
error_release:
release_region(address, SMSC_EXTENT);
return err;
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bogus iounmap() in emac
tree 1d6d1e779fcbaed6f06bf49ed4ad630ecdf58ed1 parent 1f57ff89fee47a317e9e8ca63bf0f139802cc116 author Al Viro [EMAIL PROTECTED] Thu, 25 Aug 2005 22:59:48 +0100 committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 06:30:30 -0700 [PATCH] bogus iounmap() in emac Dumb typo: iounmap(local_pointer_variable). Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/net/ibm_emac/ibm_emac_core.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c --- a/drivers/net/ibm_emac/ibm_emac_core.c +++ b/drivers/net/ibm_emac/ibm_emac_core.c @@ -1253,7 +1253,7 @@ static int emac_init_tah(struct ocp_enet TAH_MR_CVR | TAH_MR_ST_768 | TAH_MR_TFS_10KB | TAH_MR_DTFP | TAH_MR_DIG); - iounmap(tahp); + iounmap(tahp); return 0; } - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bogus function type in qdio
tree c550c6ef8439e867ea2f73aebfca0fca0e09b64a
parent b6a9ad73897acb7ea4cf56aae0fc39ba1c471fba
author Al Viro [EMAIL PROTECTED] Thu, 25 Aug 2005 23:03:35 +0100
committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 06:30:30 -0700
[PATCH] bogus function type in qdio
In qdio_get_micros() volatile in return type is plain noise (even with old
gccisms it would make no sense - noreturn function returning __u64 is a
bit odd ;-)
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
drivers/s390/cio/qdio.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/cio/qdio.c b/drivers/s390/cio/qdio.c
--- a/drivers/s390/cio/qdio.c
+++ b/drivers/s390/cio/qdio.c
@@ -112,7 +112,7 @@ qdio_min(int a,int b)
/* SCRUBBER HELPER ROUTINES **/
-static inline volatile __u64
+static inline __u64
qdio_get_micros(void)
{
return (get_clock() 10); /* time12 is microseconds */
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] I2C hwmon: kfree fixes
tree b88e2d0d55bbc9788337c256dfd25b54d684e49e
parent 32818c2eb6b83ea5065c89e0c3cf774abc4dc02b
author Mark M. Hoffman [EMAIL PROTECTED] Sat, 27 Aug 2005 08:34:08 -0700
committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 09:37:12 -0700
[PATCH] I2C hwmon: kfree fixes
This patch fixes several instances of hwmon drivers kfree'ing the wrong
pointer; the existing code works somewhat by accident.
(akpm: plucked from Greg's queue based on lkml discussion. Finishes off the
patch from Jon Corbet)
Signed-off-by: Mark M. Hoffman [EMAIL PROTECTED]
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
drivers/hwmon/adm1026.c |2 +-
drivers/hwmon/adm1031.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/adm1026.c b/drivers/hwmon/adm1026.c
--- a/drivers/hwmon/adm1026.c
+++ b/drivers/hwmon/adm1026.c
@@ -325,7 +325,7 @@ int adm1026_attach_adapter(struct i2c_ad
int adm1026_detach_client(struct i2c_client *client)
{
i2c_detach_client(client);
- kfree(client);
+ kfree(i2c_get_clientdata(client));
return 0;
}
diff --git a/drivers/hwmon/adm1031.c b/drivers/hwmon/adm1031.c
--- a/drivers/hwmon/adm1031.c
+++ b/drivers/hwmon/adm1031.c
@@ -845,7 +845,7 @@ static int adm1031_detach_client(struct
if ((ret = i2c_detach_client(client)) != 0) {
return ret;
}
- kfree(client);
+ kfree(i2c_get_clientdata(client));
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] x86_64: Tell VM about holes in nodes
tree c75562513489f62c8dcfd41acd467bca3d3202cc
parent bebf4688e9dbbfdd421736685d607bced91a3c91
author Andi Kleen [EMAIL PROTECTED] Sat, 27 Aug 2005 08:34:10 -0700
committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 09:37:12 -0700
[PATCH] x86_64: Tell VM about holes in nodes
Some nodes can have large holes on x86-64.
This fixes problems with the VM allowing too many dirty pages because it
overestimates the number of available RAM in a node. In extreme cases you
can end up with all RAM filled with dirty pages which can lead to deadlocks
and other nasty behaviour.
This patch just tells the VM about the known holes from e820. Reserved
(like the kernel text or mem_map) is still not taken into account, but that
should be only a few percent error now.
Small detail is that the flat setup uses the NUMA free_area_init_node() now
too because it offers more flexibility.
(akpm: lotsa thanks to Martin for working this problem out)
Cc: Martin Bligh [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
arch/x86_64/kernel/e820.c | 34 ++
arch/x86_64/mm/init.c | 16
arch/x86_64/mm/numa.c |8 +++-
include/asm-x86_64/e820.h |2 ++
4 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/arch/x86_64/kernel/e820.c b/arch/x86_64/kernel/e820.c
--- a/arch/x86_64/kernel/e820.c
+++ b/arch/x86_64/kernel/e820.c
@@ -185,6 +185,40 @@ unsigned long __init e820_end_of_ram(voi
}
/*
+ * Compute how much memory is missing in a range.
+ * Unlike the other functions in this file the arguments are in page numbers.
+ */
+unsigned long __init
+e820_hole_size(unsigned long start_pfn, unsigned long end_pfn)
+{
+ unsigned long ram = 0;
+ unsigned long start = start_pfn PAGE_SHIFT;
+ unsigned long end = end_pfn PAGE_SHIFT;
+ int i;
+ for (i = 0; i e820.nr_map; i++) {
+ struct e820entry *ei = e820.map[i];
+ unsigned long last, addr;
+
+ if (ei-type != E820_RAM ||
+ ei-addr+ei-size = start ||
+ ei-addr = end)
+ continue;
+
+ addr = round_up(ei-addr, PAGE_SIZE);
+ if (addr start)
+ addr = start;
+
+ last = round_down(ei-addr + ei-size, PAGE_SIZE);
+ if (last = end)
+ last = end;
+
+ if (last addr)
+ ram += last - addr;
+ }
+ return ((end - start) - ram) PAGE_SHIFT;
+}
+
+/*
* Mark e820 reserved areas as busy for the resource manager.
*/
void __init e820_reserve_resources(void)
diff --git a/arch/x86_64/mm/init.c b/arch/x86_64/mm/init.c
--- a/arch/x86_64/mm/init.c
+++ b/arch/x86_64/mm/init.c
@@ -322,18 +322,26 @@ void zap_low_mappings(void)
void __init paging_init(void)
{
{
- unsigned long zones_size[MAX_NR_ZONES] = {0, 0, 0};
+ unsigned long zones_size[MAX_NR_ZONES];
+ unsigned long holes[MAX_NR_ZONES];
unsigned int max_dma;
+ memset(zones_size, 0, sizeof(zones_size));
+ memset(holes, 0, sizeof(holes));
+
max_dma = virt_to_phys((char *)MAX_DMA_ADDRESS) PAGE_SHIFT;
- if (end_pfn max_dma)
+ if (end_pfn max_dma) {
zones_size[ZONE_DMA] = end_pfn;
- else {
+ holes[ZONE_DMA] = e820_hole_size(0, end_pfn);
+ } else {
zones_size[ZONE_DMA] = max_dma;
+ holes[ZONE_DMA] = e820_hole_size(0, max_dma);
zones_size[ZONE_NORMAL] = end_pfn - max_dma;
+ holes[ZONE_NORMAL] = e820_hole_size(max_dma, end_pfn);
}
- free_area_init(zones_size);
+ free_area_init_node(0, NODE_DATA(0), zones_size,
+__pa(PAGE_OFFSET) PAGE_SHIFT, holes);
}
return;
}
diff --git a/arch/x86_64/mm/numa.c b/arch/x86_64/mm/numa.c
--- a/arch/x86_64/mm/numa.c
+++ b/arch/x86_64/mm/numa.c
@@ -126,9 +126,11 @@ void __init setup_node_zones(int nodeid)
{
unsigned long start_pfn, end_pfn;
unsigned long zones[MAX_NR_ZONES];
+ unsigned long holes[MAX_NR_ZONES];
unsigned long dma_end_pfn;
memset(zones, 0, sizeof(unsigned long) * MAX_NR_ZONES);
+ memset(holes, 0, sizeof(unsigned long) * MAX_NR_ZONES);
start_pfn = node_start_pfn(nodeid);
end_pfn = node_end_pfn(nodeid);
@@ -139,13 +141,17 @@ void __init setup_node_zones(int nodeid)
dma_end_pfn = __pa(MAX_DMA_ADDRESS) PAGE_SHIFT;
if (start_pfn dma_end_pfn) {
zones[ZONE_DMA] = dma_end_pfn - start_pfn;
+ holes[ZONE_DMA] = e820_hole_size(start_pfn, dma_end_pfn);
[PATCH] arm: fix IXP4xx flash resource range
tree 662163e453ee6514a13e844993700e96baa09260
parent 485761bd6a72d33b3d4fa884927b2b0d983b701e
author Deepak Saxena [EMAIL PROTECTED] Sat, 27 Aug 2005 08:34:11 -0700
committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 09:37:12 -0700
[PATCH] arm: fix IXP4xx flash resource range
We are currently reserving one byte more than actually needed by the flash
device and overlapping into the next I/O expansion bus window. This a)
causes us to allocate an extra page of VM due to ARM ioremap() alignment
code and b) could cause problems if another driver tries to request the
next expansion bus window.
Signed-off-by: Deepak Saxena [EMAIL PROTECTED]
Cc: Russell King [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
arch/arm/mach-ixp4xx/coyote-setup.c |2 +-
arch/arm/mach-ixp4xx/gtwx5715-setup.c |2 +-
arch/arm/mach-ixp4xx/ixdp425-setup.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-ixp4xx/coyote-setup.c
b/arch/arm/mach-ixp4xx/coyote-setup.c
--- a/arch/arm/mach-ixp4xx/coyote-setup.c
+++ b/arch/arm/mach-ixp4xx/coyote-setup.c
@@ -36,7 +36,7 @@ static struct flash_platform_data coyote
static struct resource coyote_flash_resource = {
.start = COYOTE_FLASH_BASE,
- .end= COYOTE_FLASH_BASE + COYOTE_FLASH_SIZE,
+ .end= COYOTE_FLASH_BASE + COYOTE_FLASH_SIZE - 1,
.flags = IORESOURCE_MEM,
};
diff --git a/arch/arm/mach-ixp4xx/gtwx5715-setup.c
b/arch/arm/mach-ixp4xx/gtwx5715-setup.c
--- a/arch/arm/mach-ixp4xx/gtwx5715-setup.c
+++ b/arch/arm/mach-ixp4xx/gtwx5715-setup.c
@@ -114,7 +114,7 @@ static struct flash_platform_data gtwx57
static struct resource gtwx5715_flash_resource = {
.start = GTWX5715_FLASH_BASE,
- .end= GTWX5715_FLASH_BASE + GTWX5715_FLASH_SIZE,
+ .end= GTWX5715_FLASH_BASE + GTWX5715_FLASH_SIZE - 1,
.flags = IORESOURCE_MEM,
};
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
b/arch/arm/mach-ixp4xx/ixdp425-setup.c
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -36,7 +36,7 @@ static struct flash_platform_data ixdp42
static struct resource ixdp425_flash_resource = {
.start = IXDP425_FLASH_BASE,
- .end= IXDP425_FLASH_BASE + IXDP425_FLASH_SIZE,
+ .end= IXDP425_FLASH_BASE + IXDP425_FLASH_SIZE - 1,
.flags = IORESOURCE_MEM,
};
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IB: fix use-after-free in user verbs cleanup
tree 01c6de89a3d60c35d2133c0b6b1903509a8f1df8
parent 1c9cf6f9861f8d27303ee2531b3b7686269c71ce
author Roland Dreier [EMAIL PROTECTED] Sat, 27 Aug 2005 08:34:14 -0700
committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 09:37:12 -0700
[PATCH] IB: fix use-after-free in user verbs cleanup
Fix a use-after-free bug in userspace verbs cleanup: we can't touch
mr-device after we free mr by calling ib_dereg_mr().
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
drivers/infiniband/core/uverbs_main.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/uverbs_main.c
b/drivers/infiniband/core/uverbs_main.c
--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -130,13 +130,14 @@ static int ib_dealloc_ucontext(struct ib
list_for_each_entry_safe(uobj, tmp, context-mr_list, list) {
struct ib_mr *mr = idr_find(ib_uverbs_mr_idr, uobj-id);
+ struct ib_device *mrdev = mr-device;
struct ib_umem_object *memobj;
idr_remove(ib_uverbs_mr_idr, uobj-id);
ib_dereg_mr(mr);
memobj = container_of(uobj, struct ib_umem_object, uobject);
- ib_umem_release_on_close(mr-device, memobj-umem);
+ ib_umem_release_on_close(mrdev, memobj-umem);
list_del(uobj-list);
kfree(memobj);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] md: create a MODULE_ALIAS for md corresponding to its block major number.
tree 23660dd9234016c927b8c135c9e48b685cb16207 parent e1bcfcaa0b3bec2a67b22c565a0bf508ea90db1d author NeilBrown [EMAIL PROTECTED] Sat, 27 Aug 2005 08:34:15 -0700 committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 09:37:12 -0700 [PATCH] md: create a MODULE_ALIAS for md corresponding to its block major number. I just discovered this is needed for module auto-loading. Signed-off-by: Neil Brown [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/md/md.c |1 + 1 files changed, 1 insertion(+) diff --git a/drivers/md/md.c b/drivers/md/md.c --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -4011,3 +4011,4 @@ EXPORT_SYMBOL(md_print_devices); EXPORT_SYMBOL(md_check_recovery); MODULE_LICENSE(GPL); MODULE_ALIAS(md); +MODULE_ALIAS_BLOCKDEV_MAJOR(MD_MAJOR); - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] md: clear the 'recovery' flags when starting an md array.
tree 35b09cbecef683302adaddb9e8f7047462e7a848 parent 72008652dae7d10fa668d7b2ada3bddff7403d86 author NeilBrown [EMAIL PROTECTED] Sat, 27 Aug 2005 08:34:16 -0700 committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 09:37:13 -0700 [PATCH] md: clear the 'recovery' flags when starting an md array. It's possible for this to still have flags in it and a previous instance has been stopped, and that confused the new array using the same mddev. Signed-off-by: Neil Brown [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] drivers/md/md.c |1 + 1 files changed, 1 insertion(+) diff --git a/drivers/md/md.c b/drivers/md/md.c --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -1689,6 +1689,7 @@ static int do_md_run(mddev_t * mddev) mddev-pers = pers[pnum]; spin_unlock(pers_lock); + mddev-recovery = 0; mddev-resync_max_sectors = mddev-size 1; /* may be over-ridden by personality */ /* before we start the array running, initialise the bitmap */ - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Document idr_get_new_above() semantics, update inotify
tree 5e1ae11c320ea00488b33224cc982d0be2d986d6
parent 755528c860b05fcecda1c88a2bdaffcb50760a7f
author John McCutchan [EMAIL PROTECTED] Fri, 26 Aug 2005 22:02:04 -0400
committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 01:32:57 -0700
[PATCH] Document idr_get_new_above() semantics, update inotify
There is an off by one problem with idr_get_new_above.
The comment and function name suggest that it will return an id
starting_id, but it actually returned an id = starting_id, and kernel
callers other than inotify treated it as such.
The patch below fixes the comment, and fixes inotifys usage. The
function name still doesn't match the behaviour, but it never did.
Signed-off-by: John McCutchan [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
fs/inotify.c |2 +-
lib/idr.c|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/inotify.c b/fs/inotify.c
--- a/fs/inotify.c
+++ b/fs/inotify.c
@@ -353,7 +353,7 @@ static int inotify_dev_get_wd(struct ino
do {
if (unlikely(!idr_pre_get(dev-idr, GFP_KERNEL)))
return -ENOSPC;
- ret = idr_get_new_above(dev-idr, watch, dev-last_wd,
watch-wd);
+ ret = idr_get_new_above(dev-idr, watch, dev-last_wd+1,
watch-wd);
} while (ret == -EAGAIN);
return ret;
diff --git a/lib/idr.c b/lib/idr.c
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -207,7 +207,7 @@ build_up:
}
/**
- * idr_get_new_above - allocate new idr entry above a start id
+ * idr_get_new_above - allocate new idr entry above or equal to a start id
* @idp: idr handle
* @ptr: pointer you want associated with the ide
* @start_id: id to start search at
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixup symlink function pointers for hppfs [for 2.6.13]
tree 80a3d59724cc0faf0a5cb07f7e426c9f41d87e67
parent 7c657f2f25d50c602df9291bc6242b98fc090759
author Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED] Fri, 26 Aug 2005
16:57:44 +0200
committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 01:39:19 -0700
[PATCH] Fixup symlink function pointers for hppfs [for 2.6.13]
Update hppfs for the symlink functions prototype change.
Yes, I know the code I leave there is still _bogus_, see next patch for
this.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
fs/hppfs/hppfs_kern.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/hppfs/hppfs_kern.c b/fs/hppfs/hppfs_kern.c
--- a/fs/hppfs/hppfs_kern.c
+++ b/fs/hppfs/hppfs_kern.c
@@ -679,25 +679,25 @@ static int hppfs_readlink(struct dentry
return(n);
}
-static int hppfs_follow_link(struct dentry *dentry, struct nameidata *nd)
+static void* hppfs_follow_link(struct dentry *dentry, struct nameidata *nd)
{
struct file *proc_file;
struct dentry *proc_dentry;
- int (*follow_link)(struct dentry *, struct nameidata *);
- int err, n;
+ void * (*follow_link)(struct dentry *, struct nameidata *);
+ void *ret;
proc_dentry = HPPFS_I(dentry-d_inode)-proc_dentry;
proc_file = dentry_open(dget(proc_dentry), NULL, O_RDONLY);
- err = PTR_ERR(proc_dentry);
- if(IS_ERR(proc_dentry))
- return(err);
+
+ if (IS_ERR(proc_dentry))
+ return proc_dentry;
follow_link = proc_dentry-d_inode-i_op-follow_link;
- n = (*follow_link)(proc_dentry, nd);
+ ret = (*follow_link)(proc_dentry, nd);
fput(proc_file);
- return(n);
+ return ret;
}
static struct inode_operations hppfs_dir_iops = {
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hppfs: fix symlink error path
tree 5c281ab99184fa6dcfb09586064ea7751c32fd4c
parent d7a60d50d7713b65a3fd88f11d5717b83a6b6a97
author Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED] Fri, 26 Aug 2005
16:57:53 +0200
committer Linus Torvalds [EMAIL PROTECTED] Sat, 27 Aug 2005 01:39:19 -0700
[PATCH] hppfs: fix symlink error path
While touching this code I noticed the error handling is bogus, so I
fixed it up.
I've removed the IS_ERR(proc_dentry) check, which will never trigger and
is clearly a typo: we must check proc_file instead.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
fs/hppfs/hppfs_kern.c | 24 +---
1 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/fs/hppfs/hppfs_kern.c b/fs/hppfs/hppfs_kern.c
--- a/fs/hppfs/hppfs_kern.c
+++ b/fs/hppfs/hppfs_kern.c
@@ -38,7 +38,7 @@ struct hppfs_inode_info {
static inline struct hppfs_inode_info *HPPFS_I(struct inode *inode)
{
- return(list_entry(inode, struct hppfs_inode_info, vfs_inode));
+ return container_of(inode, struct hppfs_inode_info, vfs_inode);
}
#define HPPFS_SUPER_MAGIC 0xb0ee
@@ -662,38 +662,32 @@ static int hppfs_readlink(struct dentry
{
struct file *proc_file;
struct dentry *proc_dentry;
- int (*readlink)(struct dentry *, char *, int);
- int err, n;
+ int ret;
proc_dentry = HPPFS_I(dentry-d_inode)-proc_dentry;
proc_file = dentry_open(dget(proc_dentry), NULL, O_RDONLY);
- err = PTR_ERR(proc_dentry);
- if(IS_ERR(proc_dentry))
- return(err);
+ if (IS_ERR(proc_file))
+ return PTR_ERR(proc_file);
- readlink = proc_dentry-d_inode-i_op-readlink;
- n = (*readlink)(proc_dentry, buffer, buflen);
+ ret = proc_dentry-d_inode-i_op-readlink(proc_dentry, buffer, buflen);
fput(proc_file);
- return(n);
+ return ret;
}
static void* hppfs_follow_link(struct dentry *dentry, struct nameidata *nd)
{
struct file *proc_file;
struct dentry *proc_dentry;
- void * (*follow_link)(struct dentry *, struct nameidata *);
void *ret;
proc_dentry = HPPFS_I(dentry-d_inode)-proc_dentry;
proc_file = dentry_open(dget(proc_dentry), NULL, O_RDONLY);
+ if (IS_ERR(proc_file))
+ return proc_file;
- if (IS_ERR(proc_dentry))
- return proc_dentry;
-
- follow_link = proc_dentry-d_inode-i_op-follow_link;
- ret = (*follow_link)(proc_dentry, nd);
+ ret = proc_dentry-d_inode-i_op-follow_link(proc_dentry, nd);
fput(proc_file);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
