On Tue, May 10, 2011 at 1:53 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Felipe Contreras wrote: > >> v4: more commit message improvements > > Thanks. ÂYou seem to have ignored most of my review; I did not ignore it, I replied to your comments. A review doesn't meant that I should do what you say. > I'll try to find > time to clarify the commit message if the consensus is that this > approach is a good idea. > > An alternative possibility if we need this fixed in the v1.7.5.x > series (do we?) would be cherry-picking the fix from > sg/completion-updates on top of maint. Which cannot be done; you need the rest of the cleanups. Otherwise you would have to make many many intrusive changes. > To clarify the trade-offs: > > Â- in terms of lines of code, the fix itself in sg/completion-updates > Â and this fix are about the same size. ÂBut the sg/completion-updates > Â version relies on a code cleanup. It's not: fc: 1 files changed, 2 insertions(+), 0 deletions(-) sg: 1 files changed, 8 insertions(+), 0 deletions(-) That is if I remove the comments I added; Gabor's version doesn't have any. > Â- the fix in sg/completion-updates is less likely to be broken by > Â future changes in the bashcompinit library. How exactly? > Â- this fix is conceptually simpler. ÂIn a way, the fix in > Â sg/completion-updates only works by accident. You are missing other advantages: - thix fix is less intrusive - this fix would be easier to remove in the future (kind of comes from the previous one) - this fix has been acknowledge by zsh developers - this fix can be applies both on 'maint' and on top of Gabor's reorganization without changes I really don't understand how adding two lines of code that make something from totally broken to working properly can be so difficult. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html