Re: [lmi] [lmi-commits] master 6c0c0f0 3/4: Add numerous failing unit tests

[Greg Chicares]

On 2018-03-19 00:45, Vadim Zeitlin wrote:
> On Sun, 18 Mar 2018 20:02:19 -0400 (EDT) Greg Chicares <address@hidden> wrote:
[...]
> GC> commit 6c0c0f04ad4f374710aaa5d46fc204f1acd40b4d

["Add numerous failing unit tests", fixed in the following commit]

>  I understand the rationale for doing it like this, but I'd just like to
> mention that such commits risk making future use of (very useful) "git
> bisect" more difficult than necessary

That's a good point.

>  An alternative solution would be to create a branch with these changes and
> then merge it into master (without using fast-forward merges), as this
> would still keep the invariant "unit tests always pass in master" unbroken,
> even if it was temporarily broken in the branch. But considering your
> preference of linear history, I don't think this would be acceptable.

Combining this with another recent thread...

On 2018-03-18 00:32, Vadim Zeitlin wrote:
| On Sun, 18 Mar 2018 00:09:43 +0000 Greg Chicares <address@hidden> wrote:
| 
| GC| It cost me some time to figure this out, so, not wanting to
| GC| throw the work away, I thought I'd post it here. Vadim, would
| GC| it be in poor taste to commit something like this to the
| GC| savannah repository as a forlorn branch, to be abandoned
| GC| immediately after committing it?
| 
|  I certainly don't see anything wrong with it, but it might be nice to
| establish some naming conventions for the long-lived branches. E.g. you
| could prefix its name with "experiment/" or "test/" or whatever else you
| prefer (you could also namespace it further by using "gwc/" if you'd like).
| The branch names don't matter for Git (as long as they don't conflict with
| one of the predefined names such as "HEAD"), but it could be nice for human
| users of the repository.

What about the following idea? I haven't tested it yet, but I think
it should keep 'master' linear and atomic, while branches could be
checked out separately at any time.

---------8<--------8<--------8<--------8<--------8<--------8<--------8<-------
  # Commit to a digressionary branch...

  # See:
  #   https://lists.nongnu.org/archive/html/lmi/2018-03/msg00082.html
  # Use consecutive branch names 'q[0-9]\{5}', i.e., q00000-q99999
  # Rationale:
  #   - in English words, initial 'q' is almost always followed by 'u'
  #   - 10000 such names should be enough for lmi's lifetime

  # ...for pure divagations

git branch qNNNNN
git checkout qNNNNN
git commit sandbox_test.cpp
git checkout master
git push origin qNNNNN

  # ...for failing unit tests that are to be...

git branch qNNNNN
git checkout qNNNNN
git commit miscellany_test.cpp -m"Add a failing unit test"
  # ...corrected later:
git checkout master
git cherry-pick --no-commit ..qNNNNN
git commit miscellany.cpp miscellany_test.cpp -m"Enhance to pass new unit test"
git push origin qNNNNN
--------->8-------->8-------->8-------->8-------->8-------->8-------->8-------

Above, where you had said:

>  An alternative solution would be to create a branch with these changes and
> then merge it into master (without using fast-forward merges), as this

why avoid fast-forward merges in the failing-unit-test case,
especially if a failing test's commit is immediately followed
by a code change to make the test pass? AIUI, git would do a
fast-forward merge anyway, because it knows it can in that case.
(Because of '--no-commit', the SHA1 on the branch wouldn't become
a node in 'master'.)

I don't understand these git concepts well enough to know whether
cherry-picking is orthogonal to fast-forwarding. I've just fallen
into the habit of cherry-picking instead of merging because it
seems more "familiar". I guess cherry-picking amounts to merging
a single commit--which is all I want to do in these scenarios.

At any rate, what I'm hoping to achieve is

    master  branches
    ------
   commit1
   commit2
            q00000 failing test
   commit3
     = q00000 + change to make test pass, combined atomically
   commit4
   commit5
            q00001 store an interesting dead twig off the trunk
   commit6
     [resume main line of development, forgetting q00001]