Elijah Newren <newren@xxxxxxxxx> writes: > should be and what it should do. Your "put the repository back to a > pristine state" isn't enough to really go on from an implementation. Yeah, where does this "pristine state" come from? Do we need to fix the "git clean" documentation to reduce such a confusion (I didn't check to see if the current text is prone to be misunderstood as such yet). "git clean" is to remove crufts, isn't it? The definition of "cruft" being untracked junk that are marked expendable (aka "ignored")? And it is not "remove crurfts no matter what". > angle from my previous response in what you've addressed here. Let's > say we did implement a new flag that said we should override standard > permissions. In such a case, shouldn't ACLs also be overridden? ... > what point do we give up? What's the clear line...and why does that > line not just get drawn at not changing permissions at all? Yup. Elsewhere in the thread you gave "rm -fr" not removing an unwritable subdirectory, and that shows where others before us drew the line that has been accepted by the end users. > I'm sympathetic to "golang does a dumb thing I don't like" (the exact > situation you hilight has bothered me before too), but it's not clear > at all to me where or how git might help you cope with that. To me, > golang did a dumb and you have to manually undo the dumb. If you want > something smarter on the git side instead of the golang side, all the > stuff I mentioned above are things that would need to be addressed in > any possible solution that I'm just not seeing. Amen.
