Agilent MH12 method export

[kaipot]

No description provided.

[brendanx67]

Can we just make it so that the project in Executables uses the copy of the DLLs in the Methods folder to avoid having two copies? I think you should be able to make the project point at the other DLLs with a relative path containing ..\ parent folder navigation. Then the build system should be able to copy the DLLs from there.

[chambm]

@rita-gwen This PR changed every line of Resources.resx:
13,859 additions, 13,850 deletions not shown because the diff is too large. Please use a local Git client to view these changes.
Line endings I guess? Since it's already merged I'm not sure what the best path forwards is. @nickshulman What do you think?

[nickshulman]

I wonder why these line ending changes happen to Rita more than to anyone else.
The only thing that I have noticed which causes the line endings to switch to Unix is when I do a "Rename" using ReSharper.

By the way, if you want to see how much space a particular version of a file is taking up inside of the packfile, I think there is some information about how to use "git verify-pack" to do that here:
https://git-scm.com/book/en/v2/Git-Internals-Packfiles

[chambm]

So moving forward probably just a simple PR to revert the line ending changes? Otherwise every other PR that touches Resources.resx has to due a huge conflict resolution.

[nickshulman]

Yes, a separate PR to fix the line endings sounds like a good idea.
Merge conflicts caused by line ending changes are usually not that bad. The github website has no idea how to handle them, but if you resolve the conflicts using TortoiseMerge, it usually handles it automatically and tells you that there are no conflicts.

[rita-gwen]

Sorry about this, guys. There was a conflict in the Resources.resx file and Github was showing the whole file difference, so I used local merge. TurtoseGit conflict resolution editor apparently ignores the whitespace because it was showing the actual differences, so it was easy to resolve. I'm not sure why it keeps happening. I see "Inconsistent line endings" pop-up dialog in Visual Studio pretty often and I always cancel out of it, but I'm not sure if this is the cause or the effect. Do you think the fact that I mostly use the command line Git client instead of TurtoseGit can be relevant?

…

On Wed, Nov 29, 2023 at 10:40 AM nickshulman ***@***.***> wrote: Yes, a separate PR to fix the line endings sounds like a good idea. Merge conflicts caused by line ending changes are usually not that bad. The github website has no idea how to handle them, but if you resolve the conflicts using TortoiseMerge, it usually handles it automatically and tells you that there are no conflicts. — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/ProteoWizard/pwiz/pull/1344*issuecomment-1832494121__;Iw!!K-Hz7m0Vt54!lJcK5hhPBtlsiRph6QvFw6OiIABFBngn0fwoYIGq6QRGvl1wWq7P7iS1Az3Byurjew4pMXGHKy4E4Sku_Kqi4A$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFQG7D2JQJOK3SCOQVVCHTYG56RHAVCNFSM4UQZBMF2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBTGI2DSNBRGIYQ__;!!K-Hz7m0Vt54!lJcK5hhPBtlsiRph6QvFw6OiIABFBngn0fwoYIGq6QRGvl1wWq7P7iS1Az3Byurjew4pMXGHKy4E4SkG64Tn9A$> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Rita Chupalov *Software Developer* *at UW Genome Sciences Department*

[rita-gwen]

This is my global git config:

[core]
        autocrlf = true
        whitespace = cr-at-eol

[chambm]

The Github showing the whole file difference is the cue to look for that you had already committed the file with a line endings change. (You can also see it in the number of lines added and removed in the git status or TortoiseGit commit changes window.) I think TGit and git use the same core settings, so it's probably VS changing them. I also use autocrlf=true.

[rita-gwen]

Actually, I'm looking at Resources.resx before and after this commit and I do not see line ending differences. They both are all CR/LF.

[nickshulman]

Actually, I'm looking at Resources.resx before and after this commit and I do not see line ending differences. They both are all CR/LF.

In order to be able to see the line ending differences in the history, you need to turn off "AutoCrLf" in the git settings before you do the checkout.
I will forward you a copy of the "How to examine the line endings in files in the repository" email from last year.
When AutoCrLf is turned off the Tortoise diff will look like this, where there are different sorts of arrow characters at the end of the lines in the left and right panes.

[chambm]

TortoiseGit's "Show unified diff" can for some reason show the whitespace changes without changing autocrlf:
pwiz_tools/Skyline/Properties/Resources.resx | 23748 +++++++++++++------------
1 file changed, 11877 insertions(+), 11871 deletions(-)

diff --git a/pwiz_tools/Skyline/Properties/Resources.resx b/pwiz_tools/Skyline/Properties/Resources.resx
index a5bd6b724..a72b5805c 100644
--- a/pwiz_tools/Skyline/Properties/Resources.resx
+++ b/pwiz_tools/Skyline/Properties/Resources.resx
@@ -1,11871 +1,11877 @@

I'm guessing this got messed up when Kaipo did a merge from master with the wrong autocrlf setting, because I don't see any non-merge commits on this branch that make so many changes to Resources.resx.

[rita-gwen]

No, there are just few lines of change.
This is the PR: #2794
Could you guys have a quick look before I merge it. Looks right to me, but just to be sure.

[rita-gwen]

So, next time I see this dialog pop out should I just press OK and change everything to CR/LF?

[rita-gwen]

Thank you, guys, appreciate your help with this!