Jakub Narebski <jnareb@xxxxxxxxx> writes:
> That is just bikeshedding, but I'd rather not use '@', which currently
> is used only for _reflog_ based revision specifiers: [<ref>]@{<date>},
> [<ref>]@{<n>}, @{-<n>}, for notes which are not reflog based.
Probably a nicer way to say the same thing is to avoid "reflog based"
which sounds like you are talking about an implementation detail.
A fundamental reason to favor your "bikeshedding" (I don't think it is a
bikeshedding---it is a sound argument against using "@{...}") is that the
at-brace notation applies to a ref, not to an arbitrary commit. Applying
@{yesterday} to an arbitrary commit does not make any sense.
Notes are fundamenally metainformation about an _object_ [*1*] and are not
metainformation about refs. Since whatever magic notation to denote notes
we choose wants to be applied to an arbitrary commit, it shouldn't be the
at-brace syntax.
[Footnote]
*1* Yes, I am aware of movements to misuse notes to annotate anything
after mapping it to a random SHA-1 value, but I think that is outside the
scope of notes. Our design decision should be based on supporting the
primary use of annotating an object, and that might still keep such a use
working, in which case that would be an added bonus. But our design
shouldn't be constrained by such a secondary use.
--
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