Re: [1.8.0] Remove deprecated commands
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Feb 10, 2011, 20:56 UTC
- Message-ID
- <20110210205620.GD21144@elie>
- In-Reply-To
- <4D543FB4.1040709@lsrfire.ath.cx>
René Scharfe wrote:
> How did you search for current usage? How comprehensive are the results?
By searching for "peek-remote" at http://www.google.com/codesearch
I tried to check out all hits that weren't just enumerating git commands, but that doesn't rule out unindexed or non-public use. No interesting hits.
But that's pretty weird, given that there was no deprecation notice, nor anything else to encourage a transition.
*checks history*
Ah, peek-remote and ls-remote seem to have been introduced at the same time. ls-remote could use all git-supported protocols, while peek-remote could only use git protocol. So very few people had reason to use peek-remote, anyway.
> Am 02.02.2011 01:57, schrieb Jonathan Nieder:
>>> git-repo-config 2008-01-17 git config >> >> giggle[1] still uses it
[...]
>> Likewise darcs2git[2] and the stgit testsuite.
[...]
> Well, the release notes for 1.5.4 promised that the "next feature > release will remove it". Perhaps notifying the developers of the > projects you discovered is enough?
The list is probably not exhaustive. On the bright side, repo-config tends to be run in user-visible contexts, so I think a deprecation notice could be effective.
> That said, the benefit for final removal of this command, which is > effectively just an alias, is the smallest of the four.
After adding a deprecation notice and filing some bugs, I think we can forget about it and wait another year. ;-)
>>> git-tar-tree 2007-11-08 git archive
[...]
Show 8 quoted lines
>> pilgrim[3] uses tar-tree in its "make dist" target. I wouldn't be >> surprised if some other projects use it in a similar way. > > Possibly, and this shows that deprecation warnings don't fully solve > the problem of educating users to switch to the replacements. > > I think it's relatively safe to remove the command anyway because > the users in this case are developers and packagers
I agree. The remaining users look like holdouts that will be hard to get at by other means.