Re: cogito/git usage question

From: Linus Torvalds <torvalds@osdl.org>
Date: Aug 29, 2005, 15:19 UTC
Message-ID: <Pine.LNX.4.58.0508290804570.3243@g5.osdl.org>
In-Reply-To: <4312E74D.5020203@eircom.net>

On Mon, 29 Aug 2005, Bryan O'Donoghue wrote:

Show 5 quoted lines

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