Johannes Schindelin wrote:
Hi,
On Thu, 25 Oct 2007, Andreas Ericsson wrote:
Johannes Schindelin wrote:
On Thu, 25 Oct 2007, Steffen Prohaska wrote:
On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
But I think I have to drive my message home again: if what you
desire becomes reality, you take away the clear distinction
between local and remote branches. In fact, those branches are
neither local (because the next pull will automatically update
them with remote changes, but _only_ if they fast-forward) nor
remote (because you plan to work on them locally).
Exactly, because I do not work on those branches alone. These are
_shared_ branches. I can work on such a branch with a group of
developers. I'm willing to accept this bit of chaos.
It is not just a chaos. I see a serious problem here. On _your_
computer, you do _not_ have a shared branch. Which is visible _even_
in your modified work flow when you have unpushed changes.
Ofcourse it is. People might pull from it. That's the whole point of a
distributed model.
By that reasoning, left is right. Because your "left" is my "right".
So your desired illusion that your local branches are anything but
local branches will never be perfect enough.
Your rebase workflow is not possible if more than one dev wants to
work on the topic branch together.
Why not? I do it all the time. CVS users do it all the time, for
that matter.
For 200 branches at a time, where any of them might have changed?
I slowly start to understand why your users are confused. _Nobody_ works
on 200 branches at the same time. (No, maintainers don't count: they do
not work _on_ the branches, but _with_; they merge them.)
When you're done with a topic, why do you leave it around? Cluttering up
your "git branch" output?
We have 91 repositories at work. Roughly 60 of those are in active use.
The active repos are organized pretty much like the git repo with
'master', 'next' and 'maint'. We *do* work on all branches, but not
every day, ofcourse. They're NOT topic branches. We implement features
on topic-branches that we DO throw away, but those branches HAVE to be
there for us to be able to handle supporting of old versions as well as
implementing new features in a sane way. Throwing them away locally would
mean having to re-create them very frequently, and since they have to
exist in the upstream repo, "git fetch" would fetch and re-create them
every single time anyway.
So please, pretty please just drop the entire "use topic branches" argument.
We do that, but still have this problem, and it *is* a problem.
The problem I see here: you know git quite well. Others don't, and
will be mightily confused why pull updates local branches sometimes,
and sometimes not.
Do you know this, or are you just guessing? I'm getting the exact same
confusion with the current behaviour. "Why the hell doesn't git update
all the branches I told the damn stupid tool to auto-merge when I pull?"
That's easy. A merge can have conflicts. Conflicts need a working
directory. You cannot have multiple working directories. (Actually, you
can, with git-new-workdir, which would break down _horribly_ with your
desired change.)
Oh? You don't have local changes? Then why _on earth_ do you have a
local branch?
Because it's convenient, ofcourse. Don't you have 'maint', 'next' and 'master'
in your clone of git.git? I'm guessing at least 99% of the people on this
list have those branches lying around in their clones, even if they only
ever use 'next' and/or 'master'.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
