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

Re: Test that every revision builds before pushing changes?

From
Andreas Ericsson <ae@op5.se>
Date
Mar 26, 2009, 08:16 UTC
Message-ID
<49CB39E5.5060000@op5.se>
In-Reply-To
<87myb8aja1.fsf@rimspace.net>
Daniel Pittman wrote:
Show 14 quoted lines
> G'day.
> 
> I would like to ensure that my commits are fully bisectable before I
> commit them to an upstream repository, at least to the limits of an
> automatic tool for testing them.
> 
> 'git bisect run' is similar: it can automatically locate the breaking in
> a test suite, for example, but that doesn't help me in the case of three
> commits, A (good), B (bad) and C (good, fixing B).
> 
> I would much rather, in this case, use rebase to fix B so that it, too,
> builds before I push the changes and pollute a public repository with a
> broken changeset — and make bisect that much harder to use in future.
> 

You can do that, but it requires manual work too. The trick is to make the release branch immutable on the public repository and use topic branches with per-developer namespaces. The per-developer namespace thing is actually important, as it leaves the freedom to rewind and recreate topics to the developers (which shared branches do not).

The manual step comes at merge-time; Someone has to be responsible for merging all the topics that are to be included in the release branch and make sure it builds and passes all tests after each merge.

This workflow is a bit cumbersome. NASA uses something like this but with an extra step for multiple peer reviews on every feature/fix for software they send to satellites. Or so I've heard anyways.

If you're thinking of a staging area that should queue all commits and lock the repo while testing is in progress, you need to think again, I'm afraid, as that locks up developer time in such huge amounts that it isn't really worth it. Without the locking, you get the problem of trying to automate merges (which may conflict and need a manual resolution). Although I guess a merge conflict could result in a delayed push error, so perhaps that could work too. If you manage to cook up a solution for this, please make a small writeup on this list how you went about achieving it.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
Previous: Daniel PittmanNext: Daniel Pittman
Message 2 of 7 in “Test that every revision builds before pushing changes?”
  1. Daniel PittmanMar 26, 2009
  2. Andreas EricssonMar 26, 2009
  3. Daniel PittmanMar 26, 2009
  4. Andreas EricssonMar 26, 2009
  5. Daniel PittmanMar 27, 2009
  6. Jeff KingMar 26, 2009
  7. Wincent ColaiutaMar 26, 2009

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.