On Wed, Apr 6, 2016 at 11:36 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> I was reviewing the topics to merge to 'master', and a thought
> crossed my mind. Both of our series only refuse to create a merge
> that does not have any common ancestor, but shouldn't the right
> solution refuse to add a new root?
So I think that's an independent thing, and I think you're right, it
would be a good feature to have. As a maintainer, it would have caught
the whole "my submaintainers did something really odd, I need to talk
to them" before-the-fact rather than after-the-fact.
That said, I'm less worried about my submaintainers doing
_intentionally_ annoying things, than people doing silly things by
mistake.
So if I had a version of git that allowed me to say "don't allow pulls
that add a new root commit unless I specify a '--new-root-allowed'
flag", then yes, I'd use that. And I guess it might not be too nasty
to add: it could be done as part of the object checking pass after
downloading the pack. Was that what you were thinking of?
But at the same time, I think the existing series you have, which
hopefully results in these things not happening by mistake in the
future is the more important piece. I'd rather get good pull requests
than get errors and have to tell people "you screwed up, now we'll
need to re-do this".
But if you cook something up that checks that there are no new roots
in the pull, I'd certainly appreciate that safety net.
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html