Jeff King [off-list ref] writes:
I think people have provided sane techniques for doing this with a
pipeline. But there is really no reason not to have --grep-notes, just
as we have --grep. It's simply that nobody has implemented it yet (and
nobody is working on it as far as I know). It would actually be a fairly
simple feature to add if somebody wanted to get their feet wet with git.
I agree that the implementation will be simple once you figure out
what the sensible semantics and external interfaces are. The latter
is not that simple and certainly not something for newbies to solve
on their own. That is why I didn't mention it.
But now you brought it up, here are a few thinking-points as a
starter:
- Wouldn't it be more intuitive to just let the normal "--grep" to
also hit what "--show-notes" would add to the output? Does it
really add value to the end user experience to add a separate
"--grep-notes=P4[0-9]*" option, even though it would give you
more flexibility?
Not having thought things through thorouly, I still answer this
question both ways myself and what the right user experience
should look like.
- Do we want to be limited to one notes tree? Would it make sense
to show notes from the usual commit notes but use different notes
tree for the sole purpose of restricting visibility? If we
wanted to allow that for people who want flexibility, but still
want to use only one and the same by default, what should the
command line options look like?
- Would it be common to say "I want commits with _any_ notes from
this notes tree"? Having to say "--grep-notes=." for such a
simple task, if it is common, feels a bit clunky.
Junio C Hamano venit, vidit, dixit 22.09.2012 01:51:
Jeff King [off-list ref] writes:
quoted
I think people have provided sane techniques for doing this with a
pipeline. But there is really no reason not to have --grep-notes, just
as we have --grep. It's simply that nobody has implemented it yet (and
nobody is working on it as far as I know). It would actually be a fairly
simple feature to add if somebody wanted to get their feet wet with git.
I agree that the implementation will be simple once you figure out
what the sensible semantics and external interfaces are. The latter
is not that simple and certainly not something for newbies to solve
on their own. That is why I didn't mention it.
But now you brought it up, here are a few thinking-points as a
starter:
- Wouldn't it be more intuitive to just let the normal "--grep" to
also hit what "--show-notes" would add to the output? Does it
really add value to the end user experience to add a separate
"--grep-notes=P4[0-9]*" option, even though it would give you
more flexibility?
Not having thought things through thorouly, I still answer this
question both ways myself and what the right user experience
should look like.
- Do we want to be limited to one notes tree? Would it make sense
to show notes from the usual commit notes but use different notes
tree for the sole purpose of restricting visibility? If we
wanted to allow that for people who want flexibility, but still
want to use only one and the same by default, what should the
command line options look like?
- Would it be common to say "I want commits with _any_ notes from
this notes tree"? Having to say "--grep-notes=." for such a
simple task, if it is common, feels a bit clunky.
On my mental scratch pad (yeah, that's where the bald spots are) I have
the following more general idea to enhance the revision parser:
--limit-run=<script>::
--run=<script>:::
These options run the script `<script>` on each revision that is walked.
The script is run in an environment which has the variables
`GIT_<SPECIFIER>` exported, where `<SPECIFIER>` is any of the specifiers
for the `--format` option in the long format (the same as for 'git
for-each-ref').
In the case of `--limit-run`, the return code of `<script>` decides
whether the commit is processed further (i.e. shown using the format in
effect) or ignored.
So far the idea. We could also squash both the limitting and the
formatting option into one run option. Typical usecase could be
git log --limit-run='sh -c "test x$GIT_NOTE = xp@myid'
or the like. We could also feed <script> to a shell directly. We could
also make the limit option stop traversal (optionally). Just a scratch
pad, rwally ;)
Michael
P.S.: option name bike shedders: it's named after bisects's "run"; we
could name it after rebase-i's "exec" instead...