git gc (garbage collection) should reset commit indices

[ohadschn]

Issue

Suppose I start with:
c0 <- c1(main)

I do git reset c0 and git gc so now I have:
c0(main)

Finally I do git commit and get:
c0 <- c2(main)

Where I would have expected:
c0 <- c1(main)

Impact

Beyond the matter of general consistency, this "current commit index" hidden state behavior interferes with level building.
Suppose I want the student to simply do git commit on a trivial graph (with only init commit). So starting from c0(main) I do:

• define start
• git commit
• define goal

But then when I share the level and the student does git commit they will get c0 <- c1(main) (and not c0 <- c2(main)) so the exercise won't succeed...

This is especially troublesome considering how build level seems to always start with c0 <- c1(main) (where reset just brings it back to that position)

Workaround

Reset the state to a "clean" trivial tree with:
importTreeNow {"branches":{"main":{"target":"C0","id":"main"}},"commits":{"C0":{"parents":[],"id":"C0","rootCommit":true}},"HEAD":{"target":"main","id":"HEAD"}}

[pcottle]

Where I would have expected:
c0 <- c1(main)

I think this expectation is up for debate -- when you perform git reset C0, the C1 commit still exists. It's still on your computer/filesystem and is perfectly valid, and could even have other branches pointing to it still!

git commit creates a new, unique, independent change that then is formed as a new commit. Thus you don't arrive back at C1, but you arrive at C2 instead (since your changes are different). Basically git commit would never produce the same set of changes twice, at least in this learning environment :)

I totally agree though that its a troublesome burden while building levels -- you have to make sure to not make any mistakes (or inflate your commit hash at all).

[ohadschn]

@pcottle perhaps you missed my point about `git gc` (after which C1 no longer exists)?