A few follow ups. On 31/10/2021 17:57, skybuck2000 wrote: > > > the Git repo built. At least it gives a better overview, though the > diffs can be terrible. > > > Why were the diffs terribles to many code changes all at once ?
Terrible in the sense that it was "all the code changes at once", refactoring, wholesale code moves, concept changes, the lot. The diffs were 'correct' but not really that helpful. The value of Git (when used well) is that you can see the fine grained change management, though it can be hard to teach folk how to write good commits - the Git project itself is quite good at that. > > Git is especially good in collaborative work, without some top knob > being in 'control'. The hash is simple and unique and avoids all the > coordination issues. > > > This is a good point you make while not 100% theoretically correct > there is a small chance of hash conflict, but in principle I can see > how each hash in the world might be unique ?! ;) > > Though one could consider this a matter of principle, do I really want > to base collaborative work based on "luck" getting a unique hash by > luck ? hmmm... Folk get all antsy about the theoretical possibility - memory corruption by cosmic rays is more common! Just saying ;-) Also the Git sha1 protection (because of blob format) is still unbroken, despite the careful breakage of the pdf format > > What could be the risk of basing it on a hash conflict ? Hmmm has this > ever happend to the Linux Kernel :) ?! =D It's not even happened across *all* the hashes at Github & Microsoft. Still rarer than hen's teeth. > > > > version numbers in file names are not that usefull for application > code, there are however very usefull for shared code between > applications, so that applications can always be build against exact > version numbers. > > > This is what worries me the most for GIT, it's not suited for > shared > files between applications, updating code in a "working folder" > would be > horrible and break every application that ever used it, here > versioning > in folder names and file names is far superior to always be able to > build ANYTHING at ANYTIME. > > This is a 'mental model' misunderstanding. It is a 'kit of parts / > parts > catalog' viewpoint (home built vehicle), while Git's primary view is > that of 'the project' (compare to having a make/model of a car). > > > Isn't this the same thing, software is build up out of modules=parts. It's the direction of choice that matters. The super project choses it's libs, rather than libs forcing super-project changes. You chose the wheels for the car, not the car for the wheels (e.g. the "must be gold plated" toilets in aerospace) > > > In Git you would designate each of the resuable folder/files as a > sub-module, which can then be integrated when/wherever it's needed > by a > major project. The (supra-)project choses the version that is used. > > > OK, point taken, so you are "saying" shared libraries and such should > have a submodule. > This is where it gets a bit hairy, this kinda implies and means GIT > has to be "applied" to libraries that I may not want to work on at > all, libraries from other people. > But I still have to GIT-ti-FY them. > > Now one could argue, wait a moment Skybuck, if you don't work on them > then you don't have to GIT-ti-FU them but here lies a bit of the > danger... In the future I might discover a bug or problem or a desire > to modify a library and then BAM/BINGO... now this introduces a BIG > problem, because so far, let's suppose version information was missing > in GIT then GIT at this point has no idea of what library was being > used. So to solve this problem I would have to add a SUB MODULE before > making any changes to the library and then it becomes QUESTIONABLE if > previous GIT commits can understand what SUBMODULE/hash was supposed > to be used ? Consider this a serious question: > > What happens to previous commits if a SUBMODULE is later introduced ? > Here it gets very fuzy. > > Bye for now, > Skybuck. > -- > You received this message because you are subscribed to the Google > Groups "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/git-users/210ad64a-783e-4a64-a6dd-a88b5f73f6dfn%40googlegroups.com > <https://groups.google.com/d/msgid/git-users/210ad64a-783e-4a64-a6dd-a88b5f73f6dfn%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/3d98bcfb-fd8f-539f-33ce-4680dbd4c95f%40iee.email.
