On Thu, Oct 25, 2007 at 09:15:35AM +0200, Andreas Ericsson wrote:
quoted text > 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.
>
What actually wonders me why you guys do have 200 local branches. I
usually just create a local branch from the remote IFF I'd like to do some
work on it. And for inspecting a remote branch, a detached HEAD works just as
fine ...
-Peter
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
