Johannes Schindelin wrote:
quoted text
> Hi,
> 
> On Thu, 25 Oct 2007, Andreas Ericsson wrote:
> 
>> Johannes Schindelin wrote:
>>
>>> On Thu, 25 Oct 2007, Andreas Ericsson wrote:
>>>
>>>> Johannes Schindelin wrote:
>>>>
>>>>> On Wed, 24 Oct 2007, Andreas Ericsson wrote:
>>>>>
>>>>>> Conceptually, I don't think it'll be any problem what so ever 
>>>>>> telling anyone that the branches that aren't currently checked 
>>>>>> out get merged automatically only if they result in a 
>>>>>> fast-forward.
>>>>> It would be a matter of seconds until someone asks "why only 
>>>>> fast-forwards? Would it not be _much_ better to merge _always_?  
>>>>> Stupid git."
>>>>>
>>>>> And all because the concept of "local" vs "remote" was blurred.
>>>> It's already blurred, since we have git-pull instead of just 
>>>> git-fetch.
>>> Huh?  How is "I ask git pull to fetch the remote branch, and merge it 
>>> into my local branch" a blurring of local vs remote branch?
>>>
>>> The local branch is still the local branch where it is _my_ 
>>> responsibility to update or change anything.
>> True. So git pull saves you exactly one command. The various 
>> fetch-all-git- repos-and-update-all-fast-forward-branches in circulation 
>> at the office save us ~500 commands each time they're run. Or rather, 
>> they *could* do that, but you can't know until you've run it.
> 
> As I pointed out, there is no way to sensibly have 500 _local_ branches 
> lying around.
> 
> It is ridiculous to assume that you have to have local branches for all 
> the stable, maintenance, whatever branches.
> 
> When you have to change something, you branch, hack, develop, commit, 
> push, and then _clean up_ after yourself.  No need to clutter your 
> local branch space with unused branches.
> 

error: The branch 'next' is not a strict subset of your current HEAD.
If you are sure you want to delete it, run 'git branch -D next'.

So you want me to tell all the developers they should use "git branch
-D maint" instead, so they can bypass the built-in security checks? No
thanks.

quoted text
>> So what should I do to make what I want possible, without having 
>> git-pull muddy the waters of local vs remote? There's clearly a user 
>> desire for it, besides that of my eight co-workers and myself. Introduce 
>> git-<cmd-156>?
> 
> If you _insist_ on your workflow, hey, git is a free program, and you can 
> do what you want to do with an alias easily enough.

With a git alias? No. There aren't even any switches in git to make it do
what I want. With a shell alias? Sure, it's doable, but cumbersome. With a
shell-script I can get it done, but it's ugly, inefficient and has to parse
everything twice. It's also a time-sink, and time is something I don't have
very much of right now.

quoted text
>  You can even make 
> that alias part of the templates, so you can force your desires down the 
> throat of every of your coworkers.
> 

They're the ones that requested I hack it into git, but the result would
remain the same, ofcourse.

quoted text
> However, that does not mean that you can insist on support for your 
> workflow in upstream git.
> 

I'm not. We're currently discussing the pros and the cons, and I'm spending
my free 20 minutes every night working on a patch-series to make git-pull
a built-in and then implementing the switch/config-option/whatever that
makes it do what I want it to do. Apart from Junio, that's how everyone
that wants a feature implemented has to do it, so I'd hardly call that
insisting. If Junio decides the patch does something evil, I'll have to
settle for cherry-picking it into whatever branch I want to build from.

On a side note; I'd *love* for it to have a rebase option as well. Perhaps
I'll do that next. In the mean-time, I'd settle for just updating locally
modifiable copies of tracking branches that I've already configured git to
merge with a tracking branch when it happens to be a fast-forward.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html