Alexander Potashev <aspotashev@xxxxxxxxx> writes: >> * jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit >> + format-patch: show patch text for the root commit > > My testcases ([PATCH] Add new testcases for format-patch root commits) > for this don't satisfy the target behaviour. I thought I squashed the test case from your original to it and they seem to pass for me, but maybe you are talking about some other tests? If you know of breakages please send in incremental updates. >> * ap/clone-into-empty (Fri Jan 9 02:24:23 2009 +0300) 2 commits >> - Use is_pseudo_dir_name everywhere >> - Allow cloning to an existing empty directory > > As far as I understood from your message, you don't think that cloning > into empty directories is necessary. So, I thought, the best solution for > yesterday was "[PATCH] add is_dot_or_dotdot inline function" (to make you > happy ;)). I merely said "I am not particularly interested in it." That's quite different from "I oppose and reject". As long as the new feature is maintainability-wise low-impact and does not hurt users who do _not_ use it, I am not opposed to have a new feature even when I see it is only narrowly useful. If a topic brings in a large change that helps to support only one particular workflow better, while making it cumbersome to update the resulting code to support some other workflow later, even if the change is useful for users of that one particular workflow, I may oppose it. It would be high-impact from the maintainability point of view [*1*]. But I do not think your "clone here" falls into that category. It is really up to you to follow through with it, and people with similar needs to cheer you on. I thought you took a good strategy to first get dot-or-dotdot in (which is generally useful), hoping to bring up the "clone here" topic again by building on top of it later. > Btw, I've sent some worthwhile patches, I but haven't got any reply from you: > [PATCH] use || instead of | in logical expressions > [PATCH] Replace deprecated dashed git commands in usage > [PATCH] remove unnecessary 'if' > It's better if you say "No" than nothing. I do not recall the last one. The first one I thought was a trivial janitor patch that (1) didn't matter very deeply but made things somewhat easier to read, and more importantly (2) you had "oops" reply to yourself. I often clean up trivial "oops" in a patch that fixes bugs or adds features to avoid extra round trip with the contributor, but that is only when bugfix and enhancements are worthwhile by itself. The purpose of a clean-up patch is to clean things up. If it itself has "oops" in it, that fails its own criteria of goodness. Please don't expect/force me to spend time cleaning up "oops" in a clean-up patch, but submit a replacement I can apply straight out of my mailbox. The second one I was expecting to hear from people who were involved in the discussion back when we standardized on dashless form to show hands as I recall these messages were deliberately left with dashed form for some reason (perhaps to help avoiding "man git foo" vs "man git-foo" confusion). [Footnote] *1* Such a change probably needs to be justified either by showing any other workflow does not make sense (so supporting that one true workflow well is sufficient) or by demonstrating that support for some other equally valid workflows can be included trivially, or both. -- 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
