"Theodore Ts'o" <tytso@xxxxxxx> writes: > On Sat, Nov 11, 2023 at 10:31:54AM +0900, Junio C Hamano wrote: >> ... >> I wonder if it would help users to add a new configuration option >> for those who want to live safer that tells "commit -a" to leave >> unmerged paths alone and require the unmerged paths to be added >> explicitly (which may have to extend to cover things like "add -u" >> and "add ."). >> >> Perhaps not. I often find myself doing "git add -u" after resolving >> conflicts and re-reading the result, without an explicit pathspec. > > Maybe the configuration option would also forbit "git add -u" from > adding diffs with conflict markers unless --force is added? Historically we left it to pre-commit hooks, but I agree that protection at the time of "git add" may be more helpful. I also alluded to being careful about "git add" with an overly vague pathspec (like "." to add everything addable under the sun), but I do not think it is possible to define "overly vague" in a way that satisfies everybody (would "git add \*.h" be still overly vague when 5% of your header files have conflicts in the merge you are concluding?) and keep the new users safe. Unless the configuration forbids patterns and say "each and every individual path must be named to add and resolve conflicted paths", that is. Come to think of it, that may not be too bad. > I dunno. I personally wouldn't use it myself, because I've always > made a point of running "git diff", or "git status", and almost > always, a command like "make -j16 && make -j16 check" (or an aliased > equivalent) before commiting a merge. > > But that's because I'm a paranoid s.o.b. and in my long career, I've > learned is that "you can't be paranoid enough", and "hope is not a > strategy". :-) Being careful and paranoid is good ;-) I wouldn't use it myself, either, but the discussion started while trying to allay new users' worries about recording a half-resolved state by mistake, and in that context, I think it would have non-empty audiences. Thanks.
