Re: [PATCH 1/2] Add tests for git-sh-setup's require_clean_work_tree()

SZEDER Gábor [off-list ref] writes:

Quoting Junio C Hamano [off-list ref]:

quoted

quoted

+test_expect_success 'error on clean index and worktree while on  
orphan branch' '
+	test_when_finished "git checkout master" &&
+	git checkout --orphan orphan &&
+	git reset --hard &&
+	test_must_fail run_require_clean_work_tree
+'

The title is wrong.  Immediately after creating and getting on an
orphan branch, you have stuff in the index that is not committed to
the branch, so your index cannot be clean by definition.

The index contains the file 'file', so it's not clean indeed.

quoted

The
contents of the working tree may or may not be clean immediately
after getting on a new orphan branch, but you are doing "reset
--hard" to make the index and the working tree agree,

... and match HEAD, which in this case means both the index and the
worktree become empty.

'git rm -r .' would have made the intent clearer.  Or 'git init emptyrepo'.

quoted

so this is
testing the "clean working tree" case, I think.

So the question is, before we go any further: are an empty index and
empty worktree clean when HEAD doesn't point to a commit?  (either after
the command sequence in the above test, or right after 'git init').

I do think they are clean.

That is "rm -fr test && git init test && cd test" case, right?

It may be consistent to define it as clean, but I am not sure
existing operations that require a clean working tree is useful in
such a state (filter-branch, pull-rebase and rebase are the big
users, and none of them is so useful with an unborn history), so
loosening the definition would be not just helpful for them but
would be harmful, as they (implicitly) rely on require-clean to
stop the command early before they try to do something that needs
an existing history.

So, I am not sure if it is a good idea.