git-* commands in /usr/libexec/git-core/

[Paul Frields]

On Thu, Jan 8, 2009 at 9:14 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Wed, Jan 07, 2009 at 07:38:03PM -0500, Paul W. Frields wrote:
>>On Wed, Jan 07, 2009 at 08:52:13PM -0300, Horst H. von Brand wrote:
>>> Bryn M. Reeves <bmr at redhat.com> wrote:
>>> > Jeffrey Ollie wrote:
>>> > > On Wed, Jan 7, 2009 at 4:21 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
>>> > >> I guess it depends how much we care about being close to upstream for this.
>>> > >> If it's worth the effort to move these to libexec, then perhaps putting
>>> > >> compatibility symlinks in place for a couple of releases (with a clear
>>> > >> relnote that they will be removed in a future release and scripts need
>>> > >> updating) could be a way to handle the transition?
>>> > > Adding symlinks does nothing to help, it just delays the pain because
>>> > > people won't read the release notes or won't bother to fix their
>>> > > scripts until the symlinks disappear.  Fixing the scripts is trivial,
>>> > > and backwards compatible to boot.
>>>
>>> > No, but having an entry in the release notes for a release or two
>>> > gives something more concrete to point at and say "I told you so" than
>>> > an announcement on the fedora-devel lists which are not read by most
>>> > users (yes, I know that this was announced three years ago upstream,
>>> > but the same comment regarding users not reading things applies).
>>>
>>> It has been announced in git's release notes for more than two years now!
>>
>>I would expect a good number of git users on Fedora don't watch the
>>git upstream.  Putting a note in the F11 release notes is perfectly
>>valid, reasonable, and laudable.
>
> We (the git maintainers) can certainly do that.

Excellent. The Release Notes holding area ("beats"), where the Docs
team drafts content for the next release, haven't been scrubbed yet
but should be shortly. In the meantime, a BZ against Fedora
Documentation, release-notes is a good way to make sure someone sees
this before we're too far down the road.

Paul