this post was submitted on 17 Jun 2024
9 points (84.6% liked)

VS Code

806 readers
1 users here now

founded 1 year ago
MODERATORS
 

I need to be able to see the difference between the current working file and the previous commit as I am editing the file. The only history plugins I can find either use pop-ups (which disappear when I start typing) or a dedicated diff-view which takes up too much space on my small monitor.

you are viewing a single comment's thread
view the rest of the comments
[–] Lodra 1 points 5 months ago (2 children)

Can you give an example of the change and your comment for a single file?

2000 is a lot of files. If you need to do this often, it might be best to build a small cli tool to make this easier or fully automated. It really depends on how you choose to create those comments.

[–] [email protected] 2 points 5 months ago (1 children)

They are XML files and changes would be things like added or removed elements or changed attribute values. So e.g.: Version 1:

[...]
<Dynamo vendor="Siemens" max-rotation=12>
[...]
<Light colour="white">
[...]

Version 2:

[...]
<Dynamo vendor="Siemens" max-rotation=16>
[...]

The comments would look like:

[...]
<!-- %ATTCHANGE :: max-rotation=12 :: #ACCEPTED see report 12.24/2 -->
<Dynamo vendor="Siemens" max-rotation=16>
[...]
<!-- %REM :: <Light colour="white"> :: #ACCEPTED see report 12.24/4 -->
[...]

I make the changes while going through the report (hardcopy only) which is basically an engineering report that outlines changes made to a factory (12.24/4 means chapter 12, section 24 item 4 which would list the old and new device/machine or the changes made etc. in a technical manner). It's manual work, which is fine (I get paid by the hour). Just want it to be a bit more streamlined.

[–] Lodra 1 points 5 months ago (1 children)

Well this is definitely a bit odd. Send like those comments should be included with the original change. Or maybe they shouldn’t be recorded as comments at all and they should be a git commit message. And where does that hard copy report come from? Anyways, back to your actual question.

At this point, I’m still suggesting a tiny utility to assist with adding the comments. It looks like %ATTCHANGE and %REM are part of a very sort list of possible values. If so, a little cli tool can definitely help there. It could also handle the general comment structure and the changed value easily. Do these comments ever include something besides #ACCEPTED?

The tricky part is the ‘12.24/4’. It sounds like you go through the report and then find the files/lines to create these comments. Is that right? It would be tricky to code a cli tool for doing that because you need to jump around between files.

Last note for now, some simple git commands can definitely help you here. You could easily generate a list of changed files and lines. Another could show you the changed text. For any given change. Etc.

[–] [email protected] 1 points 5 months ago* (last edited 5 months ago) (2 children)

I am no git- expert; I mostly just branch and commit, that's the extent of my knowledge. Can you point me into the direction of some information regarding this (specific commands I could use?)

And 'Odd' is an understatement ;P these files are fairly old (I oldest was made in 1999 and the last version was from 2002) and the client was lucky they found the initial set and the last version on separate backups (floppies !). What we initially did was commit the initial version and then overwrite them with the latest version and commit again. So we now have a git history of the difference between the originals and the revisions. My job is to check if the final version is correct e.i either conform the work specification of the time (report), or any of the revisions (as-built) since then. And then create a comment that can be read by both the operator console and the archive-system. My best guess is someone's nephew created this program because why anyone would use XML for this is beyond me, although I guess in 1999 this was state-of-the-art? And no one wants to touch that codebase with a 5ft pole, lol. Anyway, the comments are parsed in a specific and precise way.

EDIT: As for your question about #ACCEPTED. The rules are "simple" each comment should start with either %ATTCHANGE, %REM, %ADD or %NOTE then 2 colons, then the old element (complete) or the ols attribute (seperated) or the note, then again 2 colons and last either #ACCEPTED, #DENIED or #REVIEW. Reveiw is followed by any text explaining why it needs reviewed, and denied and accepted are followed by either "see report xxxxx" or "as-built xxxxx" where xxxx is some reference.

[–] Lodra 2 points 5 months ago* (last edited 5 months ago) (1 children)

I’m on my phone so I can’t really test these out. But this should give you a few methods for printing the list of files changed.

Here’s a similar page to show the changes for a specific file. I expect that git blame will be similarly useful.

A few others that may help you get started as well:

git —help
git rev-parse
git log
git history
[–] [email protected] 2 points 5 months ago (1 children)

thanks so much for your help.

[–] Lodra 1 points 5 months ago

My pleasure. Thanks for posting! And feel free to ask more questions as you tackle this one.

[–] Lodra 1 points 5 months ago (1 children)

Yikes! Is this a one-time task?

[–] [email protected] 1 points 5 months ago
[–] thesmokingman 1 points 5 months ago

That’s honestly what I’d recommend. I think a quick way to do it would be to create patches from the diffs, run the patches through awk, and apply the patches.