Re: [PATCH 13/13] contrib/subtree: Remove --annotate
- From
James Nylen <jnylen@gmail.com>
- Date
- Feb 5, 2013, 13:27 UTC
- Message-ID
- <CABVa4NiyVksEn4+NqBPXpaWGYnP6FeUqeacLOnAOHtw9FgMJdA@mail.gmail.com>
- In-Reply-To
- <87pq0frnmb.fsf@waller.obbligato.org>
On Tue, Feb 5, 2013 at 6:44 AM, <greened@obbligato.org> wrote:
Show 14 quoted lines
> Junio C Hamano <gitster@pobox.com> writes: > >>> Remove --annotate. This obviates the need for an --unannotate >>> command. We really want a more generalized commit message rewrite >>> mechanism. >> >> That may be a good goal as the end result, but wouldn't it be a bit >> unhelpful to remove these before adding such a "more generalized" >> mechanism to replace them? > > I did think about that. I sent out an e-mail some time ago asking for > opinions on this. No one responded. Since this is in contrib/ I feel > comfortable getting rid of this option early so that people don't get > too attached to it. :)
I don't agree that removing `--annotate` obviates the need for `--unannotate`.
I responded on 1/17 with what I think is a typical and normal use case for that option:
- add "fancylib" as a subtree of "myprog" - commit to "myprog" repo: "fancylib: don't crash as much" - split these commits back out to "fancylib" main repo, and remove the "fancylib: " prefix
In my opinion this is a pretty normal workflow. Commits to "fancylib" in the "myprog" repo are prefixed with "fancylib: ", and that prefix becomes redundant and should be removed if those commits are split back out into the "fancylib" main repo.
I also tried to come up with another situation that would justify a more general commit message rewriting facility, and I couldn't think of any other good use cases that don't involve removing a prefix. But that doesn't mean there aren't any.
`--unannotate` is a clunky name, but I think this functionality is worth taking another look at. Maybe it could be called `--remove-prefix` ?