On Thu, Feb 20, 2020 at 12:05 PM Adam Milazzo <Adam.Milazzo@xxxxxxxxxxxxx> wrote: > > > Tying permission override to e.g -ffd would be a really bad idea. People would start adopting that for the permission override reason, then someone is going to accidentally nuke a git submodule with unpushed changes. > > Fair enough. I'm not arguing that it must necessarily be any kind of overloading of -f. It could just as well be a separate option. (Personally I'd say overloading -f to make "-f -f" mean "also delete untracked git repositories" was the bad idea, since that is not the obvious and intuitive meaning of "--force", whereas "try harder to delete files you would normally delete" _is_ the intuitive meaning, but the history can't be changed.) Yeah, arguing to change existing behavior (as you started with by labelling the thread with "BUG") will probably get you a lot of pushback, but let me address your new angle of suggesting a new option... > > Also, another way to look at this; currently 'git clean -fd' behaves the same on untracked directories as 'rm -rf' does and I think that's a good model for how to behave. Why should they be different? > > I would ask "why should they be the same?", I think it matches user expectation of how the filesystem works. But if we did want to implement a new flag, there's a question of what it 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. Clearly you don't mean that it should also do a 'reset --hard' -- despite the fact that running a reset fits this definition, but even in terms of untracked files you've still left out the "slippery slope" 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? Can we handle that in any semi-portable fashion? Assuming we do attempt to override ACLs, do we destroy portability of git (I don't know a whole lot about ACLs, so I don't know, but I thought they varied a lot between systems) -- and initiate a never-ending treadmill of needs to handle more kinds of ACLs? If we don't try to overrule ACLs, doesn't that defeat your whole argument that "git clean" (with various levels of forcing) is about trying to do as much as possible to put the repository in a clean state? Ignoring ACLs for a minute, what if we attempt to override the permissions by marking directories as writable, but find out the user isn't the owner of the directory and thus can't change its permissions? Do we try harder by attempting to invoke chmod under sudo to see if we can override the permissions? At 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? > because there's no obvious reason why behavior of "git clean", whose purpose is to put a repository back to a pristine state, should always behave the same way as "rm", whose purpose is to delete a specified set of files, and more to the point there is no reason why they should have no option to behave differently. I am not arguing for the default behavior of "git clean" to change, since that could be seen as a breaking change. Also, they are already different. "git clean" will remove a read-only file. "rm" will not (without confirmation), although "rm -f" will. Here you've changed the goalposts slightly. I didn't compare "git clean" to "rm", I compared "git clean -fd" to "rm -rf" on untracked directories. However, you are right that even those two aren't the same; "rm -rf" will recurse into a git submodule and delete it while "git clean -fd" won't. In other words, "git clean -fd" avoids bringing the repository back to a pristine state in a certain circumstance; it's actually more cautious than rm. 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. Hope that helps, Elijah
