On Sunday, October 31, 2021 at 2:27:29 PM UTC+1 o...@ucm.es wrote:
> I have to admit, I am a bit lost in your description. A couple of remarks, > though. > I thought it was simple enough but ok, I will try and give a procedural description and some further explanations. The procedural for me coding is as follows: 1. I wake up. 2. I used to start my (Dream)PC, though lately I keep it down cause it doesn't feel well lol. 3. I go to the project I want to work one. 4. The very first thing I do is I make a copy of the latest version folder with windows explorer. So I go to: "C:\Source Code\My Super Duper Trooper Application\version 1.15" I click it, I just copy and then I pasted it: "C:\Source Code\My Super Duper Trooper Application\version 1.15 copie" 5. Then I rename it with a description of what I want to do/accomplish that today. Note how there are a couple of things different about this compared to GIT: Let me first explain why this workflow once again: 5.1 The main thing is ALWAYS making a copy before I start to work on anything because of two main reasons: 5.1.1 I don't want to loose any code of the previous day, always making a COPY before any new work assures I never loose work. 5.1.2 I don't know how I am feeling this day... maybe my brain is all screwed up and I do something stupid, it's rare but it might happen ! =D 5.1.3 I takes away any fear I have about editing code. I can do whatever I want, if I screw up I don't loose anything, except what I did today. 5.1.4 and if I did do something usefull today I can simply make another copy and safe my progress that way forever/safely. 5.1.5 I basically never delete any versions whatsoever unless it's total garbage and I really don't want to confuse myself in the future. Now try and notice a couple of things different from GIT: 5.2 I always get a clean COPY, I always SAVE my progression NO MATTER WHAT. This is different from GIT, where COMMITS are not always possible because of a whole bunch of reasons, this is dangerous (risk of losing work) and this can be annoying and might even lead to stupid commands to get GIT to move on. 5.3 Another big difference is my "commit" message which is incorporates into the folder name. I write at the START of the day what it is that I wanted to do, not at the END of the day. With GIT commit I can only write a commit message at the end of the day, BUT ONLY if I can do a successull COMMIT, this is dangerous because if I can't do a COMMIT I might loose information, I might forget what I wanted to do that day with that particular copy/version. One way around this would be to give the branch a longer name. However folder names allow longer names/descriptions, too long branch names might get a bit annoying. ^ These are two valid slight complains against GIT, I hope this is taking a bit more seriously but ok. Anyway so in short my workflow is: 1. WAKE UP 2. SELECT PROJECT/FOLDER 3. COPY & PASTE PROJECT/FOLDER 4. INCREMENT PROJECT/FOLDER VERSION 5. DESCRIBE INTENDED WORK IN PROJECT/FOLDER VERSION. ^ This workflow is repeated every day, logs my progressions, keeps any of my work safe. 1. I would never ever have space in directory names. That is calling > for trouble, but if it works for you fine. > I feel the opposite, spaces are very important to be able to type relaxed and make good messages. typing underscores can lead to mussle strain because of weird shift key usage and such, typos and other mischief, though sometimes I do avoid spaces in names and revert to capitals, but rarely underscores _. > 2. I used a similar approach, quite a long a time ago, before I > switched to RCS, then (forced) to CVS and then to git/hg. The > problem of this approach is: there is no equivalent to > > git log --graphical or friends This command does not work, is this pseudo code for a command ? I am a bit intrigued about the friends thing ? :) > so you are completely on loss about the logical dependence of > your «commits» if I can call them commits. > On the contrary, every version is simply build on the previous version number except if otherwise stated. version 0.09 version 0.10 ^ version 0.10 logically follows version 0.09 that is the whole idea of versioning as far as I am concerned :) If you mean library dependence that is handled via project file and paths to folders/files. 3. It seems that you dislike hashes, (what I can understand to a certain extend from the usability point of view, at least for a > single user), but you can > If GIT breaks down or is removed no hashes available what so ever. I like recording versioning information into the files themselfes. > a. Either use > git log --graph --decorate --pretty=short | git name-rev --stdin | more > Strangely the pipe command | more does not work in this combination but without it it did work. It seems to "auto-tag" everything. > b. Or switch to mercurial which has a local number system, I have heard about this, wasn't this a commercial versioning system ? So far I like GIT best, I can understand GIT, not sure if I can understand the way mercurial numbers/versions files so there could be a downside to numbering/versioning files it could get too complex like 1.2.4.1.4.6.7 and such :) > besides hashes. Mercurial also has named branches which might > fit in better in your workflow, but, as I said, I am not > entirely sure I really understand your workflow. > In GIT I can name branches quite well, so it seems sufficient ! =D > c. Before a flame war starts, I have hastily to add: git has some > advantages over mercurial > > - it is faster on huge repositories. > > - its branching system is a bit more flexible > > - its far more extended. So at some point one should know git > (as I try to do) > Since GIT is used for Linux Kernel, I take you word for it and I believe you ! =D Bye, Skybuck =D -- 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/5c12cd16-1c9f-49e7-bdca-492384763342n%40googlegroups.com.
