git-imerge: update for the latest version

[abitrolly]

• The page is in the correct platform directory (common/, linux/, etc.)
• The page has 8 or fewer examples.
• The PR title conforms to the recommended templates.
• The page follows the content guidelines.
• The page description includes a link to documentation or a homepage (if applicable).

Version of the command being documented (if known): 1.2.0

[abitrolly]

@navarroaxel thanks for review. These edits were made in hurry, and that's the consequences. (

[waldyrious]

Hmm, I disagree with this change. The first part of the sentence ("Abort imerge operation") already refers to the cleaning up of the temporary commits. I don't think we need to specify that detail, especially since there's no mention of temporary commits before this.

In the same vein, I think it is better to keep the second part of the sentence and command, i.e. the extra step of returning to the original branch, as otherwise users would be left in a detached HEAD state. This is in fact recommended in the tool's documentation.

There are two issues for implementing a proper imerge-aborting subcommand (mhagger/git-imerge#123 and mhagger/git-imerge#189) but until then, this should not be presented stand-alone as if it were a fully supported operation of the git-imerge tool — it's more like plumbing.

[abitrolly]

Maybe replace that with git rebase --abort? If I remember correctly, it returns to the original branch automatically.

There are some things I need to do before I can check and confirm the behavior.

[waldyrious]

I don't think git rebase --abort would work; IIUC, the imerge operations aren't registered by git as a regular rebase. But do test and let us know :)

[abitrolly]

Well, I haven't used the merge capability, only rebase, and right now I don't have any PRs that need conflict resolution to test this. Looks like writing tests https://github.com/mhagger/git-imerge/tree/master/t would take a few hours, and I need them to complete other things.

Basically the testing plan.

1. start rebase on a conflicting branch
2. wait for terminal drop out for conflict resolution
3. use remove and see if git switched back to conflicting
4. check if temp branch is still there

1. start merge on a conflicting branch
2. wait for terminal drop out for conflict resolution
3. use remove and see if git switched back to conflicting
4. check if temp branch is still there

1. start rebase on a conflicting branch
2. wait for terminal drop out for conflict resolution
3. use git rebase --abort and see if git switched back to conflicting
4. check if temp branch is still there

1. start merge on a conflicting branch
2. wait for terminal drop out for conflict resolution
3. use git merge --abort and see if git switched back to conflicting
4. check if temp branch is still there

[waldyrious]

Tests for imerge would be awesome! Alternatively, in case writing the tests proves too burnensome, @mhagger himself could confirm whether git rebase --abort is a viable alternative to manually git checkouting (or git switching) to the previous branch.

[github-actions]

Hi all! This thread has not had any recent activity.
Are there any updates? Thanks!

[github-actions]

Hi all! This thread has not had any recent activity.
Are there any updates? Thanks!

[github-actions]

Hi everyone.
This thread is being closed as there was no response to the previous prompt.
However, please leave a comment whenever you're ready to resume, so the thread can be reopened.
Thanks again!

[abitrolly]

I failed. Not sure I could address this even if being paid. It is just too complicated to resolve without spending a few days on answering all questions. I checked "Allow edits by maintainers", so feel free edit and commit it in any flavor. If it is not too late of course.