-
No comment -
There is currently no setting to enable this. OneDev's diff viewer shows line numbers and surrounding unchanged lines (which can be expanded), but it does not display the enclosing function/class context as a Git-style hunk header.
To make sure the proposed feature matches what you expect:
- Where should the enclosing code context appear?
Number Option short title Explanation Pros Cons 1️⃣ A. Per-hunk header (recommended) Show the nearest enclosing function, method, or class in a header for each collapsed group of changes, similar to the text after @@ ... @@in a Git diff.✅ Familiar Git-style behavior; ✅ compact; ✅ each change group has clear context ⚠️ The label may scroll out of view in a long hunk 2️⃣ B. Sticky context Keep the current function/class visible at the top of the diff while scrolling through its lines. ✅ Context remains visible while scrolling; ✅ useful for long changes ⚠️ Uses more screen space; ⚠️ more complex behavior when old and new sides are in different symbols 3️⃣ C. Both Add a label to each hunk and also keep the active label visible while scrolling. ✅ Most context in all situations ⚠️ More visual and implementation complexity Please reply with 1A, 1B, or 1C.
-
- c
I realize that this is a complex change and can result in an issue, especially if all the new sides are in different symbols. Therefore, it may be prudent to consider having the old and new sides' stickiness as separate elements rather than combining them into one sticky element.
Don't assume. Ask high-level clarifying questions if needed.
- Numbered questions (1, 2, 3, etc)
- Lettered answer options (A, B, C, etc)
- Include a markdown table that contains the following for each option:
- number (with an emoji that represents your recommended option)
- Option short title
- Explanation (don't assume my level of knowledge).
- Pros (with relevant emojis)
- Cons (with relevant emojis)
-
No comment
-
That makes sense. For split view, the old and new sides should use independent sticky context elements, so each side can show the symbol that applies to its own revision. The per-hunk headers would likewise identify old and new context separately when they differ.
- How should the sticky context behave in unified view, where old and new lines share one column?
Number Option short title Explanation Pros Cons 2️⃣ A. Separate old/new labels (recommended) Show two compact, clearly labeled sticky elements: one for the old revision and one for the new revision. Each updates independently as its corresponding lines scroll. ✅ Preserves both contexts when a change moves between symbols; ✅ consistent with split view ⚠️ Uses more vertical space; ⚠️ one label may occasionally have no applicable visible line 2️⃣ B. One active label Show one sticky element based on the old or new line currently nearest the top of the viewport. ✅ Compact; ✅ simpler to scan ⚠️ Context can switch while scrolling; ⚠️ may hide that the two revisions are in different symbols 2️⃣ C. Sticky context only in split view Keep per-hunk context in both layouts, but provide sticky old/new context only in split view. ✅ Avoids ambiguity and extra height in unified view ⚠️ Unified view loses the always-visible context requested for long hunks Please reply with 2A, 2B, or 2C.
-
- a
Don't assume. Ask high-level clarifying questions if needed.
- Numbered questions (1, 2, 3, etc)
- Lettered answer options (A, B, C, etc)
- Include a markdown table that contains the following for each option:
- number (with an emoji that represents your recommended option)
- Option short title
- Explanation (don't assume my level of knowledge).
- Pros (with relevant emojis)
- Cons (with relevant emojis)
-
Understood. The requested behavior is now:
- Show both per-hunk context and sticky context.
- In split view, keep the old and new revision contexts in independent sticky elements.
- In unified view, show two compact, clearly labeled old/new sticky elements that update independently.
There is no existing setting that provides this, so fulfilling the request requires a product and implementation decision. @robin, could you review this feature request?
-
@servicedesk since the design has been finalized, it would be more prudent to close this issue and create a new one with the new finalized design. It might also be helpful to create ASCII diagrams that show the old UX versus the proposed UX, including the use of pseudocode to demonstrate the value of having the diff context being present. Ensure that the new issue appropriately contains the motivation behind this change.
-
Assign the new issue to Robin.
-
-
-
The configuration question is answered: OneDev does not currently provide enclosing function/class context in its diff viewer. The finalized feature design, motivation, pseudocode example, and old-versus-proposed ASCII diagrams have been moved to issue #3090. It is assigned to @robin, and all three watchers from this issue were carried over.
-
Previous Value Current Value Open
Closed
-
@zaakiy, I created new feature issue #3091 with the finalized design, the motivation for the change, old-versus-proposed ASCII UX diagrams, and a pseudocode example demonstrating the value of diff context. I assigned it to @robin and carried over all watchers from this issue. Closing this question as requested.
| Type |
Question
|
| Priority |
Normal
|
| Assignee | |
| Labels |
No labels
|
In popular Git pagers such as Git-delta, it is able to display the context of the current lines being displayed, including the name of the function, the name of the class, and so on. However, OneDev does not natively do this. When I'm looking at a
git diff, I can't tell which function the individual line changes are in. If there is no way to enable this, can we add this feature so that it's on by default?Don't assume. Ask high-level clarifying questions if needed.