Re: Useful tracking branches and auto merging

[Felipe Contreras <felipe.contreras@gmail.com>]

On Tue, Oct 5, 2010 at 11:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I believe this use-case is valid:
>>
>> * The user wants *all* his remote tracking branches to point to the
>> latest branch head in all the repos in the case the can be
>> fast-forwarded, and in the case they can't, print an error and
>> continue with the rest.
>
> I would not be so sure about the validity of that use case.
>
> If your tracking branches are always trailing, never having any real work
> of your own, there is no reason to have them locally, instead of checking
> them out on demand.  So let's forget about that case.

Don't be so quick. Typing 'master' is certain easier than
'origin/master', or 'stable' rather than 'linux-stable/master', or
'vj-feature-1' rather than 'whatever-repo-this-came-from/feature-1'.
The fact that you don't do it doesn't mean it's not a valid use-case.

> On the other hand, if you have forked a topic branch to build your new
> nifty feature at some known point (e.g. immediately after the upstream
> reached a new stable point), but you haven't done any real work on it, it
> is doubtful that it is even a good idea to fast-forward it automatically
> to begin with.  C.f.

Fortunately we have 'git checkout --no-track -b origin/foo'. Problem solved.

But rather, what I do is:
% git branch -t origin/foo
% git checkout -b nifty-feature foo

>   Message-ID: <AANLkTim85sH_2o=xCiDuoQrHq_7ZL96Y91xQMGxUP5Fy@mail.gmail.com>
>
>   "The real problem is that maintainers often pick random - and not at
>    all stable - points for their development to begin with. They just
>    pick some random "this is where Linus -git tree is today", and do
>    their development on top of that. THAT is the problem - they are
>    unaware that there's some nasty bug in that version."
>
> IOW, once I decided one point is a good place to fork a topic, created a
> branch off of it, but didn't have a chance to do a real work on it yet, it
> would be very irritating if "git pull" updated that branch only because I
> do not have my own commit on it yet.

Then either:
1) fork of a local branch
2) use --no-track
3) don't do 'git pull --all'

> I see little sanity in doing this with any option whose name has "all"; it
> largely depends on the workflow, and in a single repository, some branches
> may want to get fast-forwarded automatically while others don't [*2*].

I think if you are issuing 'git pull --all' you want your remote
tracking branches to fast forward if possible, if not, why are you
doing 'git pull --all'?

Cheers.

-- 
Felipe Contreras