Thread (7 messages) flat view 7 messages, 3 authors, 2016-08-11

Re: git bug? + question

From: Shawn Pearce <hidden>
Date: 2016-08-11 19:17:49

Josef Weidendorfer [off-list ref] wrote:
On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
quoted
After reading your reply you are probably correct.  I can see there
may be workflows that want every remote branch also created as a
local branch.

I could certainly live with a command line option to clone, e.g.:

	git clone --only vmdvt,vmtip user@host:/path...
Still missing here: What branch should be checked out after
cloning?
Ah.

I probably should have also stated that my users should be doing
-n as well with git clone, then using git checkout -b to create
a new branch from one of the refs they did clone.  (Reason is we
strictly follow a topic branch model of development, with even the
developer's local branches beginning with their initials.)

But you have a good point.  Cloning with say --only as I show above
might be confusing as its not defined what branch to checkout after
the clone.
 
Perhaps it is better to extend git-checkout to allow to do the
correct thing when the user specifies a read-only branch from
refs/remotes. E.g. with refs/remotes/origin/vmdvt,

 	git checkout origin/vmdvt

should create a new local branch refs/heads/vmdvt which forks
from remotes/origin/vmdvt (and abort with
error if refs/heads/vmdvt already exists without being the local
development branch for remotes/origin/vmdvt)
Yes, that would work for our workflow.  I won't try to speak about
anyone else's.

I'd also say that if the local branch (refs/heads/vmdvt) exists and
if `git pull . origin/vmdvt` is going to be a fast-forward that the
fast-forward should happen during the checkout.  That way after the
checkout is complete you really do have what is in origin/vmdvt,
but are sitting on a local branch.

-- 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help