[petsc-dev] 'master' RESET after bad merge! - 'tisaac/thplex' was based on 'next'

[Patrick Sanan]

On 9/3/14 9:03 PM, Satish Balay wrote:
> On Wed, 3 Sep 2014, Matthew Knepley wrote:
>
>> On Wed, Sep 3, 2014 at 1:51 PM, Jed Brown <jed at jedbrown.org> wrote:
>>
>>> Matthew Knepley <knepley at gmail.com> writes:
>>>> These are ridiculous strawmen. Git is a tool for managing source code,
>>> and
>>>> we are asking for a very simple and sensible source code management rule.
>>>> It is truly simple, apart from devising an implementation in Git.
>>> My point is that it's not that simple to define precisely within Git's
>>> relatively simple data model.  Barry suggests that Git should be made
>>> more complicated so that it can enforce various workflow policies, but I
>>> don't think that complexity is justified and I think it would cause
>>> other problems (like security vulnerabilities and extra constraints when
>>> manipulating branches).
>>>
>> You are saying:
>>
>>    - This is a sensible policy
>>
>>    - It would improve our workflow
>>
>> but
>>
>>    - Automating it is too hard, so people should do it by hand
>>
>> You come to this conclusion because
>>
>>    - It is hard to do in Git, as currently conceived
>>
>> It is not a stretch to call this a cop out. I would seriously question the
>> legitimacy of a model
>> which cannot do this very simple and useful thing.
> I might be misunderstanding things - but I think git branches are nothing but
> tags. This feature enables the current git workflows.
>
> On the other hand - mercurial branches are more substantial branches -
> [so perhaps use branch names as distinct items and enforce such
> rules?]  but then one cannot use git workflows here?
>
> BTW: Why are there new branches off next?
Unless there is a legitimate (non-maintainer) reason for ever branching 
off next, then preventing (or automatically discouraging) people from 
branching from next in the first place might be another way to proceed, 
and perhaps avoids some of the complications of knowing if anything in a 
merge originated in next. Doing this with client-side git hooks has all 
the complications Jed mentioned before, though.

>
> Satish