git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Gated Merge?

From
Jeff King <peff@peff.net>
Date
Feb 12, 2016, 19:00 UTC
Message-ID
<20160212190017.GA20801@sigill.intra.peff.net>
In-Reply-To
<xmqqr3ghvn6a.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 12, 2016 at 09:44:13AM -0800, Junio C Hamano wrote:
Show 9 quoted lines
> 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.

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.
Previous: Junio C HamanoNext: Junio C Hamano
Message 5 of 7 in “Gated Merge?”
  1. Junio C HamanoFeb 11, 2016
  2. Andrew ArdillFeb 11, 2016
  3. Stefan BellerFeb 11, 2016
  4. Junio C HamanoFeb 12, 2016
  5. Jeff KingFeb 12, 2016
  6. Junio C HamanoFeb 12, 2016
  7. Jeff KingFeb 12, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.