On Thu, 02 Nov 2006 18:40:30 -0800
Junio C Hamano [off-list ref] wrote:
quoted
which is efficient (guaranteed to do only one fetch from remote)
and convenient. Also I have Push: mapping set up on my
main machine to do master:origin, next:next, maint:maint, and
+pu:pu so that I can replace the first "git pull" on the
secondary machine with "git push secondary" on my main machine.
One thing that would make separate-remotes nicer to work with
is to have an automatic mapping between any local branch and
one of the same name in remotes.
So for instance, if you have a local branch named pu checked
out and you pull from origin, remotes/origin/pu would be merged
after the fetch unless a manual mapping was defined in the
remotes or config file.
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 ...
Why? Because vmtip and vmdvt have meaning to these users, much as
pu has meaning. Really vmtip is roughly equal to master in Git and
vmdvt is roughly equal to maint but not having the mental mapping of
"vmtip == master" just makes things easier.
Creating a local branch for every remote branch would just make
things worse in the above workflow; not to mention it makes it
confusing for other users who might be fetching into a repository
and expecting their local "next" to to update automatically after
a fetch...
On a peripherally related topic, someone on the xorg list was
complaining that after the initial clone, there is no easy way
to track branches that get added/deleted from the remote repo.
It would be nice if pull had an option to automatically add
and remove remote branches from the remotes/<remote>/xxx
namespace.
Or at least deleting/skipping over a branch you listed to fetch
from the remote that no longer happnes to be on the remote. This is
causing some pain due to the topic branches noted above.
--
On Sat, 04 Nov 2006 04:03:39 -0800
Junio C Hamano [off-list ref] wrote:
There is no "get it right most of the time" that would apply to
every workflow. We should just admit that no default layout and
configuration would suit everybody's needs. What we should do
is to try to capture a handful useful patterns and make it easy
for people to apply those canned patterns.
Consider it admitted ;o) But there is no need to have just a single
configuration that suits everybody. For instance, nobody is saying
to do away with the current default in favor of use-separate-remotes.
That is why someone saying "Nak" to a feature where all branches
are checked out locally on clone is "rash". Because it _is_ valuable
to some workflows. There is no reason Git could not support it. If
it gets in the way of some workflows, then we just make it a
configuration option. However, I don't feel strongly about this
particular option, if you notice in my email I merely suggested it
for discussion.
But by the same token, Git should _better_ support Shawn's example
workflow where currently Git makes him delete a bunch of branches
and edit the remotes/origin file every time after cloning. It would
be rash of me to send out a Nak for such an improvement just because
I don't need that feature.
All that remains is coming to some consensus on which set of options
should be enabled for new Git users. Once someone is up to speed, they
can enable whichever options support their workflow. But once they've
enabled those options, Git should do it's best to support that workflow
without a lot of manual intervention most of the time. That's what
the options I was suggesting would do for some workflows.
On Fri, 3 Nov 2006 15:36:10 -0500
Shawn Pearce [off-list ref] wrote:
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.
From: Junio C Hamano <hidden> Date: 2016-08-11 20:00:40
Sean [off-list ref] writes:
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.
I think this conversation demonstrates that this previous
statement of yours was also rather rash:
The essential point is that most of the time the Git user
should not have to manually create the merge entries in the
config file. Git should be smart enough to get it right most
of the time automatically.
There is no "get it right most of the time" that would apply to
every workflow. We should just admit that no default layout and
configuration would suit everybody's needs. What we should do
is to try to capture a handful useful patterns and make it easy
for people to apply those canned patterns.
For example, that is what we did for "git clone". We identified
two common layouts, traditional and separate-remote, and we
support both. The reason we might want to favor separate-remote
over traditional should be based on the expected workflow and
expertise level of the majority of users. If a census turns out
that the more experienced people tend to prefer traditional
layout, then changing the default to separate-remote would be
easier even if people with workflow separate-remote is more
appropriate is not the absolute majority, because the layout can
be easily changed by more experienced folks.
I think the "what should the default merge source be" topic is
very similar. There is no single _right_ way and to some extent
what the vanilla default is does not really matter.