cogito/git usage question

cogito/git usage question

[Bryan O'Donoghue]

Greetings all.

I have a copy of
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
which is currently at revision 2.6.13 as at this morning.

cg-tag-ls lists every version from 2.6.11 to the current 2.6.13
inclusive. cg-tag-ls also lists kernel version 2.6.13-rc6. What I'm
wondering is how exactly I set copy of the tree to that version, so that
I can apply the -mm patchset ?

I've asked uncle Google and searched the git mailing list archives, as
well as looking through the git and cogito documentation, however, it is
not immediately obvious to me at this point what the correct command to
do this is. I'd be very grateful, if somebody could point that out.

Best Regards,
Bryan

-- 
"Fiery the angels fell. Deep thunder rolled around their shores, burning
with the fires of Orc." -- Roy Batty, Blade Runner.

Re: cogito/git usage question

[Linus Torvalds]

On Mon, 29 Aug 2005, Bryan O'Donoghue wrote:
> 
> cg-tag-ls lists every version from 2.6.11 to the current 2.6.13
> inclusive. cg-tag-ls also lists kernel version 2.6.13-rc6. What I'm
> wondering is how exactly I set copy of the tree to that version, so that
> I can apply the -mm patchset ?

You need to start a new branch at the right point in time, and check it
out. Let's call it "bryan-mm", and then it looks something like this:

	git checkout -b bryan-mm v2.6.13-rc6

(mental footnote: pronounce it as "git checkout new branch 'bryan-mm' at
v2.6.13-rc3").

[ You can also do the exact same thing by

	git branch bryan-mm v2.6.13-rc6
	git checkout bryan-mm

  and it's entirely a matter of taste whether you usually want to create 
  the branches first, and switch to them later, or create-and-switch in 
  one go ]

So then you can apply any -mm patches to that tree.

If you want to merge the result (ie you want to have _both_ the -mm 
patches _and_ the changes from the final 2.6.13 release), you might want 
to create yet another branch so that you can easily switch between the 
different states, and then do a "resolve":

	git checkout -b bryan-mm-merged
	git resolve HEAD v2.6.13 "Merge 2.6.13-rc7-mm1 and final 2.6.13"

which will hopefully have no conflicts, and commit the end result. If it 
did have conflicts, you'll have to fix it up by hand (all the normal 
markers from CVS: "<<<<" one side "=====" other side ">>>>>"), and then 
commit it by hand with "git commit --all".

[ Notice how in this second "git checkout -b" we only gave the new branch 
  name, not where to start. That's because we just wanted to start from 
  the same point where we already were in in the original bryan-mm branch ]

Finally, use "gitk --all" to get a better mental visualization for what
the hell you just did. I keep repeating that command, because just
doing the commands may not give you the same understanding of what 
actually happened, but "gitk --all" is really good for visualizing what's 
up (less so when the branches aren't close to each other, but still..)

And then you can switch between the different branches with just a simple

	git checkout <branch>

and off you go.

			Linus

Re: cogito/git usage question

[Bryan O'Donoghue]

Linus Torvalds wrote:

<snip>

> 	git checkout -b bryan-mm v2.6.13-rc6
> 
> (mental footnote: pronounce it as "git checkout new branch 'bryan-mm' at
> v2.6.13-rc3").
> 
> [ You can also do the exact same thing by
> 
> 	git branch bryan-mm v2.6.13-rc6
> 	git checkout bryan-mm

<snip>

> And then you can switch between the different branches with just a simple
> 
> 	git checkout <branch>

Having re-read your email, six times or so, I believe those two
incantations finally make sense.

If I'm understanding, I update to a given git repository, branch locally
based on tags and then I can checkout a branch locally, to make that the
active branch.

Thank you for the input !


Best,
Bryan

-- 
"Fiery the angels fell. Deep thunder rolled around their shores, burning
with the fires of Orc." -- Roy Batty, Blade Runner.

Re: cogito/git usage question

[Linus Torvalds]

On Mon, 29 Aug 2005, Bryan O'Donoghue wrote:
> 
> If I'm understanding, I update to a given git repository, branch locally
> based on tags and then I can checkout a branch locally, to make that the
> active branch.

Exactly. This is the difference between a tag and a branch: a tag is an
"immobile" point in time, while branches are "heads of active development"
(there's a bit more detail to this: you _can_ change a tag, so it's not
like it's totally fixed in stone, but the point is that it's not a dynamic
entity - it's some fairly static thing that you've protected).

So you can't start new development off a tag directly: you need to create
a new branch that just starts off at the point that the tag points to.  
So if you really think of a branch as that "head of active development"
and tags as "static points in time" this all makes tons of sense.

Btw, you don't need to branch based on tags: you can branch based of _any_ 
kind of local reference. A tag is just a common one. But you can branch 
based on your current state too, ie a command line like

	git branch -b fixup HEAD^

means that you will create a "fixup" branch that starts not at a tag, but 
at the "parent of HEAD". In particular, let's say that you just committed 
something, and realized that you need to work on something else without 
the new thing disturbing you (you have a patch that applies in the same 
area, or whatever), something like the above works fine.

Or just use "gitk" to visually find a place, and when you decide to start 
a new branch somewhere, select that commit in gitk, and use the 
cut-and-paste facility to just paste the SHA1 directly into

	git branch -b working <any-random-point-sha1>

so it's not like the tags are important per se, they're just short-hand 
symbolc way-markers.

			Linus