git branch --switch?

Good day.

Is it possible to switch the current branch without checking it out? Not really essential, but I'm happily flaundering around with git and still start from scratch fairly regularly; to speed this up I've found the -n switch to git clone useful and would like something similar when reconstructing my "branch hierarchies".

Upto now I only know about "git checkout" (with or without -b) to switch the current branch. As said it's not really essential, but I was expecting there would be something like a "branch --switch". Did I overlook it?

Rene.

On 4/17/07, Rene Herman <rene.herman@gmail.com> wrote:

Kind of. It can be done with git-read-tree. I.e.:

  $ git-read-tree --index-output=.git/tmp-index <branch-name> && \
     mv tmp-index .git/index && \
     git update-ref HEAD <branch-name>

On 04/17/2007 04:21 PM, Alex Riesen wrote:

[ ... ]

Eew. Thank you. Maybe...

Rene.

On Apr 17, 2007, at 10:21 AM, Alex Riesen wrote:

This does not appear to do what you think it will. git update-ref will write the SHA1 of <branch-name> into the current HEAD, not switch HEAD to a new branch.

However, the first two lines will correctly update the index to the new head which is probably a good idea.

~~ Brian

On 4/17/07, Brian Gernhardt <benji@silverinsanity.com> wrote:

ach, right. Dangerous: it can change the ref HEAD points to. Very sorry! Better just:

 $ rm .git/HEAD && git symbolic-ref HEAD "refs/heads/<branch-name>"

In the end, you just have git-checkout minus git-checkout-index. Maybe a "git-checkout -n" can be useful. Even though I can't imagine what for.

On 04/17/2007 05:11 PM, Alex Riesen wrote:

Thanks.

Thought about that as well, to keep with clone, but giving "checkout" an option to not checkout seems somewhat odd.

"git branch -s" for "not only create but Set current to it as well" maybe?

Rene.

On Apr 17, 2007, at 9:36 AM, Rene Herman wrote:

Perusing git-checkout points me to git-symbolic-ref to update the HEAD ref to a new branch:

git symbolic-ref HEAD refs/heads/<branch>

However, I'm somewhat confused as to why you'd want HEAD and the working directory to get out of sync. It would cause any further commits to have broken history information. If you want to make the content of one branch ($branchA) the same as the other ($branchB), you should do something like:

git checkout -b temp $branchB # Get content from branchB git merge -s ours $branchA # Merge history (not content) from branchA git branch -M $branchA # Make this new merge branchA

This would be significantly simpler if there was a "theirs" merge strategy "git checkout $branchA; git merge -s theirs $branchB", but there isn't. Should be simple to write if you really need it though.

~~ Brian

On 04/17/2007 04:31 PM, Brian Gernhardt wrote:

Thank you for the answer. Well, as said, it's not essential, but I was just now rebuilding a repo and have a few branches that I all want to be based on the same revision. Say, branch a, b and c, based on v2.6.20.

git clone -l -s -n <a local linux repo> local git checkout -b v20 v2.6.20 git branch a git branch b git branch c

Step 1, 3, 4 and 5 of this are nearly instantaneous but 2 isn't -- this repo sits on a P1 with 64M of memory and a disk doing 8 M/s which is probably the only reason I thought asking about it was a good idea in the first place...

You'd be quite right in saying that there isn't much point; if I want to now start populating branch a, I have to "git checkout a" anyway, and that action _will_ now be instantaneous. If I'd replaced 2 with:

git branch --create-and-set-as-current v20 v2.6.20

then I will not have won any time until that 6th "git checkout a" step.

The checkout of v20 was superfluous in this though, and I just expected I should be able to skip that. It fitted my mental model...

Rene.

On 04/17/2007 05:41 PM, Rene Herman wrote:

s/until/after/

Rene.

On 4/17/07, Rene Herman <rene.herman@gmail.com> wrote:

I might have misunderstood your goal, but have you tried

 git clone -l -s -n <a local linux repo> local
 git branch a v2.6.20
 git branch b a
 git branch c a

Now a, b and c all point at v2.6.20, while HEAD points as master.

-- larsh

On 04/17/2007 05:55 PM, Lars Hjemli wrote:

Well, yes, they do, and I could also do

git branch b v2.6.20 git branch c v2.6.20

directly then (right?) but I do want that "v20" branch in the middle. The cloned repo is a linus repo, and that v20 is where I'll be pulling 2.6.20.y updates into; a merge branch will then merge v20, a, b and c into what I will be compiling.

As said, given that I need to checkout things anyway to do something with them it'a all not essential but as a newbie, I just thought that a "branch --and-set-as-current new_branch" made sense. My sense of sense may be crap; I've largely avoided dealing with souce code management, regarding CVS and SVN as unfortunate facts of life to work around and forget, mostly.

Rene.

Rene> Well, yes, they do, and I could also do

Rene> git branch b v2.6.20 Rene> git branch c v2.6.20

Rene> directly then (right?) but I do want that "v20" branch in the middle.

What does "in the middle" mean here?

If I set:

   b = a;
   c = a;

That's the same as if I said:

   b = a;
   c = b;

Why do you think those would be different? There's nothing recorded when you say "git branch X Y" except to make a new X that's a copy of the SHA1 of the old Y.

On 04/17/2007 06:50 PM, Randal L. Schwartz wrote:

In the middle of my mental model if nothing else :-) But never mind, I was confused; ignored Lars' info about branch starting points (and even myself stating it before) but given them, I have all I want.

Rene.

On 4/17/07, Rene Herman <rene.herman@gmail.com> wrote:

Yes

Ok. Then maybe you want to try something like this:

$ git clone -l -s -n ../linux-2.6 rene $ cd rene $ git remote add v20 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.20.y $ git fetch v20

This gives you a tracking branch for 2.6.20.y, named as "v20/master". That branch can then be used as a starting point for your a, b and c branches, like:

$ git checkout -b a v20/master    # this _will_ take some time...

After applying some changes on branch a, you can then merge the latest changes on the v20-branch like this

$ git fetch v20 $ git merge v20/master

If you want the merge to occur on a separate branch, do this first:

$ git checkout -b tmp a

-- larsh

On 04/17/2007 07:00 PM, Lars Hjemli wrote:

Thanks much! This is very useful.

Rene.

On 04/17/2007 05:41 PM, Rene Herman wrote:

Actually, I take that back, it's not instantaneous at all. 1995 systems are much better at showing long delays than those fancy modern computers are!

Rene.

On Tue, 17 Apr 2007, Rene Herman wrote:

You'll always have at least _one_ slow checkout. If you checkout at all.

The kernel archive is 8 million lines - 240MB or so checked out. Writing out that 240 MB to disk is not going to be instantaneous even on a modern machine, although having so much memory that you can ignore the writeout and let it happen in the background will certainly help.

If you don't need to build the tree, you can avoid the checkout entirely, of course. Most git operations don't actually need a checked-out tree at all, and you could even have done a bare clone and just inspected it with git tools if that's what is wanted.

So you could have avoided the checkout completely, and done

	git clone -l -s -n <a local linux repo> local
	git branch v20 v2.6.20
	git branch a v20
	git branch b v20
	git branch c v20

and now you'd have four branches that all point to the v20 thing, and none of them are actually checked out. And all of that would have been instantaneous, even on an old machine (apart fromt he clone itself, of course ;)

But the moment you decide to write 240MB to disk, you'll be slow.

			Linus

On 04/17/2007 06:44 PM, Linus Torvalds wrote:

Yes, this is exactly what I wanted, thank you. I'm only learning about "git branch" (as opposed to git checkout -b) now and it didn't in fact occur to me that I could specify that <start-point> although I should've noticed in the manpage and certainly in Lars' reply from a few minutes back -- managed to go into that and still not have it click.

Nothing left for me to desire...

Rene.