New likely bug Eschema; symbols & wires moving off grid

[gkeeth]

Yes, it was fixed 4 days ago and has been in nightlies since then.

You can see from this message on the issue page:

If you click on the commit hash link, it will take you to the actual code change that fixes the bug.

[BobZ]

Thank you. “Closed” and “commit” in this context seem to be jargon which I have not understood to this point.

[gkeeth]

Sure. I’m not sure if you’re asking for an explanation, but here is one whether you want it or not

“Closed” refers to the gitlab issue state, which is now considered closed rather than open. If the bug reoccurs or isn’t properly fixed it can be reopened in the future.

“Commit” is git/version control terminology. A commit is a discrete set of changes to the code with an associated message/description. You could also think of each commit as a new saved snapshot or revision of the code. Git calculates a hash for each commit which uniquely identifies that commit. The ae24daa0 in the screenshot is the first few characters of that commit’s hash.

Gitlab has a nice feature that allows commit messages to specify which issue(s) they address, if any. Then that commit can automatically close the associated issue(s), which is what happened here with Jon’s commit.

The other piece of the puzzle is when exactly the nightly builds get built. When the builds kick off, they grab the latest commit (the most up-to-date snapshot of the code). So a specific commit could possibly miss a given nightly build if the commit is made after the build starts, but it will get picked up by the next day’s nightly build. In this case the commit was 4 days ago so it should have been in at least 3 nightly builds.

You can see all the commits to the master branch of kicad here: https://gitlab.com/kicad/code/kicad/-/commits/master

And this seems like a reasonably good article about the concept of a commit in version control systems: https://en.wikipedia.org/wiki/Commit_(version_control)

[BobZ]

@gkeeth

“Closed” refers to the gitlab issue state, which is now considered closed rather than open

At the core, you answered my question and for that and your further efforts I say thanks again.

If a court case is closed, that does not say whether the defendant is guilty or innocent. It only says that the court is done with it. Am I correct?

Is a “hash” just some sort of a code?

[gkeeth]

If a court case is closed, that does not say whether the defendant is guilty or innocent. It only says that the court is done with it. Am I correct?

Correct, both for your court analogy and gitlab: “closed” in gitlab just means the developers consider the issue finished. A gitlab issue could be closed for many reasons: a developer committed code to fix the bug, or the bug was fixed a long time in the past, or the bug never existed, or the bug exists but it is infeasible to fix, or the software is working as intended (“as designed”), or the bug is in an upstream library and not kicad, or the issue is a user’s opinion, or it’s a duplicate of another issue, or…

Is a “hash” just some sort of a code?

Again, this may be more information than you’re asking for, but a hash function is a function (in the mathematical sense) that turns arbitrary information into a value of a fixed size/format. The output value is called a hash. In this case, the arbitrary information is the changes that were made to the code, and the output is the alphanumeric string that uniquely identifies the commit.

There are many, many different hashing algorithms that are useful for different things and turn up all over the place in computer science. Often the idea is that it’s easy to go from the input data to the output hash, but hard to go the opposite direction.

One example would be passwords: the system should store a hash of a password, and not the password itself. When the user enters the password, it gets hashed and compared to the stored hash. If the two hashes are the same, the user has entered the right password. If the hashes don’t match, the password was incorrect. And if someone hacks the system and gets the list of passwords, in reality they only have a list of hashes, not the passwords themselves. It is difficult or ideally impossible to calculate the original password from the hash.

Edit: and I should add that none of this information is required to use kicad… It’s just information that may or may not be interesting.

[SembazuruCDE]

@BobZ

If a court case is closed, that does not say whether the defendant is guilty or innocent. It only says that the court is done with it. Am I correct?

As with most analogies, this isn’t perfect. But It is probably close enough. The way I see it is a commit is an attempt to fix the bug. The issue can be kept open until the fix is proven to fix the issue, or may require an additional commit of code to try again to fix the issue.

@BobZ

Is a “hash” just some sort of a code?

Think of a hash as more of a fingerprint. There are many ways of generating a hash (most often it is by applying a mathematical formula to the object being hashed). With Git, it is a way of uniquely identifying a specific change. Hashes are used in other situations that is probably way out of the scope of this conversation. For this application, just thinking of it as an attempt for a unique fingerprint of the commit.

I’m sure that I’ve missed some nuances in both of the above explanations. Hopefully it is enough to kinda understand it for those of us (yes, myself included) to who don’t deal with either concept on a daily basis.

EDIT: Oops, looks like @gkeeth answered with a better answer to mine while I was writing.

[BobZ]

@gkeeth

Edit: and I should add that none of this information is required to use kicad… It’s just information that may or may not be interesting.

Thanks. I appreciate your effort to explain this stuff. Programming is not my forte.

@SembazuruCDE

Hopefully it is enough to kinda understand it for those of us (yes, myself included) to who don’t deal with either concept on a daily basis.

Likewise.

[John_Pateman]

When you are writing something under version control, you continue to work on it until a feature or a section is finished and tested. This might be equally be a bug fix. When you are happy that the work is complete, you ‘commit’ the new version to the archive - usually called a repository. Not a suppository which is rather different.
When you make the commit you add a message eg “New qwerty doodah. fixes issue [1234]”
In return the version control software returns a reference to this point in time in the form of a long hex string. “abd128bc….” The way this is calculated isn’t important but it is a unique reference to this point in time. So if someone else is looking at the project they know exactly where you are on the timeline. Usually you only need the first six or 8 characters to positively identify this.
Most of these versioning systems are ‘distributed’ so anyone else working on the project can just pull in the latest changes on line.
The VCS software allows you to go forward and back in time showing you exactly how the project was at any arbitrary point. You can also make a side branch to see how a change might work and play around with it before adding it to the main record.

Now, you may think this is just about code but it works for any text file. You can use vcs for your autobiography, the manual for some software or even for a KiCad project. Imagine being able to save a point in time and then make a new branch and try out a different layout. You could look back at a diagram which shows where you are in time. You could abandon your attempt and just choose to go back to the version that used the through hole voltage regulator because you can see the point in the timeline which says “try layout with smd version of Q3 voltage regulator” rather than looking through the directory and wondering if the one you want us “20211117-090545-Project” or “20211117-090735-Project”

All for the price of typing “git init”.

[BobZ]

Thank you for the explanation.

@John_Pateman

Not a suppository which is rather different.

I would ask you to spell out the difference but I will spare you that smelly task.

@John_Pateman

You can use vcs for your autobiography, the manual for some software or even for a KiCad project.

With KiCad I copy and rename the project folder along with the batch of KiCad files within it. This works for me although it might be instructional for me to learn to use VCS. The explanations/comments associated with the versions might be particularly helpful. I particularly like to save a point in time when I am making changes which might “not fly.” But I almost never end up going back to the earlier branch.

[RRPollack]

@John_Pateman

In return the version control software returns a reference to this point in time in the form of a long hex string. “abd128bc….” The way this is calculated isn’t important but it is a unique reference to this point in time. So if someone else is looking at the project they know exactly where you are on the timeline. Usually you only need the first six or 8 characters to positively identify this.

A small clarification: it’s more appropriate to say the hash refers to a unique reference in the history of development, rather than a point in time. A Git hash includes the state of the data being tracked, including the content of the commit logs to that point. Any change in the data or log history will result in a completely different hash value (i.e. it’s not a sequence number that increments). The hash does not, however, include the date/time the files were updated.

This difference is irrelevant to the average user, but is an important distinction to anyone looking at or compiling the source code. Two checkouts of the same commit (hash) will result in the same file contents, but the modification dates on the files may (will) be different. This is a common point of confusion for new Git users.