phil294
git squash multiple selected commits
would be nice to have for some but I don't know how the respective git command(s) for that would look like.
Squashing is possible with git of course, but since the multiple-commits-selection can have arbitrary gaps...
I don't know what the action should do here (git / basic bash commands) without rewriting the entire extension
Suggestion:
- Do not allow multiple selections (more than two) with Ctrl+click
- Allow selection of multiple commits (without gaps) with Shift+click - with that selection it's maybe easier to squash them
Do not allow multiple selections (more than two) with Ctrl+click
but it's really handy for cherry-picking and reverting them :/
Allow selection of multiple commits (without gaps) with Shift+click
that's already possible, but yeah, with gaps allowed
Do not allow multiple selections (more than two) with Ctrl+click
but it's really handy for cherry-picking and reverting them :/
Do you usually revert multiple commits at once?
Allow selection of multiple commits (without gaps) with Shift+click
that's already possible, but yeah, with gaps allowed
No, shift + click doesn't work with v0.1.14 on my machine...
No, shift + click doesn't work with v0.1.14 on my machine...
are you using MacOS?
No, shift + click doesn't work with v0.1.14 on my machine...
are you using MacOS?
No, Linux
As an initial iteration, could the squash action only appear when the selection has no gaps? That would be sufficiently useful for many (perhaps most) cases.
No, shift + click doesn't work with v0.1.14 on my machine...
@hansu is this still the case in the latest release?
As an initial iteration, could the squash action only appear when the selection has no gaps? That would be sufficiently useful for many (perhaps most) cases.
@SeijiSuenaga yes but main problem with this approach is that the concept of "gap" isn't distinct, as the ordering of commits depends on the sorting options currently set, and other branches' commits could be in the way. There's related discussion about this in #110. The continuitation logic would have to rely on Git's internal commit parent logic, but when it conflicts with the UI, that can be rather confusing. Shouldn't stop us from implementing this feature still.
No, shift + click doesn't work with v0.1.14 on my machine...
@hansu is this still the case in the latest release?
Works now, thanks!
Edit: But only when selecting from top to bottom - the other way around not.
Leaving aside the UI problem above, a non-interactive squash can be achieved using git reset --soft [commit id of parent of oldest commit to squash] && git commit. That can be done. But it would also be preferable to be able to squash older commits, not up to the current one. For that, only a scripted interactive rebase can be used, probably similar to the current "edit message" action: git commit --allow-empty --only -m "squash! [hash1]\nsquash! [hash2]" && git -c sequence.editor=: rebase -i --autosquash "[hash1]^" (not tested, just pseudo command). I'm not sure if doing it like this for the last n commits has any downsides compared to the first solution though.
Another challenge will be pre-filling the commit message field with the combination of the selected commits.