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 ? 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... What could be the risk of basing it on a hash conflict ? Hmmm has this ever happend to the Linux Kernel :) ?! =D > > 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. > 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 git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/210ad64a-783e-4a64-a6dd-a88b5f73f6dfn%40googlegroups.com.
