Add a "status" operation

[dwijnand]

When there is a merge conflict that must be resolved a very helpful message gets output. Then I start looking at the two commits, trying to understand what they were trying to do, before going to the mergetool to solve them.

The problem is that if I want to go back to see, for instance, the other commit, I need to scroll up the terminal buffer to find that original helpful message. It would be nice if there were a "status" operation of imerge that can output that again.

Thanks

[mhagger]

That's a great idea, and one that somebody else has also wished for. If you would like to work on it, I would be happy to help you get started.

[dwijnand]

I would like to work on it, but have a bit too much on my plate at the
moment. :(

On 20 July 2013 15:58, Michael Haggerty [email protected] wrote:

That's a great idea, and one that somebody else has also wished for. If
you would like to work on it, I would be happy to help you get started.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-21294770
.

[jrdavid]

I would like that feature as well. I guess that information shouldn't be too hard to extract from MergeState? If you give me a pointer or two I'd be happy to contribute.

[mhagger]

@jrdavid: Cool that you want to work on this; here's some info to get you started:

The state of the imerge as a whole is stored in the MergeState object--except for information about the micromerge that is currently in progress. This is by design, because if the user aborts the merge or manually initiates another merge and then types git-imerge continue, git-imerge has to figure out how to proceed based on the state of the repo at that time, not the state of the repo the last time git-imerge ran.

So if you look at the code for 'continue', you will see that it calls incorporate_user_merge(), which is responsible for figuring out which micromerge (if any) was just finished by the user and recording the resolution in the MergeState object.

incorporate_user_merge() finds the commit pointed at by the reference refs/heads/imerge/NAME and passes it to MergeState.incorporate_manual_merge(). The latter checks that the commit is a merge, and if so looks for its parents among the micromerges that have been recorded previously and converts them into indexes:

(i1first, i2first) = self.find_index(parents[0])
(i1second, i2second) = self.find_index(parents[1])

This locates where the just-completed merge is located in the merge graph. From there, it would be easy to output information about the original commits that are being merged, similar to what is done in request_user_merge().

However, the "status" command that you want to implement can't start from a merge commit, because the manual merge hasn't been done yet. Instead it will have to find out, from Git, if a merge is currently in progress and if so, what two commits are being merged. The first parent of an in-progress merge, of course, is stored in HEAD and can be determined via git rev-parse HEAD. The second can be determined by reading the file .git/MERGE_HEAD, which, if it exists, lists the second "HEAD" of the in-progress merge. (If the file doesn't exist, then no merge is in progress. If the file has more than one line, then an octopus merge is in progress, in which case the "status" command would have to report that no micromerge is in progress).

Then stick those two commit SHA-1s into MergeState.find_index(), to deduce which micromerge is in progress, and report the original log message using code like that in request_user_merge().

I hope that helps! If you have any questions, don't hesitate to ask.

[mhagger]

This issue has interesting discussion in it, but is otherwise superseded by issue #33.