Re: Gated Merge?

[Junio C Hamano <gitster@pobox.com>]

Andrew Ardill <andrew.ardill@gmail.com> writes:

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

Interesting.  I have never thought of adding this information to the
project history proper---I've viewed this as primarily an aid for
keeping track of topics in-flight by an individual, i.e. something
that the rest of the project do not want to even see.

> 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)

I think that this will not be a problem in practice if we took your
alternative approach to cap the topic with an extra commit that adds
the Merge Gate test; because the workflow this targets treat a topic
as a single unit, the extra commit will be rebased together with the
real commits in the topic.

>  - 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)

Yeah, I think that this is very similar to "something that the rest
of the project do not want to even see" problem, if you use an in-tree
approach.

> Cons:
>
>  - difficult to see the current complete set of merge-gates

Yes, we would need to have a quick way to enumerate commits with
these notes in the rev-list output.

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

Hmm, I am not sure if/how that will be an issue.

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

True. With an in-tree approach, you can define the order with the
filenames, for example, and the above will be clearer. Instead, you
would need to worry about name clashes, though.