The improvements prompted by #588 are plainly quite important. I am glad a successful implementation was achieved.
However, even when "fixup" commits appear in the history, it is not desirable in every cases to apply them in the very next interactive rebase. The Git command-line interface only applies "fixup" commits automatically if the rebase operation is passed the option --autosquash. Otherwise, commits labeled fixup! or amend! receive no special handling.
Similarly, I suggest that SourceGit apply the special commits only if a particular button is pressed in the window for preparing an interactive rebase.
In actual fact, I find three distinct cases commonly of interest. In addition to applying "fixup" commits, and not treating them specially, a third case is applying the reordering without applying the squashing. However, simply supporting the two cases supported by natively by Git would be entirely adequate.
The improvements prompted by #588 are plainly quite important. I am glad a successful implementation was achieved.
However, even when "fixup" commits appear in the history, it is not desirable in every cases to apply them in the very next interactive rebase. The Git command-line interface only applies "fixup" commits automatically if the rebase operation is passed the option
--autosquash. Otherwise, commits labeledfixup!oramend!receive no special handling.Similarly, I suggest that SourceGit apply the special commits only if a particular button is pressed in the window for preparing an interactive rebase.
In actual fact, I find three distinct cases commonly of interest. In addition to applying "fixup" commits, and not treating them specially, a third case is applying the reordering without applying the squashing. However, simply supporting the two cases supported by natively by Git would be entirely adequate.