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 [off-list ref] wrote:

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?

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 Apr 17, 2007, at 9:36 AM, Rene Herman wrote:

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?

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:21 PM, Alex Riesen wrote:

On 4/17/07, Rene Herman [off-list ref] wrote:

quoted

Is it possible to switch the current branch without checking it out?

[ ... ]

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>

Eew. Thank you. Maybe...

Rene.

On Apr 17, 2007, at 10:21 AM, Alex Riesen 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>

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 [off-list ref] wrote:

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

quoted

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>

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.

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 04:31 PM, Brian Gernhardt wrote:

quoted

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?

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.

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:11 PM, Alex Riesen 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>"

Thanks.

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.

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 04/17/2007 05:41 PM, Rene Herman wrote:

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

quoted

However, I'm somewhat confused as to why you'd want HEAD and the 
working directory to get out of sync.

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.

s/until/after/

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 4/17/07, Rene Herman [off-list ref] wrote:

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

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:

On 4/17/07, Rene Herman [off-list ref] wrote:

quoted

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

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.

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.

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

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.

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:

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

quoted

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.

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!

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:

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

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.

On 4/17/07, Rene Herman [off-list ref] wrote:

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

quoted

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.

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

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

directly then (right?)

Yes

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.

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:

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

Thanks much! This is very useful.

Rene.