Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > What do you think about some patch like that which retains the plumbing > behavior for things like read-tree, doesn't introduce "precious" or > "trashable", and just makes you specify "[checkout|merge|...] --force" > in cases where we'd have clobbering? Whether you like it or not, don't people's automation use tons of invocations of "git merge", "git checkout", etc.? You'd be breaking them by such a change. Other than that, if we never had Git before and do not have to worry about existing users, I'd think it would be a lot closer to the ideal than today's system if "checkout <tree> foo.o" rejected overwriting "foo.o" that is not tracked in the current index but matches an ignore pattern, and required a "--force" option to overwrite it. A user, during a conflict resolution, may say "I want this 'git checkout foo/' to ignore conflicted paths in that directory, so I would give "--force" option to it, but now "--force" also implies that I am willing to clobber ignored paths, which means I cannot use it". I would think that a proper automation needs per-path hint from the user and/or the project, not just a single-size-fits-all --force option, and "unlike all the *.o ignored files that are expendable, this vendor-supplied-object.o is not" is one way to give such a per-path hint. > This would give scripts which relied on our stable plumbing consistent > behavior, while helping users who're using our main porcelain not to > lose data. I could then add a --force option to the likes of read-tree > (on by default), so you could get porcelain-like behavior with > --no-force. At that low level, I suspect that a single size fits all "--force" would work even less well.
