1

As I understand when I run git reset without any parameters and paths it defaults to --mixed which git manual describes as:

Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated.

I'm wondering what does it reset it to? I assume that it reads some tree into index file using git read-tree, but where does it find that tree? Some other options explain that the tree is found in the HEAD file which points to a commit or branch and hence a tree hash can be resolved.

However, I've used git read-tree aa23 to put the tree into index and currently my HEAD file contains the following:

ref: refs/heads/master

But there's no branch created yet. The tree contains two files:

$ git ls-files -s
100644 a1deaae8f9ac984a5bfd0e8eecfbafaf4a90a3d0 0       f1.txt
100644 9b96e21cb748285ebec53daec4afb2bdcb9a360a 0       f2.txt

And when I run the git reset I get no errors, git status reports no changes and git ls-files -s reports no files. So what did the index was reset to?

Max Koretskyi
  • 101,079
  • 60
  • 333
  • 488
  • 1
    It resets the index to the tree of the commit you asked it to reset to. If you don't specify a commit, it resets to HEAD. – Lasse V. Karlsen Aug 21 '17 at 08:37
  • right, but that's the question, I didn't specify any commit. And `HEAD` contains reference to the non-existing branch – Max Koretskyi Aug 21 '17 at 08:38
  • 1
    If you've only initialized an empty repository, reset will empty the index. – Lasse V. Karlsen Aug 21 '17 at 08:39
  • @LasseV.Karlsen, got, thanks. So to generalize, if GIT can't resolve a tree by following `HEAD` it simply empties the index, correct? – Max Koretskyi Aug 21 '17 at 08:44
  • No, it emptied the index because you don't have any commits in the repository to reset to (just after `git init`). If you have commits in the repository, but HEAD is corrupted (points to a branch that doesn't exist) then I don't know what happens, I assume this behavior is undefined. – Lasse V. Karlsen Aug 21 '17 at 08:45
  • @LasseV.Karlsen, just tried to create a commit manually with `echo 'initial commit' | git commit-tree e05d9da`. Then checked out the tree with `read-tree` and `checkout-index`. Then ran `git reset` and got no error although one commit exists. Have empty index file. So probably git resets to the empty index if it can't resolve the tree by `HEAD` – Max Koretskyi Aug 21 '17 at 09:36

1 Answers1

3

When running git reset on an unborn branch, Git explicitly uses the semi-secret empty tree as the target of the reset:

unborn = !strcmp(rev, "HEAD") && get_sha1("HEAD", oid.hash);
if (unborn) {
        /* reset on unborn branch: treat as reset to empty tree */
        hashcpy(oid.hash, EMPTY_TREE_SHA1_BIN);
} else if (!pathspec.nr) {

With the top level tree being empty, the correct (at least notionally) result for resetting the index entry for any path P is to remove P from the index.

torek
  • 448,244
  • 59
  • 642
  • 775
  • great, thanks again! I'm writing an article on git internals, I'll drop it here tomorrow, if you have time maybe you'll quickly skim it for technical inconsistencies? – Max Koretskyi Aug 21 '17 at 17:33