Stephen Boyd <bebarino@xxxxxxxxx> writes:
> On Sun, Jan 17, 2010 at 1:04 PM, Johan Herland <johan@xxxxxxxxxxx> wrote:
>> The new --notes option triggers a call to gc_notes(), which removes note
>> objects that reference non-existing objects.
>>
>
> Shouldn't notes be unconditionally garbage collected? Or maybe there's
> a reason why notes should be treated differently that isn't written
> here.
A few thoughts, inspired by this patch, but on other things around
"notes":
- This is more about pruning notes regarding objects that are no longer
availabe from _the tip_ of the notes tree. It doesn't run (and I am
not suggesting to make it it to run) filter-branch to eradicate all
such stale notes from the notes commit ancestry, so in that sense this
is not really a garbage collection.
- We would want to have "notes prune" subcommand that lets us do the
pruning without all the other "gc" operation. "git gc" would of course
call the same underlying code "notes prune" would use if we want to
be able to trigger "notes prune" from it.
- Because there is no public interface to list objects that are annotated
with the most recent notes tree, the only thing this pruning affects is
the look-up overhead of "log --show-notes". As such, it might be
better to later add tree rebalancing in "notes prune" and at that
point, it will become even less about garbage collection and more about
performance ("notes optimize?").
- Do we want to have a public interface to list objects that are
annotated with notes? "git notes" probably deserves a bit more
subcommands other than "(edit|show)" to help users, e.g. "list" and
"remove".
- If this were "notes optimize" (this is just me thinking aloud), perhaps
we would want to do this at some key places (e.g. when you
automatically rebalance the tree).
--
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