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.
Surprisingly, this check appears to be the only thing disallowing such a state,
and the result behaves as sanely as a normal git-checkout --orphan <branch>
does! Using a detached unborn HEAD like this would avoid any need for sentinel
commits or the like in generalising rebase: we'd just do
git rm -rf .
rm -f $GIT_DIR/index $GIT_DIR/HEAD
instead of git checkout $onto, and be away replaying the commits or executing
the instruction sheet as normal.
If I prepared a proper patch series with docs and tests, would allowing this be
acceptable? I don't want to work on it if there's an intentional design
decision to explicitly disallow it. However, apart from just rebase and
rebase--interactive, I suspect other scripts which operate on history will be
more easily generalised to work on history right up to the root commit if such
a state were allowed.
PS Whilst experimenting, I also noticed a (presumably unintentional) behaviour:
$ git init .
Initialized empty Git repository in /tmp/foo/.git/
$ git checkout --detach
$ touch bar
$ git add bar
$ git commit -m test
[(null) (root-commit) 17b5bf9] test
0 files changed
create mode 100644 bar
$ ls .git/refs/heads/
(null)
$
Here we've created a branch with the strange name '(null)' instead of actually
detaching, or refusing to detach because we're on an unborn branch.
Assuming this is a bug, I'll cook up a patch to fix it either way, either by
entering a detached unborn state if we're allowing that, or to refuse to detach
if we're not allowing that state.
Best wishes,
Chris.
--
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