Re: Editing the root commit
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 22, 2012, 21:35 UTC
- Message-ID
- <7vobobm3mi.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120622205026.GI32205@arachsys.com>
Chris Webb <chris@arachsys.com> writes:
Show 29 quoted lines
> Jeff King <peff@peff.net> 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"?