On Wed, Nov 26, 2014 at 11:25:53AM +0900, Mike Hommey wrote:
> Now, looking at the notes tree reflog, I see that at some point, some
> notes were added at the top-level of the tree, without being nested,
> which is strange.
That's somewhat expected. The fanout is dynamic based on the number of
notes, so early on I think some notes may be found at the top of the tree.
> And it looks like it's related to how I've been adding them, through
> git-fast-import. I was using notemodify commands, and was using the
> filemodify command to load the previous notes tree instead of using the
> from command because I don't care about keeping the notes history.
> So fast-import was actually filling the notes tree as if it were
> starting over with whatever new notes were added with notemodify (which,
> in a case where there were many, it filled with one level of
> indirection)
Ah, that sort of makes sense. This confused the code to adjust the
fanout, because we track "number of notes" independently of "number of
files" (even though they are really the same thing in a notes tree).
> I'm not sure this is a case worth fixing in fast-import. I can easily
> work around it.
Yeah. Probably fast-import could be smarter here, but I think ultimately
it makes sense to stick to using the note commands. I think what you
want is a version of "from" that takes an existing tree (and number of
notes!) from a commit, but does not add it as a parent. AFAIK,
fast-import doesn't have a way to do that.
Probably the simplest thing is to build it with history via fast-import,
and then just truncate the history at the end with:
commit=$(echo "final notes tree" | git commit-tree refs/notes/foo^{tree})
git update-ref refs/notes/foo $commit
-Peff
--
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