Diff between branches or long spanning history.

[topherbuckley]

I've got a long history of commits (>100) spanning between two versions of a project (e.g. v1 and v2). I don't care about the individual diffs, but just want to show someone the diff between v1 and v2. They each sit on their own branch tip, and I don't want to necessarily generate a kiri diff for each commit. Is there a way kiri can specific two particular commit hashes to just take a diff between them?

I suppose I could just make a temporary branch and squash everything for this purpose, but wondered if there was a way to do this with kiri alone?

Cheers! Looks like this is progressing well since I last checked in on it.

[leoheck]

Hi, @topherbuckley did you get the opportunity to check the kiri -h? I believe there is an option for this, there.

Cheers! Looks like this is progressing well since I last checked in on it. Thank you

[topherbuckley]

@leoheck , yep, I tried all I could think of to filter the commits by --older and --newer, but I couldn't seem to get them to work together. Say I had a git log something like:

HEAD HEAD\~1 HEAD\~2 ... HEAD~100

I was trying things like:

kiri -y --newer HEAD~100 --older HEAD~97 robot.kicad_pro kiri -y --newer HEAD~97 --older HEAD~100 robot.kicad_pro

as I wasn't clear on which order they should be, but regardless, I'd always get the error "Leaving, less than 2 commits found". So I'm guessing these two flags can't be used simultaneously else they exclude one another?

I didn't see anything else that looked relevant in the help, but feel free to correct me if I'm missing it:

     -a|--all         Include all commits even if schematics/layout don't have changes
     -o|--older HASH  Show commits starting from this one
     -n|--newer HASH  Show commits until this one delimited by this one
     -t|--last VAL    Show last N commits

     -l|--no-server   Do not launch webserver/browser at the end
     -S|--server-only Start webserver but not launch browser
     -p|--port PORT   Set webserver port. By default it will try to use an available port.
     -i|--ip ADDR     Override the default 127.0.0.1 IP address

     -s|--skip-cache  Skip usage of -chache.lib on plotgitsch
     -6|--skip-kicad6 Skip ploting Kicad 6 schematics (.kicad.sch)
     -u|--layout      Force starting with the Layout view selected
     -f|--page-frame  Disable page frame for PCB

     -d|--output-dir  Change output folder path/name
     -r|--remove      Remove generated folder before running it
     -x|--archive     Archive generate files

     -v|--version     Show version
     -h|--help        Show help

     -X|--super-debug Tons of things
     -D|--debug       Extra info
    -dp|--debug-sch   Show Plotgitsch stdout and stderr
    -dk|--debug-pcb   Show Kidiff stdout and stderr
     -y|--dry-run     Run without generate artifacts
     -V|--verbose     Verbose

Also, the filtering by commits like I was trying to do would still assume the commits are linearly related (i.e. on a single branch but further back in history). Is there any way to specify another commit in another branch? For a normal diff (not kiri-diff) I'd just use git diff v1 v2 to see the diff between the two things I'm trying to compare. I was hoping for a similar syntax in kiri, but maybe it is assumed to be a linear history in the bash code?

[topherbuckley]

I was able to get the schematic diffs for what I wanted by squashing everything into a temporary branch, but the pcb layout is not generated for the earlier commit for some reason. I'd presume this is because it was using kicad 6 while the newer version is on kicad 7. I guess I need to import the kicad 6 version into kicad 7 before I can do the pcb diff?

[leoheck]

I think that comparing different branches is not possible yet. I never seen anyone with this request. But it can be added, maybe. Is it fine to work with Kicad with multiple branches.

Now, for comparing 2 versions you have to o use the hash of the comimt. you can get them with kiri ls I guess.

Then the comparison will be made with commits inside in between those hashes, including them, if I ma not mistaken. If the mag of comparing less then 2 commits appear, try to add the next hash (having for instance a list of 3), since it may be a big.

[leoheck]

Hey @topherbuckley, kiri is using the short version of the hashes.

I've pushed some small improvements here. But you definitely should not need to slice your git repo to make it work.

You can try something like this:

Start by doing kiri ls to help you get the hashes where there are changes in the kicad_sch or kicad_pcb files. Alternatively, you can use kiri lsa so you will be able to see the whole history of changes. The ls and lsa were just improved, you will have to upgrade your copy of kiri.

➜ kiri ls
     1  7aebd2e | 2023-03-22 16:09:20 | Leandro Heck | Update to Kicad 7
     2  5be11dd | 2021-12-29 14:58:15 | Leandro Heck | Update 3d models dir variable
     3  d0628e0 | 2021-12-29 14:54:10 | Leandro Heck | Convert project to Kicad v6
     4  010b611 | 2021-12-29 14:25:14 | Leandro Heck | Update using kicad 5.1.12
     5  20e163c | 2021-02-09 10:53:38 | Leandro Heck | Remove 3Ds, fix 3V3 and 1V8 switched labels
     6  f35d811 | 2021-01-23 11:23:21 | Leandro Heck | Align filled zones on 0.5 mm grid
     7  0a59275 | 2021-01-23 11:14:10 | Leandro Heck | Update copper areas
     8  e91e087 | 2021-01-22 18:28:56 | Leandro Heck | Final touches with the labels
     9  89f22a1 | 2021-01-22 17:55:51 | Leandro Heck | Update layout file
    10  b59502b | 2021-01-22 17:52:07 | Leandro Heck | Update
    11  224bb02 | 2021-01-22 17:21:39 | Leandro Heck | Initial version

Then you can pass the hashes of the older and the newer commits, like this.

➜ kiri -r -V -o e91e087 -n 0a59275

If you are using a hash that does not have changes in the schematics nor pcb, then you have to use the -a flag so it will use the whole history and not only history instead of the history that has changed in the schematic and the PCB. Like this

➜ kiri -r -V -n f505bfe -o d8406e6 -a

If the hash does not exist it is showing a message with that info. This was just added too.

Try to access the commits from a branch using the -a flag. If that does not work, I will have to think deeper about how to improve this.

but the pcb layout is not generated for the earlier commit for some reason

This can be a bug. Could you create a new issue so we can discuss this better there?

[leoheck]

Hey, @topherbuckley I added one extra parameter to allow comparing between branches as git does. Could you check if it works for you?

The syntax is this one.

kiri -g HEAD..HEAD~1

[topherbuckley]

Hey, @topherbuckley I added one extra parameter to allow comparing between branches as git does. Could you check if it works for you?

The syntax is this one.

kiri -g HEAD..HEAD~1

Brilliant! Yep, this works as expected. I tested both on a linear history and two diverged branches. Works as expected. Thanks!

Is there a quicker way to update with git btw?

Or do you also run:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/leoheck/kiri/main/install_dependencies.sh)"

followed by bash -c "INSTALL_KIRI_REMOTELLY=1; \ $(curl -fsSL https://raw.githubusercontent.com/leoheck/kiri/main/install_kiri.sh)" for every commit you do?

I'm much more git friendly, so if you have a dev approach to updating, I'd like to know so I can pull in your commits easier.

>This can be a bug. Could you create a new issue so we can discuss this better there?

Done. See [here](https://github.com/leoheck/kiri/issues/89)

[topherbuckley]

Is it fine to work with Kicad with multiple branches.

Sorry, forgot to respond to this. Yeah, it works fine if set up correctly. Although spanning multiple versions of KiCAD can make it a pain with the config files madness you saw me questioning in the kicad forums a month or so back. I'm reevaluating my way to track libraries though, so maybe that will work better when I start moving more toward the more common workflow.

There are a couple of things to keep track of though other than the config files. Kicad does a few things only on close/open of files (i.e. no menu or refresh behavior) so when you swap commits/branches you need to close the project before or after this checkout.

For this case, I had an old version (e.g. v1) that I thought needed to be saved as a KiCAD 7.0 project before I could do the kiri diffs but now that I tested your -g flag, I see you've outdone yourself and kiri can compare across versions as well! :open_mouth: :clap: :clap:)

so I had a tag on v1, made a new branch just to update the config files etc. to 7.0. Then I have branch_v1, and branch_v2 on diverging branches, and was looking for a way to compare this (thus this question began).

I also use branches for working with other people. Theres definitely some things that can cause headaches for merge conflicts, but its definitely doable if you setup the project and manage it properly. I was doing schematic design and another person doing the pcb layout, and so long as you kept your commits clean (i.e. don't include changes to the PCB if working on the schematic, and vice versa) it worked quite well.

[leoheck]

Nice, thank you for this detailed answer.

There are a couple of things to keep track of though other than the config files. Kicad does a few things only on close/open of files (i.e. no menu or refresh behavior) so when you swap commits/branches you need to close the project before or after this checkout.

Indeed, I always think this is a bug or something haha

I also use branches for working with other people. Theres definitely some things that can cause headaches for merge conflicts, but its definitely doable if you setup the project and manage it properly. I was doing schematic design and another person doing the pcb layout, and so long as you kept your commits clean (i.e. don't include changes to the PCB if working on the schematic, and vice versa) it worked quite well.

I mean, if the branch does not have any other parallel work, then it works like a linear repo.. and then it is easy, but I always thought that having parallel branches would be hard to handle when conflicts arise since we work on a GUI and then the diffs are on Text. Which are different places to put your head in. Also, there are always different kinds of people/coworkers working and they are not always easy with text like us. Actually, I love Kicad because it has easy-to-use hotkeys (they are about to destroy this) and also it has files that are readable text, not binary blobs.

Is there a quicker way to update with git btw?

Hmm, I keep it always in the same place so it is always updated for me. But I think you can go to the folder where it is installed, and then git pull. This would be enough 90% of the time.. unless a new dependency was added then I think that running that command is easier.