What's wrong
The log panel is the only place the app reports the git actions it runs: fetch, pull, commit, push, clone and propagation all report there through QueueGitLog/QueueLog. Two problems together make those reports hard or impossible to read.
-
The panel scrolls back to the bottom on every frame. ShowBottomPanel (ProjectDirector/ProjectDirector.cs:807-816) draws every line and then calls ImGui.SetScrollHereY(1) unconditionally:
if (ImGui.BeginChild("Log", ...))
{
LogQueue.ForEach(ImGui.TextUnformatted);
ImGui.SetScrollHereY(1);
}SetScrollHereY moves the scroll target to the current cursor position, which is the end of the log. Because it runs every frame, any mouse-wheel or scrollbar movement is undone on the next frame, and the panel can't be scrolled up.
-
The buffer is small, and a background job keeps filling it. QueueLog (ProjectDirector.cs:224-231) keeps at most LogLinesMax = 100 lines (:73). Meanwhile Tick calls FetchAllReposIfStale() on every frame (:690, :400). That fetches each cloned repository whose MinFetchIntervalSeconds has passed (the default is 60, GitRepository.cs:16). Each fetch logs at least one "[time] Fetching <remote>" line (:444), plus git's From … and ref-update lines when something changed.
Failure scenario
Suppose the dev directory holds 40 cloned repositories.
- The user clicks Push on one of them and the push is rejected as non-fast-forward.
QueueGitLog writes "[t] Pushing … failed" and git's four or five lines of explanation.
- The user can't scroll up to read it, because the panel returns to the bottom every frame. Once enough fetches have logged, the rejection has scrolled out of the visible area.
- Within about a minute the auto-fetch adds 40 or more
Fetching … lines. Within two minutes the push report has been dropped from the 100-line buffer altogether.
"Fetch All" and "Pull All" across the same 40 repositories cause the same problem on their own: every failure except the last few becomes unreachable.
Because the log is the app's only error channel, this undoes recent work: #415 and the "Pushing … failed" handling made failures reach the log precisely so they would not be silent.
This was traced from the code. It is ImGui drawing and can't be unit-tested headless. SetScrollHereY behaves as documented in Dear ImGui, and the demo's log window guards the call with GetScrollY() >= GetScrollMaxY() for exactly this reason.
Suggested fix
-
Auto-scroll only when the view is already at the bottom:
if (ImGui.GetScrollY() >= ImGui.GetScrollMaxY())
{
ImGui.SetScrollHereY(1);
}Place this after the lines are drawn.
-
Stop background fetches from flooding the log. Either skip the Fetching … header for a timer-driven fetch that succeeded with no output, or collapse a whole sweep into one Fetched N repositories (M failed) line. Keep the full output for failures and for fetches the user started.
-
Consider raising LogLinesMax, since 100 lines is small when one git failure takes five or more. Alternatively, keep failures separately from routine output.
Acceptance criteria
- The user can scroll the log up, and it stays where they left it until they scroll back to the bottom.
- With 40 cloned repositories left idle for five minutes, a push failure logged at the start is still in the buffer.
What's wrong
The log panel is the only place the app reports the git actions it runs: fetch, pull, commit, push, clone and propagation all report there through
QueueGitLog/QueueLog. Two problems together make those reports hard or impossible to read.The panel scrolls back to the bottom on every frame.
ShowBottomPanel(ProjectDirector/ProjectDirector.cs:807-816) draws every line and then callsImGui.SetScrollHereY(1)unconditionally:SetScrollHereYmoves the scroll target to the current cursor position, which is the end of the log. Because it runs every frame, any mouse-wheel or scrollbar movement is undone on the next frame, and the panel can't be scrolled up.The buffer is small, and a background job keeps filling it.
QueueLog(ProjectDirector.cs:224-231) keeps at mostLogLinesMax = 100lines (:73). MeanwhileTickcallsFetchAllReposIfStale()on every frame (:690,:400). That fetches each cloned repository whoseMinFetchIntervalSecondshas passed (the default is 60,GitRepository.cs:16). Each fetch logs at least one"[time] Fetching <remote>"line (:444), plus git'sFrom …and ref-update lines when something changed.Failure scenario
Suppose the dev directory holds 40 cloned repositories.
QueueGitLogwrites"[t] Pushing … failed"and git's four or five lines of explanation.Fetching …lines. Within two minutes the push report has been dropped from the 100-line buffer altogether."Fetch All" and "Pull All" across the same 40 repositories cause the same problem on their own: every failure except the last few becomes unreachable.
Because the log is the app's only error channel, this undoes recent work: #415 and the "Pushing … failed" handling made failures reach the log precisely so they would not be silent.
This was traced from the code. It is ImGui drawing and can't be unit-tested headless.
SetScrollHereYbehaves as documented in Dear ImGui, and the demo's log window guards the call withGetScrollY() >= GetScrollMaxY()for exactly this reason.Suggested fix
Auto-scroll only when the view is already at the bottom:
Place this after the lines are drawn.
Stop background fetches from flooding the log. Either skip the
Fetching …header for a timer-driven fetch that succeeded with no output, or collapse a whole sweep into oneFetched N repositories (M failed)line. Keep the full output for failures and for fetches the user started.Consider raising
LogLinesMax, since 100 lines is small when one git failure takes five or more. Alternatively, keep failures separately from routine output.Acceptance criteria