James Nylen <jny...@gmail.com> writes:

> 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:

Sorry, I must have missed that reply.

>  - 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

I can see how that would be useful.

> `--unannotate` is a clunky name, but I think this functionality is
> worth taking another look at.  Maybe it could be called
> `--remove-prefix` ?

Should this really be a function of git-subtree?  It seems like it would
fit better in a history-rewriting command.  Wouldn't rebase -i or even
filter-branch be a better way to do this?

If there's no --annotate I don't see why git-subtree should have the
--unannotate functionality.

Again, I agree that your example is relevant, maybe even common, but I
don't necessarily think git-subtree should be in the business of
rewriting commit messages at all.

I'd appreciate more thoughts from you on this.  I want to make sure we
can support your use case.

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

Reply via email to