These tests have a bit of logging that should be removed before this PR is merged.

Reminds me, I think your previous PR had some logging as well. Should we remove those? It makes the test output a bit hard to parse.

Reminds me, I think your previous PR had some logging as well. Should we remove those? It makes the test output a bit hard to parse.

The tests do indeed result in output to stdout/stderr but it's a side-effect of the tests. Right now, you can't redirect either of those io.Writers in "core" so each time I create repositories for the tests, there are two new lines written (I'm not reusing the same repository for all the tests as that will make it hard to use t.Parallel() in the future.

Ignoring the extra logging I mentioned above and the failed test's output, running the CLI tests results in output like this:

Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.
Building identity cache... Done.
Building bug cache... Done.

Every time I add a test, there are two more lines and so it's been getting more annoying as more of the CLI has test coverage. I haven't really started covering the error paths yet! A couple days ago, I created #849 to address this in the "core" - that will result quiet (passing) tests when there's a failure or when the -v flag is used.

The tests do indeed result in output to stdout/stderr but it's a side-effect of the tests.

Now that I am on a computer ... I was actually thinking about this one: https://github.com/MichaelMure/git-bug/blob/master/commands/ls_test.go#L80

Regarding this specific issue, it might be something I noticed a while back in #664 but hasn't been merged yet: https://github.com/MichaelMure/git-bug/pull/664/files?show-deleted-files=true&show-viewed-files=true&file-filters%5B%5D=#diff-8ad691e03338c49c8ea10285bf2a59172fc5b230f161292b92931a66c06b5f6aR275-R282

I don't remember exactly why I made that change, but it looks like the combined Id need to be resolved to a comment/operation Id first. If the Id is incorrect, the operation will silently do nothing when applying as it's considered invalid.

Ugh ... you're right! That logging should have been removed but since it's a t.Log() I needed to use the v flag to see it (unless the test fails). Fixed in 2c2c449.

From what you've described, I think the following code (to be removed from the test) should be working:

	// TODO: remove this comment and everything between the "snip"
	//       comments when issue #850 is resolved.

	// ***** snip *****
	cache, err := env.env.backend.ResolveBugPrefix(bugID)
	require.NoError(t, err)
	bu, err := bug.Read(env.env.repo, cache.Id())
	require.NoError(t, err)
	for _, op := range bu.Operations() {
		t.Log("Operation: ", op)
	}
	t.Log("Compiled comments: ", bu.Compile().Comments)
	// ***** snip *****

Let me know if you see something that could be improved for debugging purposes!

@MichaelMure - The problem described in #850 (git-bug comment edit has no effect) was closed by #664 so I've updated this PR to simply provide tests for the CLI comment add and comment edit commands.