Q:

experimental branch: how to record multiple alternative implementations?

I've set up an experimental branch in git, but I'm trying out a few different implementations of a feature, using different libraries.   I'd like to keep a record of these, as my own documentation of that approach/library.
My pre-git instinct is to comment out the previous experiment --- but what's the best way to handle multiple experiments in git (or version control generally)?
EDIT I should clarify these will often be little bits of code (really, parts of features), perhaps only 3-10 lines long. For example, using getenv("HOME") vs. wordexp on ~; using strcpy vs. memcpy. So there could be a lot of them, for alternatives on each step of even a relatively simple feature.
As a first stab, I've made a different branch for each version - but that will get unmanageable fast.
My current guess is:

implement the first experiment
commit it
delete the first experiment
implement the second experiment
commit it

Then I can just look at the log to find the particular experiment. EDIT log entry will then be commented and dated.
(Actually I'd probably like to instead comment out the first experiment while working on the second one, so I can refer to it easily - then delete it just before committing the second one).
Is that a good workflow?  Is there a better/standard approach?  Many thanks for sharing your experience!

A:

Using branches is the right way. It shouldn't become unmanageable. That's exactly where git shines. Branch off a commit, with a name that explains what's going on (e.g. git checkout -b featureX_fooLib), work on that, then branch off the same commit you originally branched off for the next test (e.g. git checkout -b featureX_barLib a41f38), and work there on the next example. You coulld also tag where you are before starting any of these branches - git tag featureX_libTestsBase - then for each new branch use that as the new starting point - git checkout -b featureX_bazLib featureX_libTestsBase.
I prefer not to have cruft from other places in my code, so I wouldn't want to be committing commented-out versions of old code in each new branch, but that doesn't mean I wouldn't do it; I just wouldn't have it be part of the barLib commits. One thing you could do is - from the working, final commit of the fooLib branch, save out a duplicate of the file, and don't add it to git. Now when you checkout the new barLib branch, it'll be there as an untracked file. You could also - from the new barLib branch - simply stomp over that commit's version of the file with git show featureX_fooLib:filename >filename. Now you can go in, comment out that bit, start working, and simply patch-add the new stuff for each new commit. This might be the best of both worlds.

