> I see your point about adding confusion for new users, and I
> agree. However, please note that commands are not just for new
> users. Veteran users that are not bzr developers are also worthy
> of being catered to by bzr...
Right, that's exactly where *I* (the feeling may be shared or not, I
never asked) have some hesitations about revealing them: they tend to be
lest tested and are certainly not supported as the other commands. If an
implementation change break them, we may just decide to delete them.
> Also, when you say these commands are fo debugging, you probably
> mean that this is how they cam into existence.
Mostly, AFAIK.
> While that is probably true, I would argue that once they do
> exist, their fate should be decided by their utility for mere
> mortals, not by the historical curiosities.
This is open to debate indeed,
> Now for the specific points you made.
> Commands slated for deletion of course don't need to be
> documented.
As said above, we may change our mind faster on the hidden commands...
> Merging this hidden functionality with existing non-hidden
> commands is also an okay solution.
As jelmer mentioned, this is really what we want to do for 'added' and
such: enhance ls so they become useless.
> lookup-revision
1 test, but the code is trivial too.
> and revision-info
Better coverage but tested only against the default format. Ad-hoc, but
may fail with older formats without notice (though if it fail, that
would probably be for a new format and may be fixed for all formats at
that point).
It's also ~designed to accept a revision not in the branch ancestry
> are handy for showing revision-id given a revno and vice versa. I
> don't see how "revno" or "version-info" can help here, except for
> the current tip revision. Am I missing something?
You're right.
Firing 'bzr log' is not an alternative either :)
> Likewise for find-merge-base and file-id: what other commands can
> show this information? I agree that this info is probably needed
> only rarely, but what's wrong with advertising rarely used
> commands?
Now, showing them if some config option (bzr.help.show_hidden ?) is set
(once and for all) in bazaar.conf (and stay off by default for
newcomers)... I don't see why we shouldn't show them.
>>>>> Eli Zaretskii writes:
> I see your point about adding confusion for new users, and I
> agree. However, please note that commands are not just for new
> users. Veteran users that are not bzr developers are also worthy
> of being catered to by bzr...
Right, that's exactly where *I* (the feeling may be shared or not, I
never asked) have some hesitations about revealing them: they tend to be
lest tested and are certainly not supported as the other commands. If an
implementation change break them, we may just decide to delete them.
> Also, when you say these commands are fo debugging, you probably
> mean that this is how they cam into existence.
Mostly, AFAIK.
> While that is probably true, I would argue that once they do
> exist, their fate should be decided by their utility for mere
> mortals, not by the historical curiosities.
This is open to debate indeed,
> Now for the specific points you made.
> Commands slated for deletion of course don't need to be
> documented.
As said above, we may change our mind faster on the hidden commands...
> Merging this hidden functionality with existing non-hidden
> commands is also an okay solution.
As jelmer mentioned, this is really what we want to do for 'added' and
such: enhance ls so they become useless.
> lookup-revision
1 test, but the code is trivial too.
> and revision-info
Better coverage but tested only against the default format. Ad-hoc, but
may fail with older formats without notice (though if it fail, that
would probably be for a new format and may be fixed for all formats at
that point).
It's also ~designed to accept a revision not in the branch ancestry
> are handy for showing revision-id given a revno and vice versa. I
> don't see how "revno" or "version-info" can help here, except for
> the current tip revision. Am I missing something?
You're right.
Firing 'bzr log' is not an alternative either :)
> Likewise for find-merge-base and file-id: what other commands can
> show this information? I agree that this info is probably needed
> only rarely, but what's wrong with advertising rarely used
> commands?
Now, showing them if some config option (bzr.help. show_hidden ?) is set
(once and for all) in bazaar.conf (and stay off by default for
newcomers)... I don't see why we shouldn't show them.