On Fri, 3 Nov 2006 15:36:10 -0500
Shawn Pearce [off-list ref] wrote:
quoted
quoted
Maybe even going as far as automatically creating a local branch
for each remote branch on clone is worth considering.
Nack.
I work with a workflow where our central repository has 2 important
branches (vmtip and vmvt), and a bunch of transient developer
topic branches (e.g. sp/foo). We only have a master branch in this
repository so that git-clone will clone it without choking during
the clone. Users tend to do immediately after a clone:
git branch -D master
git branch -D origin
git branch -D ... other topic branches not interested in ...
edit .git/remotes/origin ... delete topic branches ...
I think your Nack was a little rash here. The feature would be quite
useful to work flows other than yours. It sounds like what _you_ want
is a feature to select branches when cloning rather than the current
default of cloning all. That would stop your developers having to
delete branches and editing .git/remotes/origin immediately
after cloning.
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...
So yes, my 'Nack' may have been a little too rash.
--
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.
--
From: Andy Whitcroft <hidden> Date: 2016-08-11 19:24:37
Josef Weidendorfer 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?
Does any need to be checked out? Or perhap I should put it another way,
when we make a virgin repository we default to master checked out but
its not joined to the DAG. Perhaps we can just init-db and fetch the
specified branches and we are done. The user will then checkout things
as they need and if they do not need master they can lose it.
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), add to .git/config
[branch "vmdvt"]
remote = origin
merge = remotes/origin/vmdvt
and switch to this new created branch.
Given this addition to git-checkout, the implicit default
action after cloning with --use-separate-remote should be
git checkout origin/master
where "master" can be changed on the git-clone command line
to another branch, e.g. "--checkout vmdvt".
IMHO, this addition to git-checkout would make it a lot
easier to work with --use-separate-remote, as there,
every branch other the master is read-only.
And if you have two remote repositories with a master branch
each, and you want to develop locally on both, this could
be accomplished with
git checkout -b othermaster remotes/otherrepo/master
From: Josef Weidendorfer <hidden> Date: 2016-08-11 19:37:57
On Saturday 04 November 2006 20:05, Shawn Pearce wrote:
Josef Weidendorfer [off-list ref] wrote:
quoted
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.
Hmmm... But you are changing the tip of a local development branch,
which is probably not always the thing we want.
Thinking about it, we should always error out if a proposed branch
name for a read-only branch already exists.
Josef
From: Andy Whitcroft <hidden> Date: 2016-08-11 19:40:45
Josef Weidendorfer wrote:
On Monday 06 November 2006 10:53, Andy Whitcroft wrote:
quoted
Josef Weidendorfer wrote:
quoted
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?
Does any need to be checked out?
We should not change existing behavior. IMHO, checking out a branch is
mostly the right thing to do. Of course, you often want to specify which one.
The current requirement for a master branch in the origin repository
is really bad, as it obviously requires ugly workarounds in some cases
(and totally confuse newbies in such use cases).
We are not changing existing behaviour, if we do not check anything out
only when specifying '--only'.
quoted
Or perhap I should put it another way,
when we make a virgin repository we default to master checked out but
its not joined to the DAG.
I do not understand this. By creating a local branch, the commit DAG
is never changed.
In a virgin repository there is no DAG to speak of and master doesn't
really point anywhere until the first commit. I was proposing that when
--only is specified, we just leave things as they are. The master half
pointing into the zero element DAG we have in an entirely empty repo.
The new unconnected DAG or DAG's we have downloaded in the clone will be
attached to their respective branch names.
From: Josef Weidendorfer <hidden> Date: 2016-08-11 20:02:48
On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
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?
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), add to .git/config
[branch "vmdvt"]
remote = origin
merge = remotes/origin/vmdvt
and switch to this new created branch.
Given this addition to git-checkout, the implicit default
action after cloning with --use-separate-remote should be
git checkout origin/master
where "master" can be changed on the git-clone command line
to another branch, e.g. "--checkout vmdvt".
IMHO, this addition to git-checkout would make it a lot
easier to work with --use-separate-remote, as there,
every branch other the master is read-only.
And if you have two remote repositories with a master branch
each, and you want to develop locally on both, this could
be accomplished with
git checkout -b othermaster remotes/otherrepo/master
From: Josef Weidendorfer <hidden> Date: 2016-08-11 20:14:14
On Monday 06 November 2006 10:53, Andy Whitcroft wrote:
Josef Weidendorfer wrote:
quoted
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?
Does any need to be checked out?
We should not change existing behavior. IMHO, checking out a branch is
mostly the right thing to do. Of course, you often want to specify which one.
The current requirement for a master branch in the origin repository
is really bad, as it obviously requires ugly workarounds in some cases
(and totally confuse newbies in such use cases).
Or perhap I should put it another way,
when we make a virgin repository we default to master checked out but
its not joined to the DAG.
I do not understand this. By creating a local branch, the commit DAG
is never changed.