Re: Fix for shared flat binary format in 2.6.30

From: Linus Torvalds
Date: Mon Jun 22 2009 - 17:08:58 EST

On Mon, 22 Jun 2009, John Stoffel wrote:
> I just recently submitted a patch, and it took me a while to figure
> out a git flow for stupid, simple patches so that I, a moron, could
> understand it.

Well, your documented flow is pretty advanced, actually. In fact, much
more advanced than what _I_ often do when I send out patches.

So I'm not saying that your flow is wrong at all, but for "casual"
patches, there are simplifications..

> # One time commands
> > apt-get install git-email
> > git config --global "John Stoffel"
> > git config --global "john@xxxxxxxxxxx"

git-email can be useful, but it's really only useful if you plan on
sending lots of patches. A lot of casual users may fin it too much

The user name/email is always good to set up with git, though.

Of course, the really casual use won't ever even care, because it won't
necessarily even commit things! But setting it up (once) certainly won't

> # Only to be done infrequently
> > mkdir /var/tmp/git-tree
> > cd /var/tmp/git-tree
> > git clone git:// linux-2.6

Yes. Something like this, although "/var/tmp" is an odd place to put it
unless it's really a one-off thing.

> # Make a new branch <branch> for the patch you're doing. In this
> case, we'll do 'sym_hipd-ratelimit'

Ok, this is where your casual use gets to be already pretty advanced.

I would suggest starting out using the kernel git repository as more of a
"anonymous cvs" replacement, ie to just track upstream. So just keep doing

git pull origin

every once in a while, which is a really convenient way to just say "get
the latest version and update the working tree"

NOTE! It's really convenient _only_ if you don't actually do commits. If
you do your own work, it's going to do a merge etc, and that's part of the
"advanced" feature. The above is all assuming that you do NOT commit, and
you really consider it a read-only tree with perhaps some random small
local changes on top for testing.

If you are going to do anything fancier, then your "create a branch for
testing" is good. But for somebody who doesn't expect to really be a
kernel developer, starting out with a usage model based on anoncvs is
probably a more natural one.

Then, just edit the files, and use "git diff". That, along with "git pull"
would be the _only_ command you'd ever use - and you now have a nice
anoncvs-like environment to get used to git with, without having to
actually know a whole lot.

Now, what happens if your modifications touch a file that "git pull" will
update? In that case, "git pull" will will just refuse to update the file,
and do nothing. You can decide at that point to do one of several

- maybe you just want to just stay at that base (not pull updates for a
while, until you're all done with your changes)

- decide to continue with the "anoncvs" workflow, but try to just
forward-port the patches: learn the "git stash" command, and do

git stash # save your changes
git pull # do the update
git stash apply # re-apply your changes

which obviously can be complicated if you have real conflicts, but no
worse than the alternatives. If you change code that changed upstream,
you'll have to resolve the thing _somehow_, and the above won't be that
different from what you're used to with "cvs update" or whatever.

- decide that you are actually going to learn to use git branches etc,
and stop using git as just a smarter 'anoncvs' thing. This is when you
want to learn about commit, branches, and perhaps "git pull --rebase"
and friends.

In other words, you really don't have to jump in with both feet. You could
just dip your toe in the git waters before you do anything fancier.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at