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 <[email protected]> wrote:
Matthew Knepley <[email protected]> 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
