Suggestions for sprint time estimates vs. issue time estimates

I am soliciting suggestions on how to track total time estimates for an issue vs. time estimates for the same ticket during a shorter sprint period. That is, a “total estimate” vs. “sprint estimate” distinction would be helpful. Currently, my team uses “/estimate” to estimate the total size of an issue. Then, when we tackle part of an issue in a specific sprint, we use weight to enter the hours for the current sprint only. For example, a larger issue might be 40h (entered with “/estimate”), but if we tackle only an 8hr portion of that in our one-week sprints, we then assign a weight of 8. The total estimate helps planning on a longer time scale (e.g. quarterly capacities for team members), while the shorter sprint-based weight-based estimate is used for capacity planning in the shorter sprints. Maybe there is a better way to handle this distinction between time needed for an entire issue vs. time needed for a subset of that issue? We sometimes split larger issues into smaller issues, but this causes problems since it is sometimes critical to maintain all information about an issue within that single issue, rather than juggling N issues and spreading knowledge on that issue across multiple issues (also, splitting issues results in more convoluted time tracking for all of the issues [e.g. to avoid double-accounting you have to assign 0hrs for the “parent” issue, then actual hours for the child issues, etc.]). It would be nice to have a separate “sprint estimate” attribute for issues as a GitLab feature, but until that is rolled out by the GitLab development team, please share your workflow or methodologies on how you track this in GitLab.