On Sat, Jul 10 2021, grizlyk wrote: > hi > >> On Sat, Jun 05 2021 >> It's way too common of a pattern to e.g. have a *.o file made from a >> corresponding *.[ch] file(s) in the same directory. > > The patterns were common for old times (before VCSes was involved). To > deal with temporary files (like .o), generic OS tools like "make > remove_compiled" can help to clean directory before stage. To keep > derivative persistent files (like the same .o) separated directory can > be used. It's still a very common pattern, e.g. the project whose ML you're posting to uses it, anecdotally most free software C or C-like projects I look at / work on use it. In any case, git as a project can't say "you should fix your code". This VCS has to deal with the real world, people do use this pattern in the wild, and we can't willy-nilly eat their data. It's not a good approach to advocate a change in git behavior to say "people should do X, not Y, to avoid this problem", when a cursory look at real-world use reveals that "X" is in wide use, and unless you did "Y" a proposed change in behavior would be detrimental to your use of git. What is more productive is to either find out how we can support both without harming the other, or make new behavior opt-in, hence the thread(s) I linked to about "precious" etc. >> git already does a good job of supporting it. > > Sure, the light message: "There are ignored files (%u<number of > files>) not placed into repo.\n\t(use git status --ignored to view)"; > will improve the activity. Otherwise some files somethimes will not be > placed into repo unexpectedly for user. > >> You'd e.g. compile all your >> assets outside of the repo via your build system, and just not have >> anything in .gitignore. > > Do you suggest to copy desired src files into separated repo directory > (the repo directory placed under VCS control) by generic OS tools > (i.e. by cp command) and stage the separated directory? I'm not really being serious here, as should be clear from the linked threads I think the current behavior has sucky edge cases and does eat people's data in some cases, that's bad, the problem is finding a way to change it that doesn't cause badness for other use-cases. I am saying that if your proposed "Y" solution is effectively "other people should mostly/entirely rewrite their build systems to deal with a new default I'm proposing", then in this case you'd also approximately what you wou want if we keep the current behavior and you rewrite your build system(s), no? Anyway, maybe I misunderstood some of what you're saying...
