Is it possible to reject not merge commits?

104 views
Skip to first unread message

Miklos Espak

unread,
May 15, 2012, 4:33:23 AM5/15/12
to gito...@googlegroups.com
Hi,

I would like to enforce a branching scheme where the integration
branches (e.g. master) can contain only merge commits.

A little simpler version of this:
http://nvie.com/posts/a-successful-git-branching-model/

Is this possible with gitolite? I saw in the docs that you can reject
merge commits in some branches, but is it possible to accept only
merge commits in some branch?

Thanks,
Miklos

Sitaram Chamarty

unread,
May 15, 2012, 4:56:29 AM5/15/12
to Miklos Espak, gito...@googlegroups.com
It's got less to do with gitolite and more to do with "how would you check"?

(1) Come up with a command line to do the check
(2) Add that into a VREF and use that VREF in your conf file
(3) ???
(4) PROFIT!!!

Miklos Espak

unread,
May 15, 2012, 5:02:06 AM5/15/12
to Sitaram Chamarty, gito...@googlegroups.com
The M permission refuses merge commits in refs that don't have it.
Then there is a way in gitolite to test if a commit is a merge or not,
isn't there? :)

I thought the same test here with a negation.

Where I'm wrong?

Sitaram Chamarty

unread,
May 15, 2012, 5:33:24 AM5/15/12
to Miklos Espak, gito...@googlegroups.com
The existing merge-check asks "are there any merge commits"? The
negation of the answer to that question is not necessarily the answer
to "are there any non-merge commits".

(Hint: when you have both types of commits in a push, both questions
have "yes" as the answer. Basic boolean logic... if you can't get
this you should not be a developer).

Now let's get specific. The merge check works by checking if this command:

git rev-list -n 1 --merges $oldsha..$newsha

produces any output (empty => no merge pushes, non-empty => some merge push).

You might think you'll use "--no-merges" there, but I suspect that
will not be sufficient. You probably need to add --first-parent to it
(I am guessing here).

Do that, test it thoroughly, satisfy yourself that you have a shell
command whose output (or lack of) can be used to determine what you
want.

Then take src/VREF/MERGE-CHECK as a model and roll your own
NO-MERGE-CHECK script, replacing the command (in line 46, at present,
on v3.x) with the command you tested.

Finally, let me be very specific that you do not need my help to do
this, and you do not need any changes to gitolite to do this.

--
Sitaram

Miklos Espak

unread,
May 15, 2012, 5:49:51 AM5/15/12
to Sitaram Chamarty, gito...@googlegroups.com
I appreciate your trying to help, but could you please stop thinking
that others are idiot?

Yes, I know predicate logic very well, as well other type of logics. I
don't think that discussing this would really move forward solving
this problem.

I suggested there is a way in Gitolite to check if a *commit* is a
merge or not.

NOT that if a sequence of commits contains a merge or not. Please,
read carefully before you express your personal opinion about others'
ability of understanding logic.

I will answer the relevant part of the letter soon.

Best,
Miklos

Sitaram Chamarty

unread,
May 15, 2012, 6:16:28 AM5/15/12
to Miklos Espak, gito...@googlegroups.com
On Tue, May 15, 2012 at 3:19 PM, Miklos Espak <esp...@gmail.com> wrote:
> I appreciate your trying to help, but could you please stop thinking
> that others are idiot?

My apologies for implying that.

I have nothing else to add, from a technical point of view, so I'm
sure you'll figure it out from my previous email.
Reply all
Reply to author
Forward
0 new messages