Question

I am curious as to what people use for unit-testing and memory-testing tags in git.

For example, I periodically run my C++ code through valgrind, drd, and helgrind.

I will force tag with mem_ok, drd_ok, and helgrind_ok if they pass.

Of course, the drawback is, I will lose all my historical tags.

I suppose an alternative is to number them (instead of using force) like mem_ok_1, mem_ok_2, mem_ok_3, etc… …perhaps I should write a script to number my tags?

What do developers currently do to achieve this kind of functionality in git?

Potential Solution [uses branches instead of tags]

Suppose I have the following branches:

• master commits must pass google-test, valgrind, drd, helgrind
• unstable commits must pass google-test

I am thinking of this kind of workflow (M for master, U for unstable)

M1 -> U1 (branch off M1)
      U2 
      U3 
M2 <- U4 [merge]
      U5 
M3 <- U6 [merge]

In U2, U3, and U5, the commits just pass google-test: I don’t have time to valgrind, drd, helgrind.
I merge U4 and U6 into M2 and M3 after I have verified that all tests (including valgrind, drd, helgrind) pass.

The part I am confused about is, when I merge U4 into M2, do I have to branch again or can I just continue working of U4 to commit U5, U6, etc…?

In other words, I only need to branch from master to development once in the beginning with this workflow, correct?

Answer 1

Git tags aren’t really designed to be put on lots of commits like that. Instead, I’d suggest integrating your valgrind etc tests into your workflow, rather than into your branch. If you’re confident that your commits will compile happily, you could automatically run your tests, and if they pass, pull from development to passed-unit-test – a cron job or similar, if time taken to run the tests is an issue.

You could use a git hook to disallow pushes into the passed-unit-test branch unless the unit tests were passed.

You’d then have a branch which would only contain code which has passed the tests. That’s a neater solution then incrementally tagging, or tagging at all.

---

Edit:

In other words, I only need to branch from master to development once in the beginning with this workflow, correct?

Yes. development rolls into master, master only gets pushed into development at the beginning (and if applicable, if there are bugfixes – this might not be relevant to you, though).

Longer explanation and reasoning: I would use a workflow based heavily off of the Nvie Git Flow workflow. (The associated scripts are located here). It’s reasonably well used, and there’s a bunch of stuff written about this workflow, such as this (jeffkreefmeijer.com) and this (vimeo.com), if you feel like getting a solid understanding of the methodology and reasoning behind the workflow. This type of workflow gives you a couple of obvious benefits straight away:

• You have an obvious “release” branch (ie, master). This solves your hesitation with regards to merging strategies.
• The entire workflow is based around getting features merged into master, via release candidate branches – slotting in the relevant tests is conceptually easy.

So:

The part I am confused about is, when I merge U4 into M2, do I have to branch again or can I just continue working of U4 to commit U5, U6, etc…?

Assuming you’re working with a “two-branch” model similar to the Nvie Git Flow, something like this would work:

M    
| \
|  U // Branch Unstable off Master to begin with. 
|  |
|  U1 // Finish commit series between U and U1; commit to Master
| /|
M1 |
|  U2 // Finish commit series between U1 and U2; commit to Master
| /|
M2 |

-etc-

Your development branch, which I’ll call unstable to follow the question, gets branched off master (because you do further development on the code that you’ve released; code that you’ve release, ie “good” code, resides in master) at the beginning.

After that, master does not get rolled back into development. The reason for this is fairly simple; master is the place that your “good” code is. You shouldn’t be editing this code directly. (As an aside, master is a great place for tagging).

The exception for this are bugfixes; that depends on how closely you’re following the Git Flow model. If the bugfix is urgent, though, you probably want to be doing the bugfix on commit x (the broken one), not commit x+nD, where D are development commits. Once you’ve fixed the code, though, you do want the bugfix put back onto the development code; otherwise you’ll just produce re-broken code.
Bugfixes and the like might not be relevant to you, however; a two-branch model, such as the one you’ve drawn out, is perhaps enough for your project. 🙂