> > I bet Git > feels like one of those taxi rides through an unfamiliar city.. >
The GIT bash feels a bit cyber-punk-ish =D It feels very cool, though there are plenty of git bash/text/gui bugs and flickers and issues as well as the editor. I particularly like the git log --graph --all command Very cyber-punk-ish. And I also like the ANSI coloring... also very cyber-punk-ish ! =D The greens, the pinks, the cyans. Remembers me of GOOD TIMES, the dial-up modem, BBS times ! =D And a little bit Star Trek Online chat windows ! ;) > > > 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. > > I would recommend trying at least the git-gui and gitk at least for > their alternate view points when exploring Git. > On the other hands the GIT guis feels a bit child-esh, amaturistic, clumsie, slightly ugly, slightly to compacted but this could be to display more. Maybe my oppion about this will change, I may try GUI at a later stage, for now I kinda like the git bash commands too much, I can take it slow that way and have to think carefully what I am doing. With the GIT GUI I worry a bit too much that I start "clicking" on everyting like a raving lunatic and accidentally issue all commands of hidden/secret commands behind those GUI buttons. I don't really know at this point what the GUI does/buttons/commands kinda hard to tell, so that is a bit of guess work/gamble work... with commands at least I kinda know exactly what I am getting if I read the manual... sometimes I gamble a bit with commands as well, if I forgot actually how it worked... so far git is somewhat robust against gambling commands =D Maybe my luck will run out some time =D or perhaps slowly the commands will in-grain itself into my brain and get stuck there ! ;) There are plenty of times when I forget to put GIT in front of it for example so it remains a bit of a risk. > Because the basic data model of Git hasn't changed and is rock solid all > the gui's essentially show the same stuff at different levels of > prettiness and soft rounded graphics. Git-gui and gitk are TCL apps > which are multi-OS. > This may be one of the main reasons why I don't like the look of the GIT gui, it does look like a TCL app, it doesn't look like a genuine native windows app. If something breaks in TCL or TCL is incompatible on windows version X this GUI may stop working. And then it becomes a question how good are those guys at keeping it cross-platform/keeping it working. I am not sure how trust worthy and high quality TCL is. However Visual Studio or Delphi code should be much harder to break. I can vouch for Delphi based GUIs, Visual Studio a lot less. TCL I don't know ? What technology is it based on ? Probably some visual studio code ? Does this TCL GUI work on Windows 95, Windows 98, Windows XP, Windows NT, Windows Vista, Windows 7, Windows 10, Windows 11 ??? I bet it probably doesn't work on all versions and somewhere it will probably crash and I really don't want to run into those kinds of issues. There will probably be some missing DLL or it's probably linked against some newer Windows DLL version, this may be a consequence of using the Visual Studio or Delphi compiler, so this is a complaint against these compilers, However if the correct compiler is used for the correct windows version then multiple TCL GUIs can be produced for each operating system. Or TCL gui has to dynamically load DLLs and use some special compiler technology. Creating a fully cross-platform GUI is not as easy as it sounds. I do believe TCL may have put some work into it, but still... I would need to see some hard core evidence that it runs truely on all systems, all windows versions. With ms-dos/text based BASH it's much less likely to break, perhaps this is a wrong assessment of me or it may be spot on, I am not sure what technology is used to display BASH text prompt and such, it's probably not CMD.exe based but it might be. CMD.EXE iswholy in windows. Microsoft depends on it to build windows, it's probably one of the last things to EVER break ! HAHA. > 1. Big Open Soure Linux Operating System, here making simple copies > would fill up harddisks very quickly, so I can understand only storing > "differences". > > This is one of the BIG LIES we tell. I see a trend here. I also lied a bit, normally I don't lie... I do care about the ammount of storage space it takes, but again as long as it's not too much it's ok, then I don't care so half-a-lie. > Git stores snapshots. It will I may have noticed this. I did notice the GIT database can get quite large. One example is PascalCoin... it's git database seems to be 100 MB... it shouldn't be that big I think, I don't think the sources are that big, so this may be because of copies of all different versions stored ? > _show_ diffs between commits, but it's still between snapshots. It is > only later at the database level that compression is applied. > Are all snapshots stored in the git database uncompressed ? What do you mean with database and compression, is it applied later automatically by git ? For example when I "download"/pull a git repository I do see some zip extraction going on... and sometimes maybe also further pulls. Is that only done for the communication/protocol part to cut bandwidth costs ? Or is the git database later re-zipped ? For example after a GIT commit ? Come to think of it, compression might eat into time... so maybe GIT doesn't do much compression when day to day work and committing ? Maybe GIT only does compression on a git push ? And then maybe only for communication purposes ? Or perhaps then it stores it compressed ? Hmmm... > I couldn't care less about storage space > > The Git community is poor at highlighting the *backup capability* of > remotes, and when to 'push'. They are more worried about storage access > times .. > The idea of having my code backed-up on some remote is starting to grow on me, it makes it easier to move my code from computer to computer. But do I like the idea of Microsoft being in control of my code ?! =D HA ! =D Maybe lol. Perhaps an encrypted remote server lol, which only I can see the contest of for now. Perhaps after death key might be revealed but that creates incentive to kill me ! =D Perhaps key stored at some official. > 4. Difference engine, detecting differences > > You do know you get automatic de-duplication because filename metadata > is stored independently of content (blobs), so copied file contents take > up zero room! > I am in doubt what this means. I take the blog theory of GIT with a grain of salt. I have seen it fail to detect blobs. > > > 5b remote branches > > Mental mind trap: these are held locally when fetched. You can reference > them _instantly_ and start a new work-branch directly from them, without > having to create a 'local' version first > Yes this I understand that they are locally fetched. This is the cool thing, it feels like they are remotes, but they are stored on my drive and I can see and work on/copy from them at any time and if/when it pleases me I could even upload something if it's not to old and then it may sync-up or issue a pull request on their remotes which is very cool, lots of automation there... It's like SURPRISE, I have a commit/pull request for you ! Almost like a birthday present, they may not have known I pulled down their remotes unless they inspect github with insight but still don't know for sure if anybody is working on their code ! =D > > 1. Continue working with my own versioning system for very fast code > development when developing solo. > > It's an option. However if your development becomes a team, you are > likely to run into scaling issues (see Mr Torvalds's issues ;-) > I would like to discuss what my options are with GIT, if you know anything about this that is. I have seen different options and I would like to know which ones would be best for me in my scenerio. I could experiment with it, but if I can avoid experimentation based on advise that I would prefer somewhat. So far I have seen some things/options mentioned: 1. replacing the the .git folder with some kind of directive to re-direct git to where the git database really is. I can see some adventages and drawbacks of this: Disadventages: 1.1 One could consider this "folder pollution" but it's not so bad. 1.2 It could get very confusing: Is it the real git database ? or is it a referrial ? It may have been better if the folder was called something else like: .gitlink instead of .git To clearly indicate that it is a link to some git database and not the real thing. Adventages: 1.3 Easy to use, just put a .git file in there and a re-direct. 1.4 Traceability towards the git database, by inspecting the file I can know that there is a git database and where it is. 1.5 Indication that this folder is associated with a git database. This I consider a big one, I may forget that there is a git database associated with it. Anyway it was a bit hard to find what git options are available to, I found some information scattered all over the place over many websites. I probably stored it in firefox with some session manager. I may dive back into that later. If you have any more links or tips for reading how to do all of this I am all ears ! =D I still think it's necessary to somehow tell the git database where to work on... hmm.. > > GIT is more focused on sharing quality/working code and integrating code > > and less on experimental/broken/flawed/buggy code. > > OOOH So missing the point... Git gives control to the user so they can > do the latter in the privacy of their own dev environment. > You mean bug fixing, experimenting with code ? Well this can be done via zip files or something but ok, git does simply/automate and speed this up. > It then provides the tools so that they don't have to be embarrassed > when publishing their polished code ! > What tools, like downloader/uploader ? The difference engine is kinda hard to use, it's textual it gives some ideas, maybe sometimes even better than beyond compare because left,right does not need to be chosen it's automatic sort of, more consistent but the real work has to be done with Editors, Compilers, Beyond Compare, Linkers, Assemblers, GIT is only a tiny little tool in it all ! =D > > You should see some of my hacks on Matlab (interpreted, 3 fails a minute). > Having lots of versions allows me to go back to interesting outputs that > would otherwise have been lost in most other versioning systems > (remember its 100% snapshots!) > Hmm why would it have been lost in other versioning 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/6676b29f-43b7-418e-b61c-c0b90c44e69en%40googlegroups.com.
