Chris Webb <chris@xxxxxxxxxxxx> writes:
> Jeff King <peff@xxxxxxxx> writes:
>
>> I think the only thing you can do is make a fake sentinel commit (with
>> an empty tree) to put in HEAD, and then remove the sentinel immediately
>> after the first commit is put in place (making sure not to include it in
>> the first commit's parent list). Yuck.
>
> If I do this:
>
> diff --git a/path.c b/path.c
> index 6f2aa69..1b3b6f3 100644
> --- a/path.c
> +++ b/path.c
> @@ -169,8 +169,9 @@ int validate_headref(const char *path)
> int fd;
> ssize_t len;
>
> + /* Allow HEAD to be entirely missing for detached orphan state */
> if (lstat(path, &st) < 0)
> - return -1;
> + return errno == ENOENT ? 0 : -1;
>
> /* Make sure it is a "refs/.." symlink */
> if (S_ISLNK(st.st_mode)) {
>
>
> to thwart the sanity check, I can do 'rm $GIT_DIR/HEAD' to put my HEAD into a
> state where it is both detached and unborn, i.e. so that my next commit will
> result in a detached HEAD pointing at a root commit.
No thanks. It will be too big a change to the fundamental invariant
for what a git directory is (and isn't). It is simply unacceptable
to suddenly start treating a random directory that does not even
have HEAD as a git directory.
It would be a lot more palatable approach to teach "rebase -i" defer
its "detaching HEAD to the onto commit" step before starting to read
the insn sheet. Would such a change be too involved for it to be
worth supporting "rebase --root -i"?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html