Re: Editing the root commit
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:54:09
Chris Webb [off-list ref] writes:
quoted hunk
Jeff King [off-list ref] writes:quoted
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"?