Re: [PATCH 2/8] Add --unannotate
James Nylen jny...@gmail.com writes: I just now saw these emails. I'm having a hard time thinking of any good use case other than: - add fancylib as a subtree of myprog - commit to myprog repo: fancylib: don't crash as much - split these commits back out to fancylib's main repo, and remove the fancylib: prefix That does seem to me to be the common case, at least. You could potentially have something like Don't crash as much (fancylib) but that's awkward. What might you want to do with a pattern-based rewrite that doesn't involve removing a prefix when splitting commits? I'm not really sure. I've never used --annotate in my own work. In fact, I don't see the use of the original --annotate option at all, since it causes more detailed commit messages in the smaller of the two repositories. I'll have to look back through Avery's logs and see if I can puzzle out why this was added. If it's not useful, perhaps we can remove it before migrating to mainline. Junio, is there a policy for backward-compatability in contrib? I hope that since that directory is for stuff not yet in mainline, there is some room to massage the user interface. -David -- 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
Re: [PATCH 2/8] Add --unannotate
gree...@obbligato.org writes: Junio, is there a policy for backward-compatability in contrib? I hope that since that directory is for stuff not yet in mainline, there is some room to massage the user interface. I do not think there is anything more than we wish there were fewer such end-user facing changes. The purpose of having anything in contrib/ is to give them a way to gain more visibility than they otherwise would as standalone projects on their own. I don't want to control the day-to-day quality issues in them. That is what we have guilty parties for contrib/ subdirectories for, so that they can decide how mature their pieces in contrib/ are and what kind of b/c break is acceptable ;-) Thanks. -- 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
Re: [PATCH 2/8] Add --unannotate
On Tue, Jan 1, 2013 at 5:31 PM, gree...@obbligato.org wrote: Junio C Hamano gits...@pobox.com writes: David A. Greene gree...@obbligato.org writes: From: James Nylen jny...@gmail.com Teach git-subtree about --unannotate. This option strips a prefix from a commit message when doing a subtree split. Hrm. This looks like a workaround for a short-sighted misdesign of the annotate option that only allowed prefixing a fixed string. I have to wonder if it is better to deprecate --annotate and replace it with a more general commit log rewriting facility that can cover both use cases? That's not a bad idea. I'd have to think a bit about a sensible design. Do you have any ideas, James? I just now saw these emails. I'm having a hard time thinking of any good use case other than: - add fancylib as a subtree of myprog - commit to myprog repo: fancylib: don't crash as much - split these commits back out to fancylib's main repo, and remove the fancylib: prefix You could potentially have something like Don't crash as much (fancylib) but that's awkward. What might you want to do with a pattern-based rewrite that doesn't involve removing a prefix when splitting commits? In fact, I don't see the use of the original --annotate option at all, since it causes more detailed commit messages in the smaller of the two repositories. -- 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
Re: [PATCH 2/8] Add --unannotate
Junio C Hamano gits...@pobox.com writes: gree...@obbligato.org writes: In the meantime, will you apply the patch or do you prefer a new design? The --unannotate option will become a baggage you will have to keep working until the end of time, if we applied it. I think it is not too uch a baggage, so it probably is OK. Ok. I think it's worth applying since people find it useful. It's not very complicated. -David -- 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
Re: [PATCH 2/8] Add --unannotate
David A. Greene gree...@obbligato.org writes: From: James Nylen jny...@gmail.com Teach git-subtree about --unannotate. This option strips a prefix from a commit message when doing a subtree split. Hrm. This looks like a workaround for a short-sighted misdesign of the annotate option that only allowed prefixing a fixed string. I have to wonder if it is better to deprecate --annotate and replace it with a more general commit log rewriting facility that can cover both use cases? -- 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
Re: [PATCH 2/8] Add --unannotate
Junio C Hamano gits...@pobox.com writes: David A. Greene gree...@obbligato.org writes: From: James Nylen jny...@gmail.com Teach git-subtree about --unannotate. This option strips a prefix from a commit message when doing a subtree split. Hrm. This looks like a workaround for a short-sighted misdesign of the annotate option that only allowed prefixing a fixed string. I have to wonder if it is better to deprecate --annotate and replace it with a more general commit log rewriting facility that can cover both use cases? That's not a bad idea. I'd have to think a bit about a sensible design. Do you have any ideas, James? In the meantime, will you apply the patch or do you prefer a new design? -David -- 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
Re: [PATCH 2/8] Add --unannotate
gree...@obbligato.org writes: In the meantime, will you apply the patch or do you prefer a new design? The --unannotate option will become a baggage you will have to keep working until the end of time, if we applied it. I think it is not too uch a baggage, so it probably is OK. -- 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
