git branch --switch?

git branch --switch?

[Rene Herman]

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.

Re: git branch --switch?

[Alex Riesen]

On 4/17/07, Rene Herman <rene.herman@gmail.com> 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>

Re: git branch --switch?

[Rene Herman]

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

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

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

Re: git branch --switch?

[Brian Gernhardt]

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

Re: git branch --switch?

[Alex Riesen]

On 4/17/07, Brian Gernhardt <benji@silverinsanity.com> wrote:
>
> 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.
>

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.

Re: git branch --switch?

[Rene Herman]

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.

Re: git branch --switch?

[Brian Gernhardt]

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

Re: git branch --switch?

[Rene Herman]

On 04/17/2007 04:31 PM, Brian Gernhardt 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.

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.

Re: git branch --switch?

[Rene Herman]

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

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

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

Re: git branch --switch?

[Lars Hjemli]

On 4/17/07, Rene Herman <rene.herman@gmail.com> 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

Re: git branch --switch?

[Rene Herman]

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

> On 4/17/07, Rene Herman <rene.herman@gmail.com> 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.

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.

Re: git branch --switch?

[Randal L. Schwartz]

>>>>> "Rene" == Rene Herman <rene.herman@gmail.com> writes:

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.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: git branch --switch?

[Rene Herman]

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

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

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.

Re: git branch --switch?

[Lars Hjemli]

On 4/17/07, Rene Herman <rene.herman@gmail.com> wrote:
> On 04/17/2007 05:55 PM, Lars Hjemli 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.
>
> 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

Re: git branch --switch?

[Rene Herman]

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.

Re: git branch --switch?

[Rene Herman]

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.

Re: git branch --switch?

[Linus Torvalds]

On Tue, 17 Apr 2007, Rene Herman wrote:

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

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

Re: git branch --switch?

[Rene Herman]

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.