Johannes Schindelin wrote:
Hi,
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.
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? Do they
*really* go into all those branches and make really, really sure they run
git pull before they ever do anything? Isn't there a teensy weensy risk of
them forgetting that sometime when they really meant to do it?
On the other hand, if they absolutely *must* fork a branch at a specific
point in history (rather than "the latest published work this branch has"),
won't they run gitk/qgit/git-log/whatever, regardless of where their branch
head is?
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?"
frequently echoes around the office. My co-workers aren't interested in
learning about git internals, or its reasons for doing what it does.
They don't give a damn about local vs remote namespaces for their branches.
They want to get some work done the smoothest way possible, but with our
small forest of repositories and the bushel of branches in each repo
makes life difficult for them, because they just can't imagine that
git doesn't do what they told it to, which is "this branch tracks that".
They may work on "this", but still want it to track "that" so they don't
have to run "git-update-all.sh", or "git-walk-everything.sh" or any other
of a dozen small and near-identical scripts floating around the office.
--
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
