Fix cu_hxr energy gain profile calculation

[williamColocho]

A few bugs introduced while reworking the code.

[nneveu]

I'm not sure I see what changed in the model_general_calcs.py file? Maybe an accidental addition to this commit/PR?

[nneveu]

This file is already on this repo with these functions? Maybe this wasn't meant to be updated?

[nneveu]

Also, let me know if you want help resolving the conflicts.

[williamColocho]

I would like to help resolving the conflicts. I don't fully understand being ahead and behind. What should my regular workflow be to stay on the main branch? William

…

________________________________ From: Nicole ***@***.***> Sent: Thursday, November 21, 2024 9:28 PM To: slaclab/lcls-tools ***@***.***> Cc: William S. Colocho ***@***.***>; Author ***@***.***> Subject: Re: [slaclab/lcls-tools] Fix cu_hxr energy gain profile calculation (PR #204) Also, let me know if you want help resolving the conflicts. — Reply to this email directly, view it on GitHub<#204 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKR74QVONV2JL6ERMHN6A4T2B26INAVCNFSM6AAAAABRLRDBQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJSHEYDGNZUG4>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[robnagler]

I don't fully understand being ahead and behind.

Ahead means that the branch has changes that are not yet added to main, i.e. the changes you desire to add to main in the PR.

Behind means that the main branch has changes that have yet to be merged into your branch, i.e. other PRs being merged into main since you started development (or the last time you merged main).

What should my regular workflow be to stay on the main branch?

Merge main into your working branch every day before beginning work and possibly multiple times in a day, depending on the state of the branch. Depending on the complexity of changes, you may be able to rebase (apply your changes on top of any new changes in main) instead of merging. This avoids interleaved changes when the PR is created.

Personally, for larger projects, I always merge and resolve conflicts, and then I recreate a new branch with a squash merge just before the PR. This way there's a single commit with a cohesive description for the PR, which can help reviewers. My branches tend to be very messy, because I commit multiple times in a day to backup my work.