Add functionlity to move commit(s) up/down the commit history

[luzpaz]

Describe the solution you'd like
The ability, through the interface (RMB dialog), to highlight (a) commit(s) and move it/them up or down the commit history of a branch.

Describe alternatives you've considered
Very tediously: creating a tempbranch, cherrypicking specific commits (from the target branch) that are 'in the way' in to temp branch, dropping the commits in question from target branch, then recommitting them from temp branch in the wanted.order back to the target branch.

Additional context
This feature can exist under/next to the squash functionality (#14) once it's implemented. Also it could be smart enough to move single or groups of commits (when highlighted) up or down the commit history. It could be context sensitive so that if the commit in question is the last commit, clicking on the RMB will only offer Move commit down and not display both option including Move commit up.

[francescmm]

Hi @luzpaz I'll start working on this soon-ish. The functionality, although hidden behind a UI as you describe will perform the exact Git operations you are describing, so it could be a very highly demanding thing to do and not as UI-responsive as one might think.

[luzpaz]

Hi @luzpaz I'll start working on this soon-ish. The functionality, although hidden behind a UI as you describe will perform the exact Git operations you are describing, so it could be a very highly demanding thing to do and not as UI-responsive as one might think.

@francescmm sweet!
Understandably so, it may merit some form of visual feedback wait cursor/graphic as well...I'd imagine

[hartwork]

Alternatively, this could be using git rebase -i under the hood where changing order of commit is already supported. Just an idea.

[francescmm]

Hi @hartwork, the interactive mode requires to send the different parameters needed back to git. I'm not sure is supported right now even via the standard input channel.

[hartwork]

@francescmm I would adjust GIT_EDITOR and put lines with commit SHA1s in the right order preceded by "pick " into the right file location on disk, done. What am I missing?

[francescmm]

I might not be following you, so correct me if I'm wrong:

GIT_EDITOR is the editor to be used, but nothing else, and GitQlient doesn't know about external editors for now.

How GitQlient works is by running a background process to execute git commands. With the interactive I cannot access the "live" terminal workflow. When the git command finishes (or the editor - vim, nano, or UI-based) is closed, the changes are saved.

So in the case of GitQlient, when the command git rebase -i interactive finishes the execution it will do the same. The problem is that executing git via an external process doesn't allow to provide feedback even if the option passed is the interactive mode.

I know that git creates all the files for the rebase and keeps them in a folder named .git/rebase-merge. One idea would be to modify those, but again, I would have to synchronize with the background execution.

[hartwork]

@francescmm sorry, I meant EDITOR not GIT_EDITOR. You can use git rebase -i in a non-interactive way e.g.:

EDITOR='sed -i "2,$ s|^pick |fixup |"' git rebase -i 86e0984f2b73509bb48608f4c4f65cfc12facff0  # needs GNU sed

That's what I was referring to, the example is from libexpat/libexpat#439 (review) .
To make it work, you could either write a tiny program for EDITOR that waits until it receives a signal from GitQlient so that GitQlient can write the file and have Git process it, that would be cross-platform. If this was only Unix or with Bash available, you could auto-generate a command for EDITOR to write the needed file on the fly (..).
Maybe it's too much of a hack 🤷 Just an idea 🍻

[francescmm]

Oh, I'm gonna check that! :D If I manage to do everything "internally" in GitQlient it would be a win-win! Thanks, @hartwork !

[luzpaz]

Any progress here ?

[francescmm]

No progress so far on this, sorry. One of the things that makes it more difficult to implement is the case where a merge is among the commits to rewrite. I'm thinking on not allowing that since this is not a native move as it would happen when doing an interactive rebase.