From: James Nylen Date: Mon, 18 Feb 2013 19:46:56 GMT Subject: Re: [PATCH 13/13] contrib/subtree: Remove --annotate Message-ID: In-Reply-To: <87sj4t4gar.fsf@waller.obbligato.org> On Mon, Feb 18, 2013 at 1:39 PM, wrote: > James Nylen writes: >> - 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 > 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? I'm not a git guru by any stretch, so I'm sure there are other ways to accommodate the example use case above. I really just want to be able to split and merge repositories while keeping meaningful commit messages with an appropriate level of detail. Can you suggest an alternative workflow? > If there's no --annotate I don't see why git-subtree should have the > --unannotate functionality. Because they are not inverse operations - they both apply to `git subtree split`. I think that `--annotate` would only be useful as an option to `git subtree merge`. In that case it would be the inverse operation of `git subtree split --unannotate`, and then I would agree that if you remove one, you can/should remove the other. > 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'm willing to accept that. Junio seemed to be leaning that way too in earlier emails. > I'd appreciate more thoughts from you on this. I want to make sure we > can support your use case. I currently need to enable `git subtree` manually anyway, since it's not part of the main distribution. So it's not a burden for me to support this feature with a customized script, or learn a new way to do it. Thanks for your consideration of this small and nit-picky issue.