There remains one big problem with this idea. By using git all version information is basically lost and all the effort I put into version folders and version files is lost and my users of my fork would not benefit from versioning at all.
For them it would be "all" or "nothing". Unless they start versioning their copies of the fork themselfes, this could lead to "wild" grow of all kinds of different version numbers based on their own copies. One possible solution is to add tags and release/version numbers, but again lots of work, overhead and it doesn't version everything, only when a tag is applied. I am a strong believer in that everything should be versioned at all times and it should be crystal clear against what version is being coded, or what version of a file/folder is included in a build... Hmmm... That would leave only one possibility: "upload all or most or desired" version folders. However GIT does not seem to like this much ? Is it possible to "instruct" GIT to do it's thing based on version folders ? That would be somewhat cool ! Bye, Skybuck. On Sunday, October 31, 2021 at 6:14:40 AM UTC+1 skybuck2000 wrote: > > My own versioning system is very simple and used for solo development > 99.99999%. > > I will give an example of how this works. > > The main thing is "folders", "version number in folders" and "comments in > folders". > > For example, let's suppose I want to test an algorithm called "Jack". > > I would create a folder like so: > > C:\Source Code\Tests\Test Jack\version 0.01 original code\ > > Then I would make a copy of that code: > > C:\Source Code\Tests\Test Jack\version 0.02 modify it\ > > Now I can start making save modifications. > > Perhaps I will get an idea how to improve it with some new algorithmic > parts: > > C:\Source Code\Tests\Test Jack\version 0.03 and new algorithm to it\ > > Perhaps I then want to do an optimization sessions > > C:\Source Code\Tests\Test Jack\version 0.04 optimize it\ > > Perhaps then I may want to restructure it: > > C:\Source Code\Tests\Test Jack\version 0.05 restructure\ > > Then I discover/decide the re-structuring failed and I want to skip that > version. > > I rename it: > > C:\Source Code\Tests\Test Jack\version 0.05 restructure (failed, skip this > one)\ > > Then I want to finally clean up some code/comments for sharing with others > or stablize it > > C:\Source Code\Tests\Test Jack\version 0.06 based on version 0.04 clean up > code\ > > Then perhaps I want to make some last small changes/adjustments settings > for a release version. > > C:\Source Code\Tests\Test Jack\version 0.07 release it\ > > Finally I might want to share/incoorporate it into a git release/commit. > > This is where it gets a bit hairy. I could create a git init inside that > release folder, but as soon as I copy that folder, it copies the whole git > database, possibly leading to lost of wasted harddisk space and it doesn't > make much sense. > > Further more this copieing of folders has some benefits compared to git: > 1. more redundancy. > 2. quick access to different versions, code copieing possibilities. > 3. easy to see sense of progression. > 4. all files in a version belong together. > 5. easy to make copies and make changes > 6. any change is automatically saved without requiring any commits. > 7. I can copy from any version without having to cancel any unstaged > changes. > 8. I can even work on multiple versions at the same time, example: > > C:\Source Code\Tests\Test Jack\version 0.08a idea 1\ > C:\Source Code\Tests\Test Jack\version 0.08b idea 2\ > C:\Source Code\Tests\Test Jack\version 0.08c idea 3\ > > So for slight branching git does not really offer any benefit and this can > be done fine with windows explorer and ntfs folder structures also > incredibly fast. > > However comparing versions and detecting differences might become a bit > more complex, this is where git and other tools have some value. > > I could even sub version those folders or any folder and make a sub > version and move code around, example: > > C:\Source Code\Tests\Test Jack\version 0.09\sub version 0.01 test > something > C:\Source Code\Tests\Test Jack\version 0.09\sub version 0.02 test > different something > C:\Source Code\Tests\Test Jack\version 0.09\sub version 0.03 test > alternate something > > I could then select one or copy code from multiple sub versions to produce > final new version > > C:\Source Code\Tests\Test Jack\version 0.10 merged version mostly based on > version 0.02\ > > So basically the possibilities are endless. > > A second versioning system is also in place, versioning files themselfes > in case I only want to change files and not folders, this gets a bit messy > and can run out of sync but it can be convenient, example: > > C:\Source Code\Tests\Test Jack\version 0.11\unit_main_version_011.pas > C:\Source Code\Tests\Test Jack\version 0.11\unit_algo_version_011.pas > C:\Source Code\Tests\Test Jack\version 0.11\unit_helper_version_011.pas > C:\Source Code\Tests\Test Jack\version 0.11\unit_helper_version_012.pas > C:\Source Code\Tests\Test Jack\version 0.11\unit_helper_version_013.pas > > This way I can quickly try out different helper versions without copieing > the entire folder and without re-naming all versions in all these files. > > 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. > > No check outs needed, not digging into commit hashes, etc, it's almost > funny to think how some people, git users or windows manage to do this at > all, some might use some kind of version field inside > binaries/executables/dlls, but that is after the dead, after everything is > build, this may be for binary compatibility. What I wrote above is about > source capability where everything is build into a single binary. > > Anyway I hope to have convinced you somewhat that GIT is not ideal for me, > it's risky if something bad happens to it's database, it's cumbersome to > use, it's slow for that reason, lot's of overhead. So far I have used GIT > mostly with git commands, I know there is a GUI but then I feel more > disconnected, for now it makes more sense to work like I was working in > ms-dos to get more a feel for it. > > Problem with GIT gui approach is that git gui might change over time as > many guis do and that idea seems horrible to me, unless there are some big > benefits, I also do not want to be dependent on some non-windows gui for > software development. > > So why use GIT at all, there must be some benefits ? and just I do see > some benefits: > > Let's start with the main one, most likely: > > 1. Big Open Soure Linux Operating System, here making simple copies would > fill up harddisks very quickly, so I can understand only storing > "differences". > > For me personally I couldn't care less about storage space as long as it > does not get out of hand, as long as executables and other large files are > ignored, this is not a benefit of GIT for me, on the contrary this I > consider a big fat risk. What if sector damage occurs or other fuck ups > happen ?!? > > Other true/real benefits are/could be: > > 2. Automatic uploading/sharing of files towards github so others can see > my code more usually, better formatted and can download it faster. THIS IS > A BIG BENEFIT of GIT. > > 3. Automatic downloading/sharing of other peoples files and benefitting > from that, looking at what they have done. VERY BIG BENEFIT OF GIT. > > 4. Difference engine, detecting differences between their code and my code. > > 5. Possibly point 4 supported by "flows", "work flows", "branches", > "master branch", "local branch", "my copy" and so forth. > > The idea of having multiple branches inside the GIT database, multiple > flows of code, comparing flows against each other this is very interesting ! > > 6. Especially multiple remotes ! Very interesting to follow development > efforst of multiple people. > > 7. Integration into a main/master branch, also very interesting to get > some code consistency for multiple people/different versions, trying to > set/create one master version. > > 8. Github insight and github time lines and github forks, insight into > parallel/other development efforst of other users/programmers and so forth. > > 9. Pull requests on github also interesting, offers a discussion board an > can be accepted or denied. > > 10. Following people's code changes or contributions through github web > interface, also very interesting. > > So there are some clear benefits to using GIT, mostly for "multi-user" / > "multi-programmer/developer" projects. > > What I don't like about git is lack of version numbers in folders and > files but I can do that myself as described above. > > I have seen one project so far that adds/uses "tags" to add some > release/main version numbers to certain commits. The lack of > "absolute/total" version numbers for every commit is concerning to me, I > don't really like this, it feels a bit messy. > > A commit can basically be based on any code version or any branch. I want > to be sure on what code version it was based and from what branch it came, > this information is somewhat missing when looking at an individual commit. > > There is some information for this, like log graph and following the > lines. However following the lines/graph can be very hard especially in dos > mode/bash mode it can get confusing very fast. This is why I like version > numbers and sub version numbers better, this may help at determining what > is truely going on. > > Perhaps an official numbering scheme like so might be based: > > version 0.20 based on version 0.13 > > In case it was based on a different branch. This is very important > information for me to know what code it was based on and what code might be > missing. > > The shorter version: > > 0.20.0.13 would not be sufficient information, this would be very > confusing: > > Does this mean it's a sub version based on 0.20 ? > > So this is what I don't like about other versioning systems that don't > clearly indicate what code a version was based on. > > Anyway github does give some further information from which branches code > came from by clicking on commit hashes... > > Sometimes there is commit hash a + commit hash b and then both can be > followed, it's not ideal and can still lead to some confusion, where the > hell am I if I click A or B ? and so forth... again lack of information > what branches and versions these commits came from, difficult to tell/spot. > > Anyway I want to try and integrate/benefit from GIT by trying to > integrate/incorporate it into my own versioning system so that I can do two > things: > > 1. Continue working with my own versioning system for very fast code > development when developing solo. > > 2. Benefit/use git to try and work/colloborate with others on some of my > versions or theirs but not all. > > It may not be necessary for others to follow all my versions, version > numbers and attempts. > > I want to be more in control of what I share and what I don't share. This > also makes more sense. > > GIT is more focused on sharing quality/working code and integrating code > and less on experimental/broken/flawed/buggy code. > > For me the main purpose of a versioning system is to be "idiot proof", > "fuck up proof", "bad day proof", "had a bad night sleep prove", "the > universe was against me lol" proof anything. > > Basically I consider 90 to 99,9% of people on this planet idiots are > inperfect to say it mildly. > > If I was perfect/a god. I would not need a versioning system and I could > apply all my changes/patches perfectly. But this is ofcourse never the case. > > Other benefits of versioning are historic reasons, looking at who code > came to be, and another important one is sense of achievement. > > My versioning system allows me to quickly fall back to previous versions > in case the current versiong totally fucked up, if it's really bad I might > even delete the current version, but many times I also want to keep my fuck > ups as a reminder that it was a bad idea or something fucked up, or I > should not go that route, it also allows me to salvage any code from it > that might still be usefull. > > However commiting fuck ups, bad code feels weird in GIT so I don't like > doing that. I could maybe store in on seperate branches but this would > create unnecessary branches and most likely a lot of confusion. > > It could be funny though if there were some "fucked up branch tags" or > maybe even a main fuckup branch, however merging would ofcourse most likely > be horrible and take a lot of time so completely crazy idea. However > searching the git database for "fucked up" tags could/would be funny. But I > am not in the bussiness of having fun with my code ike that, searching for > funny fuck ups, I don't have that need or desire so it's mostly completely > useless and it's just there as a warning sign "don't go there" and "skip > it". > > Anyway as I tried to explain above there could be some value in applieing > certain worked out more valuable pieces of code towards a git database. > > That way "my" "users" of my github repository and their forks of my fork > will get to see some quality code that might benefit them. > > The downside to this is they don't get to help me with fucked up or broken > or buggy code, but I can also decide to release that as well ofcourse > perhaps on a special seperate buggy or "need help" branch whatever. That > could be cool. > > What I would further like to do is keep the GIT databases completely > seperate and outside of my main code folders, test folders, library > folders, unit folders, etc. > > I don't like the idea of a somewhat hidden or mysterious .git folder > somewhere somewhere in between my code folders. > > My code folders are mostly for code, perhaps some binaries and that is it, > a versioning system or a database of a versioning system does not belong > there. Consider it messy, or garbage :) or overhead. Non-senseable, > non-intelligentable, unreadable files = git database ?! > > However I would like to give git databases a special place inside my main > Source Code folder perhaps as a special sub folder for example: > > Source Code\Git Databases > > Below that I could then create git databases for those > files/folders/projects/units/libraries etc that I am interested in sharing > or collaborating on. > > I do see some general problems with GIT which I will first discuss because > I don't quite like it and sometimes I do it feels kinda wrong and sometimes > right it's a bit weird. > > I could create a single git database for all of my code, but this would > probably be completely insane... the number of commits would be in the > millions potentially or hundreds of thousands... without any filtering that > would drive anybody crazy looking at the log etc. > > For me personally it would actually be kinda funny then I can see what > kind of work I have done in the past, but why would I want to see it in > such excruciating detail ? That would only make sense if somebody has to > pay me per work done or hour or something. > > Second the filtering itself would get annoying, all kinds of special > commands needed to isolate the log of a certain project, there is the risk > that these commands might miss certain changes or files, perhaps they are > somewhere else in some different folder or something. I can imagine this > becoming a risk. > > Then there is the opposite approach, let's look at this from an extreme > perspective. > > A git repository per folder. This is immediately where GIT gets weird and > becomes a problem, what does that mean per folder ? The weird thing and > sometimes good thing about GIt is it also versions the SUBFOLDERS ??!?! so > it's never really just one folder, it's feels more like a project database, > it automatically incorporates sub folders. > > This might not alway be desireable and this might become a problem, it > might be desireable to have seperate git databases for sub folders, to work > individually/in isolation on those sub folders for efficiency and not > clobbering reasons and thus also efficiency reasons not having to deal with > commits from other sub folders or main folder. > > I have seen that git has something called submodules, though this seems to > be more aimed at using shared code/libraries I am not sure if git modules > could be used to maintain sub folders exclusively inside those sub modules. > > After all is said and done I am sure git has a whole bunch of > options/commands and parameters to do all kinds of things but this is where > GIT kinda lacks/back fires and becomes cumbersome and overheadish to use > and possibly error prone and dangerous a few typos here and there and ouch ! > > Though git shows some promise and potential, it will need more work to > make it more user friendly, increase the ammount of simply commands, like > git switch, instead of parameterized commands like git checkout -b bla and > so forth. Smaller commands with less parameters are less error prone. > > Another dislike of mine against GIT is the order of parameters. If there > is only one parameter then it's simply and easy to remember as soon as > there are multiple parameters it gets confusing and dangerous for example > is it: > > git add remote > or is it > git remote add > > Plus the help is kinda lacking in this regards, clearly stating the order > or recognizing when commanders/parameters were issued/stated in the wrong > order. This is definetly where GIT could use some more work and a better > helper system to help the user in recognizing wrong order of parameters and > suggestion correct order and such and giving perhaps one example. > > Sometimes GIT does give good help and suggestions so it's not all bad or > anything lol, this is quite amazing and where the FUN part of GIT is, the > help/suggestions that it sometimes offers. Sometimes this can also be a bit > dangerous especially if that is not what the user should be doing > especially for the more advanced commands or situations... GIT might not > always known in what kind of situation the user has gotten himself into or > what he wants/intends to do, this is also perhaps something where GIT might > aid the user, the user might be able to issue an "intention command" or > "situation" and then "intention" command to GIT to try and make GIT > understand what situation in the programmer is in and what the programmer > wants GIT to suggest for example a pretty famous one is probably the > fuck-up and the much desired UNDO command haha... or the fucked up commit > message. > > Let's envision/see how such a git command could be implemented/done, for > example: > > Case 1, the code fuck up and commited fucked up code situation: > > git situation "fucked up code" and "fucked up commit" > git intention "undo commit" > git give suggestion. > > And then git might give some commands to try. > > Ofcourse it might be more easy if there was an undo command in the first > place though for many reasons that might not be as easy, because of the > complexity and branches involved etc. > > git undo last commit. > > ^ this might be helpfull. > > another could be: > git situation "bad commit message" > git intention "want to correct commit message" > git suggestion > > and then git gives some commands how to re-edit the message etc. > > Anyway, back to my desired intention of seperating the GIT databases and > evaluating if that makes any sense and what adventages and drawbacks could > be: > > The biggest adventage are: > > 1. My code stays absolutely 100% safe, assuming NTFS is safe ! ;) > 2. I can safely delete GIT databases if I don't like GIT anymore or if > something better comes along withour RISKING my source code. > 3. Direct access to source code always. > > I basically already went over some of the adventages at the start of this > post but ok, more insight at the bottom of this post. > > 4. Sharing code on my terms and when I want to do so, not having to share > everything not having to share all versions. > (People can still see versions/commit log in git database but get a > cleaner view basically) > > Anyway, let's explore how this could/may work and I do see some slighty > disadventages to this approach of seperating git databases. > > The down side to this idea is that I have to copy/duplicate the entire > folder structure of my main source code, in the example of jack this would > become: > > C:\Source Code\Git Databases\Test Jack\ > > I could have seperate git databases further in for example: > > C:\Source Code\Git Databases\Shared\ > vs > C:\Source Code\Git Databases\Private\ > > Shared would function as public, but not just from the public but also to > the public, so that is why calling it shared makes more sense this would be > a big fat warning to me that anything I commit to "shared" would end up in > the public/shared somewhere. > Basically an "uploadable" git database because remotes for pushing and > such are set. > > Private > In case I want to download some source code and not necessarily collobrate > on it. > > Perhaps it might make more sense to use the technical terms in the folder > names like so: > > C:\Source Code\Git Databases\Pulls\ > C:\Source Code\Git Databases\Pushes\ > C:\Source Code\Git Databases\PullsAndPushes\ > > I could then also move git databases if I decide to start collaborating or > stop collobarting etc. > > Pulls would be to benefit from other peoples code exclusively. > Pushes would be others benefit from me exclusively and I am not interested > in their code/contributions. > and > PullsAndPushes would be full on collaboration ! ;) > > I kinda like this idea a little bit, though there is some risk of > duplicates but this could also be a benefit, trying out different things. > > But what I kinda want is to reduce the number of git databases, currently > I made a lot of copies of git databases out of fear of fuck ups, and also > experiments/experimentations and so forth, I don't consider this > necessarily bad, but it might lead to some confusion/doubts about what all > those databases are for and state they are in etc. > > So let's continue with the jack example, let's suppose full on > collaboration: > > C:\Source Code\Git Databases\PullsAndPushes\Test Jack Algorithm\ > > Now I can expand on this folder name a little bit to clearly indicate this > is some kind of algorithm called jack or perhaps it was an algorithm from > jack whatever but at least I know it's some kind of algorithm... anyway. > > What I would now like to do is tell git that I want to commit certain > folders from my own versioning system for example: > > git commit folder " C:\Source Code\Tests\Test Jack\version 0.04 optimize > it\" > git commit folder "C:\Source Code\Tests\Test Jack\version 0.07 release it" > git push remote jack > > So basically here git would create it's own view/copy of what I've been > doing/up to and then users on github exploring my fork get some idea of > what I have been up to and can get a clean version of my work. > > Perhaps later I could also push some branches that I might want some help > with or whatever. > > So basically this creates a different view for git, git is not fully aware > of all of my versions, but only gets to see a select view. > > But this would allow me and others to use GIT features to detect > changes/differences and collaborate to some degree. > > So far so good, my question is: what git command do I need to use to make > this happen ? I feel confident GIT must have some kind of command for this ? > > Now I can see a big adventage of this approach. > > C:\Source Code\Git Databases\PullsAndPushes\Test Jack Algorithm\ > > ^ Could be used as a "working folder" for collaboration purposes. > > If git is smart enough to "check out' this folder after the 3 commands > above then at least that folder has a consistent view of what is in the GIT > database, it might be slightly confusing with my "real" source code folders > because it is already at version 0.11 but that is the risk I am willing to > take and for now I can deal with this inconsistency. > > This working folder would allow me to pull down changes from other people > and examine them safely inside this working folder, without upsetting any > of my real code folders. > > This is where further functionality is desired. > > I may want to merge against my own real folders. > I may want to difference against my own real folders. > I may want to check out to one of my own real folders. > > So for example: > > git compare folder "C:\Source Code\Tests\Test Jack\version 0.11\" > > Git would then see some changes, would notice the extra helper files and > so forth. > > Let's suppose somebody did some good changes > > I pull them down with > git pull remote jack > > Then I may want to merge those changes: > git merge folder "C:\Source Code\Tests\Test Jack\version 0.11\" > > Perhaps I consider the changes so good that I want to skip my own 0.11 > folder and check it out into a new version folder: > > git checkout folder "C:\Source Code\Tests\Test Jack\version 0.12\" > > Then maybe later I decide I do want to try and incorporate some of my > changes maybe from another folder > > git merge srcfolder "C:\Source Code\Tests\Test Jack\version 0.10\" > dstfolder "C:\Source Code\Tests\Test Jack\version 0.12\" > > perhaps first I want to see a difference > > git compare srcfolder "C:\Source Code\Tests\Test Jack\version 0.10\" > dstfolder "C:\Source Code\Tests\Test Jack\version 0.12\" > > after working on it and created: > > C:\Source Code\Tests\Test Jack\version 0.13\ > > Now I can incorporate it back into git database folder for sharing: > > git commit folder "C:\Source Code\Tests\Test Jack\version 0.13\" > git push remote jack > > So basically I can come to the conclusion that a "folder" based GIT > approach would be more suiteable for integrating with my own folder based > versioning system. > > Maybe later git could also be made more aware of file based versioning > system. > > But for now a folder based approach to GIT would be usefull. > > There is ofcourse a little catch once the git commit folder command is > issued there should be no trace of any of my main folders/structures. > > So basically I need to be able to setup git databases such that it points > to a certain "base" folder which in this case would be: > > "C:\Source Code\Tests\Test Jack\" > > Even though this doesn't make much sense yet, a better description would > be a "virtual folder" or "virtual base". > > Basically I would like to be able to incorporate some virtual folders > inside the git database so that if a user does clone the database/fork and > such that it gets a nice folder, for example: > > git clone jack "c:\junk\" > > junk is used as a test folder... > should produce a test git database such that the final result is: > "c:\junk\test jack algorithm" > > So for example I have to be able to create an artificual folder structure. > > Or I could just initialize the git databases into the lower folder: > > cd C:\Source Code\Git Databases\PullsAndPushes\ > > git create database "\Test Jack Algorithm\" > > However this would create a lot of .git folders and/or conflicting > folders in pulls and pushes so this is not good. > > Git must isolate this database in "Test Jack Algorithm\" > > So basically the git database should be in: > > \Test Jack Algorithm\.git" > > But I want git to be aware that it belongs to "Test Jack Algorithm" ? > > How can I do that without introducing a second folder like so: > \Test Jack Algorithm\Test Jack Algorithm\" > ^ This gets messing and somewhat annoying and confusing. It's a small > issue, but would be nice to solve it. > > This could become a bit issue if folder names become very long, so it's > definetly worth solving, windows does have some long folder name limits so > this can definetly become a bigger issue. > > So basically these are more desires and questions, I think there was one > more but I may have forgetting it in this anger about too long windows file > names lol, the last thing I forgot is probably not that big of a deal. > > If GIT could do all of this and perhaps setup some aliases or get new > build in commands to make this all possible that would be great ! > > This may also help to integrate GIT further with windows explorer and/or > NTFS or other file and folder based systems ! > > 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/764c8f08-b9c3-4d6b-80af-9fb866d7b2b7n%40googlegroups.com.
