Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

grit: fix sort order of newly-created trees with sub-trees #186

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

peff
Copy link
Contributor

@peff peff commented Mar 24, 2014

Git has odd sorting requirements for tree entries. The entries are sorted by name, but sub-trees sort as if they had "/" at the end. That means when you add full paths to the index like this:

index.add("foo.bar", "content")
index.add("foo/file", "content")
index.write_tree()

the resulting tree ends up sorted correctly (foo must come after foo.bar, because / comes after .). But if you provide individual sha1s, like this:

index.add("foo.bar", "content")
index.add("foo", [some_tree_sha1, "40000"])
index.write_tree()

we end up sorting the entries in the wrong order. Git complains (and may provide incorrect answers for diffs, since we rely on the sort order there).

The fix is fairly straightforward; we already take special care to use a separate sorting key that includes the "/", but we missed the case of a sub-tree being named explicitly by its sha1.

I know Grit is in "deprecated mode", but this is a real bug that can cause corrupt objects to be created. It's probably worth including.

Git has odd sorting requirements for tree entries. The
entries are sorted by name, but sub-trees sort as if they
had "/" at the end. That means when you add full paths to
the index like this:

    index.add("foo.bar", "content")
    index.add("foo/file", "content")
    index.write_tree()

the resulting tree ends up sorted correctly (`foo` must come
after `foo.bar`, because `/` comes after `.`). But if you
provide individual sha1s, like this:

    index.add("foo.bar", "content")
    index.add("foo", [some_tree_sha1, "40000"])
    index.write_tree()

we end up sorting the entries in the wrong order. Git
complains (and may provide incorrect answers for diffs,
since we rely on the sort order there).

The fix is fairly straightforward; we already take special
care to use a separate sorting key that includes the "/",
but we missed the case of a sub-tree being named explicitly
by its sha1.

Signed-off-by: Jeff King <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant