From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Fix for shared flat binary format in 2.6.30
Date: Mon, 22 Jun 2009 21:09:02 UTC
Message-ID: <fa.sBKvroXHHfIXlB9tBeDW/gk+jI4@ifi.uio.no>

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 user.name "John Stoffel"
> > git config --global user.email "john@stoffel.org"

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
overhead).

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
hurt.

> # Only to be done infrequently
> > mkdir /var/tmp/git-tree
> > cd /var/tmp/git-tree
> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.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
things:

 - 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.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Fix for shared flat binary format in 2.6.30
Date: Tue, 23 Jun 2009 02:47:41 UTC
Message-ID: <fa.PpQ5UxvXXUeTat3auS5SzpQVE1g@ifi.uio.no>

On Mon, 22 Jun 2009, John Stoffel wrote:
>
> Linus> Then, just edit the files, and use "git diff". That, along with
> Linus> "git pull" would be the _only_ command you'd ever use - and you
> Linus> now have a nice anoncvs-like environment to get used to git
> Linus> with, without having to actually know a whole lot.
>
> So say I want to manage multiple branches, since I want to test some
> patches out, or various kernel revisions, or even git bisection?
>
> Or should I just use a completely seperate tree for a bisection run?

Oh, it really does sound like you want to do the whole "multiple branches"
thing, and want to do way more with git than just use it as an anoncvs
replacement.

So your workflow is fine.

My clarification was really meant for the case where people were perhaps
more used to the CVS kind of model (and SVN is very much the same one).
I bet there's lots of people who are used to anoncvs and carrying their
patches (uncommitted) in their trees, and then doing "cvs update".

So I tried to just outline the git version of that.

It's a much weaker model, and not at all as capable, but it _is_ simpler.

> Linus> 	git stash		# save your changes
> Linus> 	git pull		# do the update
> Linus> 	git stash apply		# re-apply your changes
>
> Ohh!  This is a new one to me.  Gotta remember this one, that's huge!
> Maybe what I've written should be updated to use this method instead?

Your multiple branch approach is much better since you do commits etc. A
commit is a long-term stash, and you can (obviously) queue them on top of
each other.

With "git stash", you can have multiple different stashed things too, but
they don't queue up on each other - they are just random independent
patches that you've stashed away because they were inconvenient at some
point.

So the real "branches + commits" model is what a real git user does, and
your description wasn't bad at all. It was just perhaps more of a stretch
than some people who are used to CVS would necessarily want to begin with.

> Heh, from all I've seen with your rants, git pull --rebase isn't what
> I want to do if I can help it.  :]  Even though I'll probably never
> publish a branch, just small patches occasionally at times.

There's nothing wrong with "git pull --rebase" if you're a "leaf
developer", ie you don't publish your git tree, and you don't integrate
work from other peoples git trees.

Doing "git pull --rebase" (or "git fetch" + "git rebase origin", which is
the same thing) is very convenient for people who do commit their changes
with git, and aren't ready to publish them.

I actually do it all the time myself - in my own private git source tree.
I send git patches to Junio by email, and I don't publish my own git tree
any more, since Junio is the real maintainer, and has been doing such a
stellar job.

So when it comes to git, I occasionally have some git work going on
myself, and I tend to maintain those as commits in my private tree that I
then update with "git pull --rebase". It's an excellent _private_
workflow, because it means that I can trivially keep my own work
up-to-date, and if part of it is something that I sent to Junio for
merging, if/when he merges it, when I do "git pull --rebase" my own
private commit automatically goes away since it's no longer needed, and
got merged.

So it's true that I rant against people doing rebase, but I rant against
maintainers who either rebase other peoples commits (it's happily getting
fairly rare), or who keep a private tree that they rebase all the time,
and then they publish what is obviously _totally_ untested crap, because I
can tell that they rebased within the last few hours, and thus the weeks
or months of work that they then publish has been essentially made public
with zero testing.

So rebase has huge downsides, but for private git patch queues it's
wonderful. There's a reason 'git rebase' is very much part of the core git
distribution, it's not some kind of second-class citizen.

			Linus