Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

[Andreas Ericsson <ae@op5.se>]

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@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231