Re: Moving to git

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
<ramana.gcc@googlemail.com> wrote:
> On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
>>>>
>>>> Absolutely, a non-fast-forward push is anathema for anything other people
>>>> might be working on.  The git repository already prohibits this; people that
>>>> want to push-rebase-push their own branches need to delete the branch before
>>>> pushing again.
>>>
>>> On the FSF trunk and the main release branches - I agree this is a
>>> complete no-no.
>>>
>>> A push-rebase-push development model is possible / may be useful when
>>> the developers collaborating on that branch agree on that model.
>>
>> Teams following a different model could use a separate repo shared by
>> those developers, not the gcc.gnu.org one. It's much easier to do that
>> with git.
>
> Yes you are right they sure can, but one of the reasons that teams are
> doing their development on a feature branch is so that they can obtain
> feedback and collaborate with others in the community. People wanting
> to adopt more aggressive uses of git should be allowed to do so in
> their private branches as long as they are not able to mess up the
> official branches in the repository.
>
> If there is no way to have some branches in a repo allow rebasing and
> others not, that's fine but I'd like to know that's the case.
>
> Adopting restrictions on the official branches is quite right (list
> below not extensive but it sounds like) ...
>
> a. no rebase / rewriting history
> b. no git merges from feature branches.

One very frustrating thing for me is "git bisect" doesn't always
work.  I think cherry-pick is OK, but probably not rebase nor merge.

Can we enforce that "git bisect" must work on official branches?

-- 
H.J.