Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 13/13] contrib/subtree: Remove --annotate

From: James Nylen <hidden>
Date: 2016-06-15 22:56:03

On Tue, Feb 5, 2013 at 6:44 AM,  [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
quoted
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` ?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help