Re: Gated Merge?

From: Andrew Ardill <andrew.ardill@gmail.com>
Date: Feb 11, 2016, 22:42 UTC
Message-ID: <CAH5451=rVmdTra0rVNEkfdfOeSyeETSMo7YGWdYozZr_=YyAtw@mail.gmail.com>
In-Reply-To: <xmqqvb5uvr40.fsf@gitster.mtv.corp.google.com>

On 12 February 2016 at 09:06, Junio C Hamano <gitster@pobox.com> wrote:

Show 27 quoted lines

>
> To realize this, there are low-hanging-fruit building blocks that
> are trivial:
>
>  - Such an annotation can be made as a note attached to the commit
>    in question;
>
>  - Such a check can be done in pre-commit hook;
>
>  - Such a pre-commit hook can iterate over this set of commits
>
>     DIFF=$(git rev-list --left-right HEAD...MERGE_HEAD)
>
>    collect these Merge Gate annotations from the commit appears on
>    the left hand side (e.g. only exists on the trunk that a side
>    branch is about to be merged in), and run them.
>
> But the last one feels very costly, and I suspect that there must be
> a better way to do this.  I do not think we want the "what to do"
> part (i.e. checking new lines for __attribute__ in the first
> example, or rewriting new lines that has __attribute_ in the second
> example) to be in git-core; that clearly is outside the scope of the
> plumbing.  But the part that finds these "annotations", especially
> if we can come up with a fast implementation that may be hard to
> script, may be a good addition to the plumbing command set.
>
> Thoughts?

What is the benefit in doing this in notes vs having the tests in the working tree?

Pros:

 - merge-gates can be added after the commit, but will stick with the
commit if it moves around (as opposed to creating a second commit to
add the merge-gate to the working tree)

 - cross repository standards can be established that allow
merge-gates to be detected and run automatically (arguably could be
done with a standardised folder structure too, but that is more
disruptive)

 - can view the relevant merge-gates in git log against each commit
that they are protecting

Cons:

 - difficult to see the current complete set of merge-gates

 - difficult to make changes to a number of merge-gates at the same time

 - poorly defined behaviour when multiple merge-gates overlap in
functionality. Which gates execute first? What if I reorder the
commits?

My practical knowledge of notes is severely lacking so excuse me if I missed anything obvious.

Regards,

Andrew Ardill

(sorry for the double post Junio, gmail ate my plain text encoding at some point...)