> > > There's no such support built into Git (because this simply goes > perpendicular > to its data model, where multiple versions are recorded for the same file > (well, actually, they are recorded across the content of all the files in > the > project, but let's not digress)) but you can use Git's command to do what > you're after: >
What I would like also is for these differences to be visible on github/commits. - `git diff` can work on files. Yes I have seen this before, but it was not quite intuitive... I would expect it to work with git diff filea fileb but from what I can remember it may have to work differently based on what files are in the repo, though I could be wrong, tomorrow I will experiment some more with this git diff and creating patches. > > - `git apply` and `git am` can be used to apply what `git diff` generates > - > this is called "unified diff format" - to the specified file(s). I have heard about "patches", "git patches", "applieing git patches", "e-mailing git patches" and such but never really done it so this is a bit interesting to try this out. At least this is a start and offers something to try and get these differences and store them. So for now my idea is to create some kind of patch/patch files and then store them on the repo in case I want to store these differences and then in principle people can click those difference files on github and can see the differences in this git diff format. But I have a feeling this will be less ideal because it will probably be somewhat confusing and will probably not "play ball" with github though I may be surprised. On the other hand the difference visualization on github is not too great anyway... meld or other tools might be better.... but for quick web access github is kinda nice. However noobies or maybe even nobody might understand what these patch files are but then that is up for me to describe. It would be nice to record at least these changes somewhat, it would be even nice if this could be automated... I am sure somebody could come up with a script, but then it might become somewhat painfull if I have to start using scripts everywhere for such versioning files. So then one could say, just leave the version information out but I have some objections against that because then it becomes hard to actually know which file in the repo/which commit is actually an intact version or a next version. Another solution could be to use git tags, but then versioning is lost if these tags disappear or git stops being used, and there is another disadventages to not using multiple versions, it's a pain in the ass to switch to older versions/commits, creating a worktree just to fetch one older file is a pain in the ass. Plus here is thus also where git gets messy when it comes to versioning and keeping version implementations seperated, this is where git truely starts to "flow" to much into each other and this is a complained against how git handles this and here I feel git somewhat falls short and should get some kind of true version number feature to version files properly, and maybe even start a versioning "revolution" where programmers actually start liking to version their files properly ! ;) Now there are some disadventages as to have to replace version numbers everywhere it's used when it increments that is true, but this can also be considered a major adventage because now the compiler will complain about missing old version if it was removed from project and hence you as a programmer get automatic support from the compiler to check exactly which files are updated because of a new version being used, so this gives more control over "transitioning" to a new version. Sometimes this may be overkill, or annoying or time wasting, or undesired, but on the other hand it can also give re-assurence that everything is fine cause you re-checked most of it. Now spending so much time on re-versioning things is somewhat of a time waster so I don't try to use it too much but I have seen situations where not versioning quickly would be much more horrible... and this is where git falls short. Committing unfinished or broken versions also seems not a good idea, so quickly renaming files and incrementing their version number is a much quicker/easier and saver way to quickly interate over versions of files/implementations, keeping multiple files consistent by changing all of their version numbers so that programmer knows they belong together. Without proper versioning of files it becomes much harder to tel if a certain file was properly changed to fit the new version... it becomes confusing to say the least and previous work/data/code could be lost much easier since it's overwritten by newer versions/implementations. Again this is where git falls short and needs some kind of future to quickly and safely version files. The closest thing I have seen so far that comes anywhere close to the desired feature would strangely enough be git stash, with indexing where multiple works can be "stashed" but ofcourse stashes way too risky and odd to work with, one wrong stash command and poof everything gone, don't like that... files should be on the system and not somewhere in some magic repo stash. I would also like git to record these diffs between versions permanently just to be able to see what changed, and it would be nice if it could this automaticaly, running git diff weird command is kinda boring and tedious last time I tried it, there it could also use some improvement maybe... add the weird slashes and it gets difficult/akward to use... > But in general this is not a task specifically for Git - the venerable > tools > `diff` and `patch` predate Git by at least two decades, I think. > Then you kinda admit here that git is not a versioning system and that kinda sucks a little bit :) So git is a flow system... and there is such a thing is too much flow. I don't want multiple versions/implementation/concepts flowing into each other. Different implemention concepts belong at the very least in different versions. I know what you thinking, create a seperate branch perhaps for different concepts/versions, this is kinda weird, and also very risky and strange... cause switching branches is strange when changes are not commited yet and it is also hell confusing cause you don't know what was on the last branch to be honest... all you know these files came from there... it's possible to do a git diff but that might confuse more then it actually solves and it wastes time. Plus creating different versions is not possible without either: committing, which is undesirable because the implementation is not finished yet, or using work trees which is to heavy handed. I may be working on two versions at the same time, an older version which I am unhappy with and a newer version which is supposed to be better. Thus this requires moving code from the older version to the newer version or chopping code off and fixing chop off mistakes, hence a clear need to be able to work with two completely different versions on disk, perhaps even three if I need to go even deeper for older data structures, perhaps even 4 or more theoretically no limit, but let's keep it at something reasonable like 3 or 4. This is where git becomes boring, a time waster, heavy handed, cumbersome, risky and confusing, not to mention having to come up with a non-conflicting branch name. Maybe I simply haven't mastered "git flowing" yet and "branching".... which is quite messy for me currently... The idea if merging flows/feature branches is a conceptually very strange idea for me and for now I don't like it because I don't know what the hell I am merging and what the end result will be... to much automization. The work I performed on the new version might as well be almost perfect... and if I merge it I run the risk of the merge process screwing it up without me even noticing it.... or now I have to waste more time and do a git diff somehow after the merge which is also somewhat akward maybe... is it git diff HEAD ? git diff HEAD~1 could be tried... now there is even more risk... what if the merge fails... more time potentially wasted on aborts... what if something goes wrong, or a miss-merge... undoing merge commits is much harder then actually working with files and correct a mistake in a file... again much much much more risk with git... now expensive re-base operation or risky git resets and what not have to be done to correct wrong commits. So this is where git and the user is fighting the system much more than it is worth it. As far as I am concerned this is where GIT could improve and needs to improve, this is where the entire software world and maybe even document world needs to improve and try to version there files better, especially files that belong together ! ;) Though that is also somewhat debately... single files can also be very important and allowing files to run out-of-sync version which might save time but I usually not do it though sometimes I do but then later correct it once everything is good and stable and then I sync it up again... just to save some time. 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/c22601ca-f782-4514-883d-65f825eb445dn%40googlegroups.com.
