On Tue, May 14, 2013 at 5:49 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> The reason for the "only regression" period is to avoid more >> regressions. If you show me how any of the fixes I sent in this series >> could potentially cause a regression, > > I already said that "You can see these patches are so trivially > correct" is not a valid argument. You can say so, it doesn't make it so. > The original patches would also > have been looked correct when they were sent to the list. No, they didn't look correct, and I made it clear when I sent the patches to be *tested*. > Things > take time and actual use by the users to mature. Some things, not all things. That's a hasty generalization fallacy. >>> You cannot be both. Which is it? >> >> I marked the patch that fix a regression as such, I marked the patches >> that are obvious fixes with no possibility of regressions as such, and >> I marked the trivial cleanups with no possibility of regressions as >> such. > > I think you mean 6/10 by "the patch that fix a regression", but if > that is the case, please send only the regression fix that cleanly > apply to the tip of 'master', without any other dependencies, with a > proper description of what breaks and how it fixes. I did that for v2, but you didn't merge that. > We know you can do better than "certain" and "might". > >> In certain situations we might end up pushing garbage revisions (e.g. in >> a rebase), and the patches to deal with that haven't been merged yet. >> >> So let's disable forced pushes by default. I have done more than enough. I'm not going to write tests for this, and I'm not going to find out for sure. There is a *potential* that there's a regression, and that's reason enough to apply this patch as it is. I have done way more than my fair share already. I'm 98% certain that this patch series as it is would not introduce a regression for v1.8.3, and that's good enough for me. If anybody has any problem with that, they can pick this series and do whatever they want with them. If I'm supposed to be the owner of contrib/remote-helpers, it certainly doesn't feel that way. If I am the owner, but you are worried, why don't you let me make the decision, and if something blows in v1.8.3, you can tell me; "see? you are not ready to have the full maintainership of this". After all, this is in the contrib area, so if there's a time for a possible future maintainer of a core part of git to make mistakes, it would be now. But of course, this would *not* happen, because the patches are obviously correct and I stand by that claim. As things currently stand, v1.8.3 *might* introduce a regression. -- 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