On Tue, Feb 5, 2013 at 6:44 AM, <gree...@obbligato.org> wrote:
> Junio C Hamano <gits...@pobox.com> writes:
>>> Remove --annotate. This obviates the need for an --unannotate
>>> command. We really want a more generalized commit message rewrite
>> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html