multiple branches in one respository?

[Sanjoy Mahajan]

Does mercurial encourage (or discourage) working with multiple
branches in one directory, for example as Linus describes in the email
below from the git list?

Or, for multiple branches, is the recommended mercurial practice to
keep only one branch in each directory?

-Sanjoy

Date:    Mon, 29 Aug 2005 08:19:16 PDT
From:    Linus Torvalds <torvalds at osdl.org>
To:      "Bryan O'Donoghue" <typedef at eircom.net>
cc:      git at vger.kernel.org
Subject: Re: cogito/git usage question


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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html