On Fri, Feb 12, 2016 at 09:44:13AM -0800, Junio C Hamano wrote:
> Andrew Ardill <andrew.ardill@xxxxxxxxx> 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.
After reading Andrew's message, I wondered if these are really any
different than regular tests at all.
Let's say I implement feature X on a topic branch, and I add a
regression test for it. Once that is merged, now we have that regression
test forever[1], and any future topic branches that get merged from
master must pass that test or be rejected.
If I update the interface for foo(), it is the same thing. We do not
write a specific test for it, but we expect that the compiler will catch
any callers of the old foo, because the new tree carries the updated
definition that will not work with them (and we often structure our
interface refactoring exactly to catch such things).
So let's go back to your FORMAT_PRINT example. The topic changes all of
the format-attributes into FORMAT_PRINTF, but we never add a "test" that
says "now there are no more bare format-attributes, and if there are, it
is a regression".
But I don't think this needs to have anything to do with merges in
particular, or rules like "when merging a branch that does not have me
in it". It is about saying "from here on out, the tree state should
match this property, and we can test it by running this script". And
then running "make code-lint-tests" becomes part of the acceptance
testing for a proposed topic merge, just like "make test" is already
(and likewise, people forking _new_ branches from master after the topic
is merged would make sure they do not fail the code-lint tests before
even submitting the topic).
-Peff
[1] Of course it doesn't _have_ to be forever. We sometimes modify or
back out tests as new situations come up, and we could do the same for
these sorts of code-lint tests.
--
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