How to switch kernel customizations from 2.6.15.6 to 2.6.16?

How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Matt McCutchen]

Dear git people,

I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
2.6.15 kernel repository (which was then at version 2.6.15.6) and making
several commits.  Now I would like a Linux kernel based on 2.6.16 with
the same customizations.  This seems to be a very simple task, but I
have been trying various combinations of git commands for several days
and have not figured out how to do it.

I believe that means I should pull the 2.6.16 kernel into the "origin"
branch and then rebase the "master" branch, merging my customizations
with 2.6.16.  To this end, I switched my remote file to point to the
2.6.16 stable repository and tried to pull.  The result was not what I
wanted.  The situation is complicated by the fact that 2.6.15.6 is not
an ancestor of 2.6.16.  The warning in the man page about branches that
are modified nonlinearly seems to apply.

How do I make my customized 2.6.16 kernel?

-- 
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Linus Torvalds]

On Tue, 28 Mar 2006, Matt McCutchen wrote:
> 
> I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
> 2.6.15 kernel repository (which was then at version 2.6.15.6) and making
> several commits.  Now I would like a Linux kernel based on 2.6.16 with
> the same customizations.  This seems to be a very simple task, but I
> have been trying various combinations of git commands for several days
> and have not figured out how to do it.
> 
> I believe that means I should pull the 2.6.16 kernel into the "origin"
> branch and then rebase the "master" branch, 

Don't "Pull". "Fetch".

"Pull" implies a merge, which is not what you want.

>		 To this end, I switched my remote file to point to the
> 2.6.16 stable repository and tried to pull.  The result was not what I
> wanted.  The situation is complicated by the fact that 2.6.15.6 is not
> an ancestor of 2.6.16.  The warning in the man page about branches that
> are modified nonlinearly seems to apply.

Just realize that you can have any number of branches, and instead of 
forcing "origin" to be something that it simply is not, just create a new 
branch called "linus".

Make that point to my tree, and do

	git fetch linus

to update it. It really is that easy.

Exact commands something like this:

 (1) Edit your .git/remotes/linus file so that it has the following 
     contents:

	URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
	Pull: refs/heads/master:refs/heads/linus

 (2) Use that to fetch my tree as the "linus" branch:

	git fetch linus

and now you have at least a nice new branch that contains the "standard" 
kernel. At which point you just need to do

 (3) rebase the work since "origin" onto "linus":

	git rebase --onto linus origin

I really really despise the "git rebase" command line syntax, and I find 
it very non-inuitive, but what this does is take your current branch, 
compare its contents to "origin" (ie where you started from), and then 
just rebase the commits onto the state that is "linus".

[ Junio: syntax comments:

  Personally, I think the rebase syntax sucks, because the _natural_ way 
  to do it is to just describe the set of commits to rebase the same way 
  we describe all _other_ commit sets: as a "begin..end" sequence.

  So I think rebase _should_ work something like this:

	git rebase origin.. [--onto] linus

  ie just giving an arbitrary range. This is even more noticeable for 
  "git-format-patch", where that insane "<his> [<mine>]" syntax is even 
  worse, for no good reason, when again it should really just work like 
  "git diff" where giving a single revision implies a single revision, and 
  giving a range implies a range, and no strange "mine" vs "his" rules ]

Oh well. Syntax rant over.

			Linus

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Shawn Pearce]

Matt McCutchen <hashproduct@verizon.net> wrote:
> Dear git people,
> 
> I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
> 2.6.15 kernel repository (which was then at version 2.6.15.6) and making
> several commits.  Now I would like a Linux kernel based on 2.6.16 with
> the same customizations.  This seems to be a very simple task, but I
> have been trying various combinations of git commands for several days
> and have not figured out how to do it.
> 
> I believe that means I should pull the 2.6.16 kernel into the "origin"
> branch and then rebase the "master" branch, merging my customizations
> with 2.6.16.  To this end, I switched my remote file to point to the
> 2.6.16 stable repository and tried to pull.  The result was not what I
> wanted.  The situation is complicated by the fact that 2.6.15.6 is not
> an ancestor of 2.6.16.  The warning in the man page about branches that
> are modified nonlinearly seems to apply.
> 
> How do I make my customized 2.6.16 kernel?

I think you want to use `git-fetch --force` to download origin but
not immediately merge it yet.  This will bypass the not-an-ancestor
check you are running into.

Then you can perform the rebase yourself with:

	# Export your local changes into a series of patches.
	#
	git-format-patch -k --stdout --full-index v2.6.16.6 >changes.mbox

	# Checkout the new origin (2.6.16) into master.
	#
	git-reset --hard origin

	# Now apply your patches.
	#
	git-am --binary -3 changes.mbox

If you get merge conflicts fix them up and restart with
`git-am --resolved`.


Note this is the logic of `git-rebase` except it doesn't require
you to actually have a common ancestor, while `git-rebase` does.

-- 
Shawn.

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Junio C Hamano]

Matt McCutchen <hashproduct@verizon.net> writes:

> I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
> 2.6.15 kernel repository (which was then at version 2.6.15.6) and making
> several commits.  Now I would like a Linux kernel based on 2.6.16 with
> the same customizations.

Drawing ancestry graph would help visualizing what you want to
achieve.  You have:

       v2.6.15
    ---o
        \ 
         \
          \                 
           o---o---o v2.6.15.6
                    \
                     x---x---x v2.6.15.6-matt

where x---x---x are your own changes, and you want:

       v2.6.15           v2.6.16
    ---o---o---o---...---o---o
        \                     \
         \                     y---y---y 2.6.16-matt
          \                 
           o---o---o v2.6.15.6
                    \
                     x---x---x 2.6.15.6-matt

to happen, where y---y---y are analogous to x---x---x.

Assuming your branches are:

        origin - v2.6.15.6 (from stable team)
        master - your changes (2.6.15.6-matt)

you could:

        $ git fetch git://../torvalds/linux-2.6.git tag v2.6.16
        $ git checkout -b 2.6.16-matt v2.6.16
        $ git format-patch origin master | git am -3

Alternatively, you might want to do a real merge:

       v2.6.15           v2.6.16
    ---o---o---o---...---o---o
        \                     \
         \                     \ 
          \                     m 2.6.16-matt
           o---o---o v2.6.15.6 /
                    \         /
                     x---x---x 2.6.15.6-matt

Presumably the stable team backported safer changes from the
history between v2.6.15-v2.6.16, and the way things are fixed
are probably quite different from the equivalent fixes in the
development track that led to v2.6.16 (because what's being
patched has also changed), so it is very likely you would see
serious conflicts during this merge.  If you do not understand
what the stable team did in order to reimplement certain fixes,
you would have a very difficult time deciding on how to resolve
conflicts with this merge.

At that point it would not be a git question but the kernel
question I am not qualified to answer ;-), but it might be an
interesting exercise.

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Oh well. Syntax rant over.

Yeah, inertia, backward compatibility wart, craziness.

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

>   Personally, I think the rebase syntax sucks, because the _natural_ way 
>   to do it is to just describe the set of commits to rebase the same way 
>   we describe all _other_ commit sets: as a "begin..end" sequence.

I'd agree in general, and I am not happy about them.

But I have an excuse.

rev-parse's A..B notation was invented on June 13th (178cb24).
But format-patch was originally posted on May 30th:

	http://article.gmane.org/gmane.comp.version-control.git/4279

before the convenience of rev-parse was invented ;-).

>   So I think rebase _should_ work something like this:
>
> 	git rebase origin.. [--onto] linus
>
>   ie just giving an arbitrary range.

In addition, both rebase and format-patch does a bit more than
straight his..mine.

    *---x---x---o---o---o---o
     \                      ^mine
      .---.---.---.
                  ^his

We do _not_ want to process all six of his..mine commits when
doing "format-patch his mine" in the above picture, because
upstream might have accepted some of them already, and we filter
them out with git-cherry.  

>   This is even more noticeable for "git-format-patch", where
>   that insane "<his> [<mine>]" syntax is even worse, for no
>   good reason, when again it should really just work like "git
>   diff" where giving a single revision implies a single
>   revision, and giving a range implies a range, and no strange
>   "mine" vs "his" rules ]

Having said that, you have been able to say format-patch A..B
C..D E..F for quite some time (since November 21, 2005).

Rebase is even more strange, especially with --onto.  When you do

    $ rebase --onto his origin mine

in this picture,

    *---x---x---o---o---o---o
     \      ^origin         ^mine
      .---.---.---.
                  ^his

you are discarding two 'x' commits, and lost-found is the only
thing that would help you to recover them.

Unlike format-patch which takes ranges, rebase does not let you
say "rebase --onto base A..B C..D E..F"; what happens might be
too confusing, especially if B, D, F are not coming from the
current branch.  The current branch is rewound to base and then
the chosen sets of patches are applied, which is kind-of scary.
It would feel safer to do:

	$ git checkout -b newbranch base
        $ git format-patch --stdout A..B C..D E..F | git am -3

and after making sure the result is really what you want
resetting the original branch to the current (newbranch) head.

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Linus Torvalds]

On Tue, 28 Mar 2006, Junio C Hamano wrote:
> 
> Having said that, you have been able to say format-patch A..B
> C..D E..F for quite some time (since November 21, 2005).

Yes, and the documentation still talks only about the old insane format..

> Rebase is even more strange, especially with --onto.  When you do
> 
>     $ rebase --onto his origin mine
> 
> in this picture,
> 
>     *---x---x---o---o---o---o
>      \      ^origin         ^mine
>       .---.---.---.
>                   ^his
> 
> you are discarding two 'x' commits, and lost-found is the only
> thing that would help you to recover them.

.. and this is largely because the whole interface is broken.

The breakage shows up as inflexibility and having a hard time explaining 
what the thing does.  It shows up as confusion about the usage, and about 
the meaning of a simple command line.

For example, in the most trivial format, doing a

	git rebase <branchname>

the _logical_ thing (from just reading the command) to believe the above 
does is to think that it rebases the named branch. I pretty much guarantee 
that that is what any native English speaker would think it does, if they 
thought about it.

The fact that it actually does the _reverse_, and rebases not the named 
branch, but the branch you are on right now.

The fact that when things go south, the old branch has gotten lost (unless 
you remember about ORIG_HEAD) is all related to the same thing. It's just 
a very non-intuitive interface.

That was fine when people weren't supposed to use it, and it was doing 
something very very special, but that has clearly changed over time. Now 
people are encouraged to use it, it's pretty well-known, and even new git 
users seem to want to do it.

I think "git rebase" is a lost cause. It's just fundamentally a very very 
badly designed command, because it does everything the wrong way around.

I personally believe that the _sane_ way of doing rebasing is to 
 - get rid of "git rebase" entirely
 - teach "git cherry-pick" to take a _range_ of commits instead.

Lookie here, let's look at your example a bit more (which in turn comes 
from the original question that started this thread):

    *---x---x---o---o---o---o
     \      ^origin         ^mine
      .---.---.---.
                  ^his

We have three branch points, and we want to move the commits on "mine" 
from "origin" onto "his". How would you do this so that it's _not_ 
confusing, and so that you can explain to a newbie user what he is doing, 
_especially_ if things go wrong in the middle?

Right now, the sequence is:

	git checkout mine			# if required
	git rebase --onto his origin

and if things go south during the rebase, it's immediately total chaos, 
and you really _really_ need to understand what you are doing.

The above just doesn't make any sense. It's hard to explain why you would 
do something like that.

In contrast, here's an alternate workflow that is much easier to explain, 
and doesn't involve "rebase" at all:

	git checkout his
	git cherry-pick origin..mine

Notice what this does? Show these two sequences to anybody who has some 
basic familiarity with git terminology, but has perhaps never actually 
used it, and ask them what the two sequences do. I pretty much guarantee 
that the second sequence will make sense and get people to generally pick 
the right answer, while the first sequence will make people maybe _guess_ 
the right answer, but it's not intuitive.

In particular, what do you think happens when a patch in the series 
doesn't apply under the two circumstances? Which workflow has the 
"intuitive" way of recovering, and which does not?

Right. The second one has a very intuitive way to recover. In fact, it's 
so intuitive that the answer may be "ok, I'll skip that one commit 
entirely because I don't know how to resolve it, and instead cherry-pick 
the rest, and ask the original author to cherry-pick it for me later". And 
doing so is as easy as

	git reset --hard	# undo the mess from the failed one,
				# the same way we always do for all
				# other failed things

	git cherry-pick next..mine	# do the rest

See? That's a very logical thing to do. It's different from "git rebase", 
but it's different in a _good_ way.

In contrast, the "rebase" conflict resolution is pretty damn esoteric, and 
using a simple "gitk --all" when things go wrong won't help you pick 
things up at all.

Now, "git cherry-pick" doesn't actually support the above format, and I'm 
not saying that the "git rebase" name itself is evil. I think we could fix 
"git rebase" to work better, but the semantics - the way they are 
_designed_ right now - are just horrible.

			Linus

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Linus Torvalds]

On Wed, 29 Mar 2006, Linus Torvalds wrote:
> 
> Right now, the sequence is:
> 
> 	git checkout mine			# if required
> 	git rebase --onto his origin

vs

> 	git checkout his
> 	git cherry-pick origin..mine

Btw, I realize that the advantage of "git rebase" is that it doesn't 
change somebody elses branch. However, we'd still be a lot better off with 
us simply doing the equivalent of something like

    git checkout -b new-mine his && 
	git cherry-pick origin..mine &&
	git rename-branch -f new-mine mine

instead of what git-rebase does now.

			Linus

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> In contrast, here's an alternate workflow that is much easier to explain, 
> and doesn't involve "rebase" at all:
>
> 	git checkout his
> 	git cherry-pick origin..mine

Yes, I think it would be good to deprecate/discard the current
rebase and make cherry-pick the recommended workflow.

Optionally.  I've been thinking about not using git-cherry while
cherrypicking, because falling back to three-way merge seems to
work equally well in dealing with "patch already applied" case.

Anyway, teaching the range notation to cherry-pick would be
something like this, I suppose.

---
diff --git a/git-cherry-pick.sh b/git-cherry-pick.sh
new file mode 100755
index 0000000..72a3828
--- /dev/null
+++ b/git-cherry-pick.sh
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+. git-sh-setup
+
+git-format-patch --stdout --full-index -k "$@" |
+git-am --binary -3 -k
diff --git a/Makefile b/Makefile
index d945546..e130d8c 100644
--- a/Makefile
+++ b/Makefile
@@ -114,7 +114,7 @@ ### --- END CONFIGURATION SECTION ---
 
 SCRIPT_SH = \
 	git-add.sh git-bisect.sh git-branch.sh git-checkout.sh \
-	git-cherry.sh git-clone.sh git-commit.sh \
+	git-cherry.sh git-cherry-pick.sh git-clone.sh git-commit.sh \
 	git-count-objects.sh git-diff.sh git-fetch.sh \
 	git-format-patch.sh git-log.sh git-ls-remote.sh \
 	git-merge-one-file.sh git-parse-remote.sh \
@@ -139,7 +139,7 @@ SCRIPT_PYTHON = \
 SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
 	  $(patsubst %.perl,%,$(SCRIPT_PERL)) \
 	  $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
-	  git-cherry-pick git-show git-status
+	  git-show git-status
 
 # The ones that do not have to link with lcrypto nor lz.
 SIMPLE_PROGRAMS = \
@@ -484,9 +484,6 @@ common-cmds.h: Documentation/git-*.txt
 	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
 	    $@.py >$@
 	chmod +x $@
-
-git-cherry-pick: git-revert
-	cp $< $@
 
 git-show: git-whatchanged
 	cp $< $@

Re: Rebase semantic and cherry-pick

[Jakub Narebski]

Linus Torvalds wrote:

> In contrast, here's an alternate workflow that is much easier to explain,
> and doesn't involve "rebase" at all:
> 
> git checkout his
> git cherry-pick origin..mine
[...] 
> Now, "git cherry-pick" doesn't actually support the above format, and I'm
> not saying that the "git rebase" name itself is evil. I think we could fix
> "git rebase" to work better, but the semantics - the way they are
> _designed_ right now - are just horrible.

Perhaps if possible also have

git cherry-pick --whole-branch branchname

meaning

git cherry-pick branchname:begining..branchname:HEAD

-- 
Jakub Narebski

Re: Rebase semantic and cherry-pick

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Perhaps if possible also have
>
> git cherry-pick --whole-branch branchname
>
> meaning
>
> git cherry-pick branchname:begining..branchname:HEAD

There is no branchname:beginning in git.

Re: Rebase semantic and cherry-pick

[Linus Torvalds]

On Wed, 29 Mar 2006, Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > Perhaps if possible also have
> >
> > git cherry-pick --whole-branch branchname
> >
> > meaning
> >
> > git cherry-pick branchname:begining..branchname:HEAD
> 
> There is no branchname:beginning in git.

Well, in this case you don't need it. You just do

	git cherry-pick HEAD..branch

and it just magically does the right thing.

For consistency reasons, we should probably allow that to be written as 
just "..branch", the same way we can write "branch.." to mean "everything 
in HEAD but not in "branch".

		Linus

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Matt McCutchen]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

On Tue, 2006-03-28 at 18:26 -0800, Junio C Hamano wrote:
>        v2.6.15           v2.6.16
>     ---o---o---o---...---o---o
>         \                     \
>          \                     y---y---y 2.6.16-matt
>           \                 
>            o---o---o v2.6.15.6
>                     \
>                      x---x---x 2.6.15.6-matt
> 
> to happen, where y---y---y are analogous to x---x---x.
> 
> Assuming your branches are:
> 
>         origin - v2.6.15.6 (from stable team)
>         master - your changes (2.6.15.6-matt)

Beautiful diagram.  This is exactly my situation.

> you could:
> 
>         $ git fetch git://../torvalds/linux-2.6.git tag v2.6.16
>         $ git checkout -b 2.6.16-matt v2.6.16
>         $ git format-patch origin master | git am -3

This looks like what I want.  When I run the third command, however, I
get "no patch found".  Four files corresponding to my four commits
appear in my repository; I have attached them.  What is wrong?

> Alternatively, you might want to do a real merge:
> [...] If you do not understand
> what the stable team did in order to reimplement certain fixes,
> you would have a very difficult time deciding on how to resolve
> conflicts with this merge.

Yes, I think this is the problem what I ran into before when I was
trying to pull.

Perhaps this is just politics, but which kernel repository is more
official, and why?  Linus's or the one I have been using,
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
?

Thanks for the help!
-- 
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/

[-- Attachment #2: 0001-Changes-for-Matt-s-custom-kernel-the-Stickier-Patch-and-appropriate-markers.txt --]
[-- Type: text/plain, Size: 11630 bytes --]

>From nobody Mon Sep 17 00:00:00 2001
From: Matt McCutchen <matt@mattlaptop.metaesthetics.net>
Date: Sun Mar 5 20:14:20 2006 -0500
Subject: [PATCH] Changes for Matt's custom kernel: the Stickier Patch and appropriate markers.

---

 Documentation/filesystems/stickier.txt |   24 ++++++
 README.matt                            |    1 
 fs/namei.c                             |  132 ++++++++++++++++++++++++++------
 localversion-matt                      |    1 
 4 files changed, 132 insertions(+), 26 deletions(-)
 create mode 100644 Documentation/filesystems/stickier.txt
 create mode 100644 README.matt
 create mode 100644 localversion-matt

6a2fe5757614310ca63e7b2bac1acb5c2081d86c
diff --git a/Documentation/filesystems/stickier.txt b/Documentation/filesystems/stickier.txt
new file mode 100644
index 0000000..03db966
--- /dev/null
+++ b/Documentation/filesystems/stickier.txt
@@ -0,0 +1,24 @@
+Matt McCutchen's Stickier Patch
+-------------------------------
+
+In the official Linux kernel's filesystem support, the only thing the sticky bit does is restrict deletion and overwriting of directory entries: you can't unlink or move another file over a file you don't own in a sticky directory you don't own.
+
+The Stickier Patch makes two changes to the behavior of the sticky bit.  First, creating a link to a file you don't own in a sticky directory you don't own is now forbidden.  (Doing so used to be possible but irreversible, which I considered an incongruity.)
+
+Second, a sticky directory you don't own has restrictions on lookup by name beyond the requirement of execute permission.  You can always look up a file that you own or on which you have at least one permission (read, write, or execute).  If you try to look up another file, you get EPERM.  If you try to look up a nonexistent file, you get ENOENT if you can read or write the directory, but EPERM if you can only execute it.  These restrictions apply to all path following, so every system call that follows paths can potentially cause EPERM.
+
+Why this change?  If you want to allow everyone on your computer to read a folder in your home directory, you can set its permissions to 755; however, to get to the folder, people need execute on your home directory.  But giving them execute opens the door to loads of abuse.  People can guess filenames and see if those files exist in your home directory; if the files exist, people can stat them and learn their atimes, mtimes, and sizes.  Maybe they won't hit upon any of your personal files, but the names of your mailbox and your dotfiles are likely to be well-known.  People can find out when you last got mail and about how big the mail was, what programs you've used recently, and so forth.
+
+With the Stickier Patch, you can set your home directory sticky (mode 1711).  People can still get to the public folder, but trying to access any other name will cause EPERM.  They can't even learn whether the files exist, much less stat them.
+
+Alternatively, you can set your home directory to mode 1755, in which case others can list the names of all files but only see stat information for the public ones:
+	drwxr-xr-t  81 matt matt 4096 Jan 18 16:13 .
+	drwxr-xr-x   3 root root 4096 Jan  8 16:46 ..
+	?---------   ? ?    ?       ?            ? .bashrc
+	lrwxrwxrwx   1 matt matt   18 Jan 18 16:14 symlink -> some/target/path
+	drwxr-xr-x   1 matt matt   18 Jan 18 16:14 public
+	?---------   ? ?    ?       ?            ? private
+
+Note that the symlink appears and is stattable because it grants everyone every permission; there's nothing you can do about this unless/until I make another patch that adds lchmod and meaningful symlink permissions (r == readlink, w == writelink (to be implemented), x == traverse).  In addition, the Stickier Patch does not change the behavior of readdir, which often gives the i-number and type of a file along with its name.  (In fact, a short-form ls listing will classify private directories as directories, not as unstattable, because short-form ls bases classification on readdir.)
+
+Future versions of the Stickier Patch may address these issues and may also provide a way to set a directory so private entries are hidden from readdir (setuid bit?).  In the meantime, if any of these issues is a concern, one should remove read permission and announce the names of files others may access in another venue so they don't have to guess.
diff --git a/README.matt b/README.matt
new file mode 100644
index 0000000..8df642d
--- /dev/null
+++ b/README.matt
@@ -0,0 +1 @@
+This is Matt McCutchen's custom kernel.  Right now, the only difference between it and the official one is the Stickier Patch, described in Documentation/filesystems/sticker.txt , which changes the behavior of the sticky bit on directories.
diff --git a/fs/namei.c b/fs/namei.c
index 6dbbd42..baea761 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -766,6 +766,66 @@ fail:
 }
 
 /*
+ * It's inline, so penalty for filesystems that don't use sticky bit is
+ * minimal.
+ * MATT -- null inode allowed, it's as if nobody owns it
+ */
+static inline int check_sticky(struct inode *dir, struct inode *inode)
+{
+	if (!(dir->i_mode & S_ISVTX))
+		return 0;
+	if (inode && inode->i_uid == current->fsuid)
+		return 0;
+	if (dir->i_uid == current->fsuid)
+		return 0;
+	return !capable(CAP_FOWNER);
+}
+
+/*
+ * MATT -- Will a new entry refuse to adhere to the directory?  :)
+ */
+static inline int check_unsticky(struct inode *dir, uid_t new_owner)
+{
+	if (!(dir->i_mode & S_ISVTX))
+		return 0;
+	if (new_owner == current->fsuid)
+		return 0;
+	if (dir->i_uid == current->fsuid)
+		return 0;
+	return !capable(CAP_FOWNER);
+}
+
+/*
+ * MATT
+ * Check whether we can traverse a directory entry; return 0 or -Exxxx.
+ * 1. We can if the directory entry isn't sticky for us (see check_sticky).
+ * 2. If the entry points nowhere, we can traverse it if we can read or
+ *    write the directory.
+ * 3. If the entry points to a file, we can traverse it if we can read,
+ *    write, or execute the file.
+ * Because of the clumsy interface, we need several permission checks.
+ */
+static inline int may_traverse(struct inode *dir,struct inode *inode)
+{
+	if (!check_sticky(dir, inode))
+		return 0;
+	if (inode) {
+		if (permission(inode, MAY_READ, NULL) == 0
+			|| permission(inode, MAY_WRITE, NULL) == 0
+			|| permission(inode, MAY_EXEC, NULL) == 0)
+			return 0;
+		else
+			return -EPERM;
+	} else {
+		if (permission(dir, MAY_READ, NULL) == 0
+			|| permission(dir, MAY_WRITE, NULL) == 0)
+			return 0;
+		else
+			return -EPERM;
+	}
+}
+
+/*
  * Name resolution.
  * This is the basic name resolution function, turning a pathname into
  * the final dentry. We expect 'base' to be positive and a directory.
@@ -794,6 +854,7 @@ static fastcall int __link_path_walk(con
 		unsigned long hash;
 		struct qstr this;
 		unsigned int c;
+		struct inode *dirsave;
 
 		nd->flags |= LOOKUP_CONTINUE;
 		err = exec_permission_lite(inode, nd);
@@ -801,6 +862,7 @@ static fastcall int __link_path_walk(con
 			err = vfs_permission(nd, MAY_EXEC);
  		if (err)
 			break;
+		dirsave = inode;
 
 		this.name = name;
 		c = *(const unsigned char *)name;
@@ -852,8 +914,16 @@ static fastcall int __link_path_walk(con
 		if (err)
 			break;
 
-		err = -ENOENT;
 		inode = next.dentry->d_inode;
+		/*
+		 * MATT -- May we traverse the entry?
+		 * inode might be null; may_traverse checks this case and
+		 * might cause EPERM to conceal whether the inode exists.
+		 */
+		err = may_traverse(dirsave, inode);
+		if (err)
+			goto out_dput;
+		err = -ENOENT;
 		if (!inode)
 			goto out_dput;
 		err = -ENOTDIR; 
@@ -906,6 +976,14 @@ last_component:
 		if (err)
 			break;
 		inode = next.dentry->d_inode;
+		/*
+		 * MATT -- May we traverse the entry?
+		 * inode might be null; may_traverse checks this case and
+		 * might cause EPERM to conceal whether the inode exists.
+		 */
+		err = may_traverse(dirsave, inode);
+		if (err)
+			break;
 		if ((lookup_flags & LOOKUP_FOLLOW)
 		    && inode && inode->i_op && inode->i_op->follow_link) {
 			err = do_follow_link(&next, nd);
@@ -1260,21 +1338,6 @@ int fastcall __user_walk(const char __us
 }
 
 /*
- * It's inline, so penalty for filesystems that don't use sticky bit is
- * minimal.
- */
-static inline int check_sticky(struct inode *dir, struct inode *inode)
-{
-	if (!(dir->i_mode & S_ISVTX))
-		return 0;
-	if (inode->i_uid == current->fsuid)
-		return 0;
-	if (dir->i_uid == current->fsuid)
-		return 0;
-	return !capable(CAP_FOWNER);
-}
-
-/*
  *	Check whether we can remove a link victim from directory dir, check
  *  whether the type of victim is right.
  *  1. We can't do it if dir is read-only (done in permission())
@@ -1333,12 +1396,27 @@ static inline int may_delete(struct inod
  *  4. We can't do it if dir is immutable (done in permission())
  */
 static inline int may_create(struct inode *dir, struct dentry *child,
-			     struct nameidata *nd)
+			     struct nameidata *nd, uid_t new_owner)
 {
 	if (child->d_inode)
 		return -EEXIST;
 	if (IS_DEADDIR(dir))
 		return -ENOENT;
+	if (check_unsticky(dir, new_owner))
+		return -EPERM;
+	return permission(dir,MAY_WRITE | MAY_EXEC, nd);
+}
+
+/* Same as may_create but allow the child to already exist.
+ * Separately you should check may_delete on an existing child, if any.
+ */
+static inline int may_create_or_overwrite(struct inode *dir, struct dentry *child,
+			     struct nameidata *nd, uid_t new_owner)
+{
+	if (IS_DEADDIR(dir))
+		return -ENOENT;
+	if (check_unsticky(dir, new_owner))
+		return -EPERM;
 	return permission(dir,MAY_WRITE | MAY_EXEC, nd);
 }
 
@@ -1405,7 +1483,7 @@ void unlock_rename(struct dentry *p1, st
 int vfs_create(struct inode *dir, struct dentry *dentry, int mode,
 		struct nameidata *nd)
 {
-	int error = may_create(dir, dentry, nd);
+	int error = may_create(dir, dentry, nd, current->fsuid);
 
 	if (error)
 		return error;
@@ -1721,7 +1799,7 @@ EXPORT_SYMBOL_GPL(lookup_create);
 
 int vfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
 {
-	int error = may_create(dir, dentry, NULL);
+	int error = may_create(dir, dentry, NULL, current->fsuid);
 
 	if (error)
 		return error;
@@ -1794,7 +1872,7 @@ out:
 
 int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
 {
-	int error = may_create(dir, dentry, NULL);
+	int error = may_create(dir, dentry, NULL, current->fsuid);
 
 	if (error)
 		return error;
@@ -2032,7 +2110,7 @@ slashes:
 
 int vfs_symlink(struct inode *dir, struct dentry *dentry, const char *oldname, int mode)
 {
-	int error = may_create(dir, dentry, NULL);
+	int error = may_create(dir, dentry, NULL, current->fsuid);
 
 	if (error)
 		return error;
@@ -2092,7 +2170,7 @@ int vfs_link(struct dentry *old_dentry, 
 	if (!inode)
 		return -ENOENT;
 
-	error = may_create(dir, new_dentry, NULL);
+	error = may_create(dir, new_dentry, NULL, inode->i_uid);
 	if (error)
 		return error;
 
@@ -2285,12 +2363,14 @@ int vfs_rename(struct inode *old_dir, st
 	if (error)
 		return error;
 
-	if (!new_dentry->d_inode)
-		error = may_create(new_dir, new_dentry, NULL);
-	else
-		error = may_delete(new_dir, new_dentry, is_dir);
+	error = may_create_or_overwrite(new_dir, new_dentry, NULL, old_dentry->d_inode->i_uid);
 	if (error)
 		return error;
+	if (new_dentry->d_inode) {
+		error = may_delete(new_dir, new_dentry, is_dir);
+		if (error)
+			return error;
+	}
 
 	if (!old_dir->i_op || !old_dir->i_op->rename)
 		return -EPERM;
diff --git a/localversion-matt b/localversion-matt
new file mode 100644
index 0000000..fd815c7
--- /dev/null
+++ b/localversion-matt
@@ -0,0 +1 @@
+.matt1
-- 
1.2.4


[-- Attachment #3: 0002-Create-and-add-to-.gitignore-files-so-that-source-tree-is-git-clean-after-I.txt --]
[-- Type: text/plain, Size: 1852 bytes --]

>From nobody Mon Sep 17 00:00:00 2001
From: Matt McCutchen <matt@mattlaptop.metaesthetics.net>
Date: Sun Mar 5 20:16:19 2006 -0500
Subject: [PATCH] Create and add to .gitignore files so that source tree is git-clean after I
build the kernel.

---

 arch/i386/kernel/.gitignore     |    3 +++
 drivers/ieee1394/.gitignore     |    1 +
 drivers/scsi/aic7xxx/.gitignore |    4 ++++
 include/asm-i386/.gitignore     |    1 +
 scripts/kconfig/.gitignore      |    1 +
 5 files changed, 10 insertions(+), 0 deletions(-)
 create mode 100644 arch/i386/kernel/.gitignore
 create mode 100644 drivers/ieee1394/.gitignore
 create mode 100644 drivers/scsi/aic7xxx/.gitignore
 create mode 100644 include/asm-i386/.gitignore

a52dcfea1864b643a58ab2e1693487037f64f233
diff --git a/arch/i386/kernel/.gitignore b/arch/i386/kernel/.gitignore
new file mode 100644
index 0000000..e8ef014
--- /dev/null
+++ b/arch/i386/kernel/.gitignore
@@ -0,0 +1,3 @@
+vsyscall-int80.so
+vsyscall-sysenter.so
+vsyscall.lds
diff --git a/drivers/ieee1394/.gitignore b/drivers/ieee1394/.gitignore
new file mode 100644
index 0000000..33da10a
--- /dev/null
+++ b/drivers/ieee1394/.gitignore
@@ -0,0 +1 @@
+oui.c
diff --git a/drivers/scsi/aic7xxx/.gitignore b/drivers/scsi/aic7xxx/.gitignore
new file mode 100644
index 0000000..a1a7fcd
--- /dev/null
+++ b/drivers/scsi/aic7xxx/.gitignore
@@ -0,0 +1,4 @@
+aic79xx_reg.h
+aic79xx_seq.h
+aic7xxx_reg.h
+aic7xxx_seq.h
diff --git a/include/asm-i386/.gitignore b/include/asm-i386/.gitignore
new file mode 100644
index 0000000..62b0ac8
--- /dev/null
+++ b/include/asm-i386/.gitignore
@@ -0,0 +1 @@
+asm-offsets.h
diff --git a/scripts/kconfig/.gitignore b/scripts/kconfig/.gitignore
index 2dac344..8298ca8 100644
--- a/scripts/kconfig/.gitignore
+++ b/scripts/kconfig/.gitignore
@@ -14,3 +14,4 @@ mconf
 qconf
 gconf
 kxgettext
+zconf.hash.c
-- 
1.2.4


[-- Attachment #4: 0003-More-ignore-files-for-build-outputs.txt --]
[-- Type: text/plain, Size: 872 bytes --]

>From nobody Mon Sep 17 00:00:00 2001
From: Matt McCutchen <matt@mattlaptop.metaesthetics.net>
Date: Sun Mar 5 23:12:19 2006 -0500
Subject: [PATCH] More ignore files for build outputs

---

 arch/i386/boot/.gitignore       |    3 +++
 arch/i386/boot/tools/.gitignore |    1 +
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 arch/i386/boot/.gitignore
 create mode 100644 arch/i386/boot/tools/.gitignore

94eb588607845f97f0fceb6e95690142ba8a807a
diff --git a/arch/i386/boot/.gitignore b/arch/i386/boot/.gitignore
new file mode 100644
index 0000000..495f20c
--- /dev/null
+++ b/arch/i386/boot/.gitignore
@@ -0,0 +1,3 @@
+bootsect
+bzImage
+setup
diff --git a/arch/i386/boot/tools/.gitignore b/arch/i386/boot/tools/.gitignore
new file mode 100644
index 0000000..378eac2
--- /dev/null
+++ b/arch/i386/boot/tools/.gitignore
@@ -0,0 +1 @@
+build
-- 
1.2.4


[-- Attachment #5: 0004-Fix-setlocalversion-to-follow-a-ref-when-looking-for-a-GIT-version-suffix.txt --]
[-- Type: text/plain, Size: 858 bytes --]

>From nobody Mon Sep 17 00:00:00 2001
From: Matt McCutchen <matt@mattlaptop.metaesthetics.net>
Date: Sun Mar 5 23:16:01 2006 -0500
Subject: [PATCH] Fix setlocalversion to follow a `ref: ' when looking for a GIT version suffix

---

 scripts/setlocalversion |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

75f8f156ff1f7869b23edf795e9588e25755be5d
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 7c805c8..229bda7 100644
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -35,6 +35,13 @@ sub do_git_checks {
 	my $head = <H>;
 	chomp $head;
 	close(H);
+	# Follow a ref: in the HEAD
+	if ($head =~ s/^ref: //) {
+		open(H,"<.git/" . $head) or return;
+		$head = <H>;
+		chomp $head;
+		close(H);
+	}
 
 	opendir(D,".git/refs/tags") or return;
 	foreach my $tagfile (grep !/^\.{1,2}$/, readdir(D)) {
-- 
1.2.4

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> For example, in the most trivial format, doing a
>
> 	git rebase <branchname>
>
> the _logical_ thing (from just reading the command) to believe the above 
> does is to think that it rebases the named branch. I pretty much guarantee 
> that that is what any native English speaker would think it does, if they 
> thought about it.

Not really.  Most of the commands in git suite operate on the
current branch.

After thinking about it a bit more, I still agree with you that
things are not as easy to explain as they should be, but I do
not think rebase is so broken anymore.

> In contrast, here's an alternate workflow that is much easier to explain, 
> and doesn't involve "rebase" at all:
>
> 	git checkout his
> 	git cherry-pick origin..mine

This is _easy_ to explain, yes.  However, I do not necessarily
agree with what you said here:

> In particular, what do you think happens when a patch in the series 
> doesn't apply under the two circumstances? Which workflow has the 
> "intuitive" way of recovering, and which does not?
>
> Right. The second one has a very intuitive way to recover. In fact, it's 
> so intuitive that the answer may be "ok, I'll skip that one commit 
> entirely because I don't know how to resolve it, and instead cherry-pick 
> the rest, and ask the original author to cherry-pick it for me later". And 
> doing so is as easy as
>
> 	git reset --hard	# undo the mess from the failed one,
> 				# the same way we always do for all
> 				# other failed things
>
> 	git cherry-pick next..mine	# do the rest

It is not so easy to figure out what the next should be.  If we
limit ourselves to the simplest case that origin is an ancestor
of mine, yes, but in general, no.  We are rebasing presumably
because upstream made independent progress so "origin" would not
be an ancestor of mine anymore; and you are talking about the
generic rev-list syntax next..mine === ^next mine.

"reset --hard" to stop cherry picking is easy.  I do not think
continuing is as easy as you made it sound like.

There was a nontrivial amount of thought went into making the
"rebase" restartable.  Actually, that thought was really for
making the "am" restartable, and the hope was once the user
becomes familiar with how to restart "am", restarting "rebase"
is just as easy because you restart them the same way.  You have
it fall back to 3-way merge (and in the case of rebase, it _can_
fall back to 3-way when the patch does not apply, because all
the blob object names recorded in the intermediate patch format
are from your local repository), you resolve and prepare the
index to be committed, and say "git am --resolved".  We _could_
make "git rebase --resolved" a synonym for "git am --resolved",
because "rebase" being tied to "am" only because the former is
implemented in terms of the latter behind the user _is_
unintiutive.

> See? That's a very logical thing to do. It's different from "git rebase", 
> but it's different in a _good_ way.

As I said, yes, the part to punt is easy.  But that is different
from being able to continue smoothly.  And if you want to punt
during "rebase", you could just as easily do "git reset --hard
ORIG_HEAD", just like you would punt a failed merge with "git
reset --hard ORIG_HEAD".

The non-English (and no natural language I presume) syntax
rebase takes is a mistake from understandability point of view.
I fully agree with that.  Let me think aloud how we could
rephrase them better.

(1) git rebase origin

         A---B---C master (HEAD)
        /
    ---o---o---o---o origin

    I started building on tip of his but while I was woking on
    it he made independent progress.  I want to rebuild my
    branch as if I started at the tip of his current branch.

                     A---B---C master (HEAD)
                    /
    ---o---o---o---o origin

(2) git rebase --onto origin A..C

         A---B---C master (HEAD)
        /
    ---o---o---o---o origin

    I started building on tip of his but while I was woking on
    it he made independent progress.  I want to rebuild my
    branch as if I started at the tip of his current branch, but
    come to think of it I do not need A anymore.

                     B---C master (HEAD)
                    /
    ---o---o---o---o origin

    I personally feel _this_ form is the most logical, and form
    (1) for the sake of consistency could be spelled as:

        $ git rebase --onto origin origin..master

    So you could think of (1) a convenient shorthand for this
    spelled-out form.

(3) git rebase --onto origin A..C topic

               B---C topic
              /
         .---A---. master (HEAD)
        /
    ---o---o---o---o origin

    I have a topic that interferes with what he did in his
    latest updates, and I'd like to resolve the conflicts
    early.  Currently I am not on that branch so first let me
    switch to it.

         .---A---. master
        /
    ---o---o---o---o origin
                    \
                     B---C topic (HEAD)

    This form was done only as a shorthand to save typing "git
    checkout topic" at the beginning, just like "git checkout -b
    newbranch" can be used to save typing "git branch newbranch"
    before the checkout, but I agree it may have made things
    more confusing.  We _could_ deprecate this form and require
    the user to always switch branches before starting the
    rebase.

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Junio C Hamano]

Matt McCutchen <hashproduct@verizon.net> writes:

>> you could:
>> 
>>         $ git fetch git://../torvalds/linux-2.6.git tag v2.6.16
>>         $ git checkout -b 2.6.16-matt v2.6.16
>>         $ git format-patch origin master | git am -3
>...
> What is wrong?

Me ;-).

It should have been 

        $ git format-patch --stdout origin master | git am -3

Sorry.

> Perhaps this is just politics, but which kernel repository is more
> official, and why?  Linus's or the one I have been using,
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
> ?

Linus tree is the main development for the 2.6.(X+1), and
2.6.x.y are managed by the stable team.  They serve different
purposes, and both are "official".

Re: Rebase semantic and cherry-pick

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> For consistency reasons, we should probably allow that to be written as 
> just "..branch", the same way we can write "branch.." to mean "everything 
> in HEAD but not in "branch".

Something like this, perhaps.

-- >8 --
revision arguments: ..B means HEAD..B, just like A.. means A..HEAD

For consistency reasons, we should probably allow that to be written as 
just "..branch", the same way we can write "branch.." to mean "everything 
in HEAD but not in "branch".

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/rev-parse.c b/rev-parse.c
index f176c56..e956cd5 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -315,16 +315,17 @@ int main(int argc, char **argv)
 		dotdot = strstr(arg, "..");
 		if (dotdot) {
 			unsigned char end[20];
-			char *n = dotdot+2;
+			char *next = dotdot + 2;
+			char *this = arg;
 			*dotdot = 0;
-			if (!get_sha1(arg, sha1)) {
-				if (!*n)
-					n = "HEAD";
-				if (!get_sha1(n, end)) {
-					show_rev(NORMAL, end, n);
-					show_rev(REVERSED, sha1, arg);
-					continue;
-				}
+			if (!*next)
+				next = "HEAD";
+			if (dotdot == arg)
+				this = "HEAD";
+			if (!get_sha1(this, sha1) && !get_sha1(next, end)) {
+				show_rev(NORMAL, end, next);
+				show_rev(REVERSED, sha1, this);
+				continue;
 			}
 			*dotdot = '.';
 		}
diff --git a/revision.c b/revision.c
index 745b0d2..2cda7e0 100644
--- a/revision.c
+++ b/revision.c
@@ -642,14 +642,19 @@ int setup_revisions(int argc, const char
 		if (dotdot) {
 			unsigned char from_sha1[20];
 			char *next = dotdot + 2;
+			char *this = arg;
+			static const char HEAD[] = "HEAD";
 			*dotdot = 0;
 			if (!*next)
-				next = "HEAD";
-			if (!get_sha1(arg, from_sha1) && !get_sha1(next, sha1)) {
+				next = HEAD;
+			if (dotdot == arg)
+				this = HEAD;
+			if (!get_sha1(this, from_sha1) &&
+			    !get_sha1(next, sha1)) {
 				struct commit *exclude;
 				struct commit *include;
 
-				exclude = get_commit_reference(revs, arg, from_sha1, flags ^ UNINTERESTING);
+				exclude = get_commit_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
 				include = get_commit_reference(revs, next, sha1, flags);
 				if (!exclude || !include)
 					die("Invalid revision range %s..%s", arg, next);

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Matt McCutchen]

On Wed, 2006-03-29 at 19:22 -0800, Junio C Hamano wrote:
> It should have been 
> 
>         $ git format-patch --stdout origin master | git am -3

Thanks!  My kernel is finally merged and is building as I write!  It
turns out that parts of my commits #2-#4 had already been addressed
between 2.6.15.6 and 2.6.16.  I had to merge #2 with what had already
been done, and #3 and #4 became unnecessary.
-- 
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Linus Torvalds]

On Wed, 29 Mar 2006, Matt McCutchen wrote:
> 
> Perhaps this is just politics, but which kernel repository is more
> official, and why?  Linus's or the one I have been using,
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
> ?

The beauty of git should be (and maybe that's not entirely true simply 
because of practical concerns) that there really need not be any notion of 
"more official".

You can fetch multiple different git trees from different sources into the 
same git tree, and then keep them _all_ around equally as different 
branches. You can move fixes between the different branches with "git 
cherry-pick", and you can merge different branches with "git merge"

Now, the reason I say "_should_ be" rather than "is" is two-fold:

 - right now, a lot of the infrastructure is simply set up more towards 
   the "one single source repository" model. When you do a "git clone", it 
   kind of makes the origin special. That's how all the documentation is 
   written, and that's also the only remote branch that git creates 
   _automatically_ for you.

   This really isn't a technical issue: the git code code doesn't care 
   about any special "original" repository. But the fact that you have to 
   create the ".git/remotes/linus" file by hand, and that all the examples 
   in the docs end up talking about a single "origin" branch means that 
   people _think_ of git as a "single origin" thing.

 - the more fundamental one is that when you start mixing branches, you 
   have to be very careful if you expect the upstream projects to pull the 
   changes _back_. In particular, that's where you have to think twice (or 
   three times) about doing a "git merge" (or a "git pull", which 
   implicitly merges for you if it's not a pure fast-forward).

   In particular, the fact that _you_ want to merge two trees that came 
   from different sources does _not_ imply that either of the two sources 
   might want to merge with each other. So if you merge the two together, 
   you may find it impossible to have either of them then pull from you: 
   they way want your changes, but they might not like the merge you did, 
   because they have different policies about that work than you did.

So while the first point is purely a "mental model" issue and about lack 
of helper scripts, the second point is fundamental.

For example, in your case it was almost certainly the right thing to do to 
cherry-pick your changes from the 2.6.15.6 branch onto the development 
branch, because I simply don't want to merge the 2.6.15.6 stuff into the 
standard tree: part of the _rules_ for the stable branch is that the 
things it fixes should have been fixed in the development tree already, so 
merging the stable tree should always be unnecessary (and often clash, 
although _hopefully_ in many cases the fixes in the stable tree are 1:1 
identical and will merge beautifully).

Anyway: from a technical standpoint, no tree should be "special" or "more 
official" for git usage. But when merging data back to any of those trees 
that aren't special, the source/history of the data is important to keep 
in mind. Branch "a" may not be any more special than branch "b", but when 
you push changes back to the source of branch "a", the history of those 
changes (relative to what the source was) is meaningful.

			Linus

Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

[Matt McCutchen]

On Thu, 2006-03-30 at 09:32 -0800, Linus Torvalds wrote:
> The beauty of git should be (and maybe that's not entirely true simply 
> because of practical concerns) that there really need not be any notion of 
> "more official".

I understand this, and it is one of several reasons why I prefer git to
other version control systems.  However, I thought there would be a
single official kernel repository even if git didn't require it.  Junio
explained to me that both yours and the stable one are official for
different purposes.  I think I will use the stable one because it is
current enough for my needs.

>  - the more fundamental one is that when you start mixing branches, you 
>    have to be very careful if you expect the upstream projects to pull the 
>    changes _back_. [...]

True.  It might help several branches coordinate development if a commit
could be marked as "equivalent" to another commit so that, if both were
involved in a merge, one could be thrown out.

-- 
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/