Also throw away any graphical tool you might use. They are dangerous! Use the command line (you will most likely only need to remember 6 commands this is not rocket Science)
I wouldn’t say so, even though it’s very good to learn to use git from the command line first to understand the GUI tools.
The artifact seems to be caused by leaving the (your local?) repository in the middle of a merge operation. If that came from the central repository or goes there, you and your university comrades are in a deep trouble with git and you really should take time to understand and learn to use merging or how to avoid it.
If it’s of any consolation, merging may be the most difficult part of git which average users have to taggle with.
But it also has to be said that you shouldn’t need or even try to use merging with KiCad files, simply because it doesn’t work at all with these kind of data files. Even though they are human readable it doesn’t mean that they behave similarly than programming source code. This has been discussed many times in this forum. Therefore, if you bump into a merge conflict with KiCad files, you have to stop and think what’s wrong with your workflow.
Sadly a lot of graphical tools make it way too easy to loose data. They are setup to not fail as easily to give users the impression that git is easy. Meaning things like being in the middle of a merge or losing data on branch switch are mistakes that happen way too easy (on the command line you would need to enter --force to ever be able to lose data, tools like gitextensions have the “force” option directly next to the sensible options including the “no flag” option. I have just this week seen somebody loose a full day of work with this shit.)
In any case my best guess is that this is a student project with a deadline and they have to get this done. Therefore they don’t have time to learn to use git properly. And there’s no need for that: they must avoid merge conflicts, not solve them.
So, @Szilassi_Andras, if you and some others have made changes to the same file simultaneously, in parallel, and hope to get a working design – that won’t work . Each one of you must make changes to a file, then push them, then the others have to pull them without making any changes to that file meantime. In other words, every instance of that design file must be “locked” when it’s edited - if not in the versioning system level, then at least by your common agreement.
The same is true for a situation where one person makes changes, pushes them, then changes to another machine and continues there without first pulling. He will loose either his first or second changes, they can’t be expected to be mergeable. (Don’t ask how do I know this use case.)
Even though git is very powerful, it’s not a good fit for non-distributed (or maybe actually “centrally controlled”) development.
If the university supplies an SVN server then this might be the better option. Especially combined with locking files to avoid getting into merge troubles. And yes i am aware that Students always start to late and therefore have too little time to do anything properly (I am after all still a student on paper). Well my professor defined it as “experience is realizing earlier that you started too late”. But still if i need to use a tool then it in most cases pays off to invest a few hours into learning it instead of loosing days in fixing my mistakes.
Reminds me of when I worked at the general consulting desk at my Universitie’s computer center (early '90s). The programming classes all used the VAX/VMS server, but were never taught the basics of the filesystem. (VMS will create a new version of a file every time you save to the same file name. So you may end up with foo.bar[1], foo.bar[2], foo.bar[3], etc.) The account filespace allocation was fairly small, so it was considered normal for about halfway through the semester to start getting students coming through complaining about their account being full. When we have them log into their account we would find hundreds of versions of each project (because they were following the rule of save often). VMS has a very simple command called purge that by default will delete all but the most recent version of a file. (I haven’t used it in a long time, but I believe you could tell it how many above 1 to keep with an argument.)
Based on that experience, I’m not surprised that students don’t get much instruction on how to use git.
I used to have an extremely simplistic approach to version control systems.
Every day I’ve made some significant progress on a project, I write a short description of the change in a log file, and then zip the whole project directory and attach date in ISO8601 to the zip filename. Often I also delete a lot of the files in the project_2020-05-20.zip such as KiCad’s own backup files and other files that are known to not be important.
I also copy these backups to external storage, so even if my whole PC crashes I do not loose much.
It’s simplistic but yet very effective, and most of all, the learning curve is near zero.
For the last half year or so I’m also struggling with Git.
It would be really helpful for me to have true version control built into KiCad.
As I do designs “graphically”, I’d like to commit graphical changes, and see the diffs visually.
I know external tools exists like https://cadlab.io/ - haven’t tried it so don’t know how is it performing.
