-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
merge result when repo contains unstaged conflicting changes #389
Comments
Identified by Peter. Both workflowr and git2r can handle conflicting changes when the changes are committed. However, unstaged changes in conflicting files causes the git_merge_result object returned by git2r to behave unexpectedly. I opened an Issue on git2r to try to handle this upstream: ropensci/git2r#389 For now I catch this in workflowr and try to provide messaging similar to Git. I didn't display the problematic files because technically the print method does not have access to the location of the Git repo.
Identified by Peter. Both workflowr and git2r can handle conflicting changes when the changes are committed. However, unstaged changes in conflicting files causes the git_merge_result object returned by git2r to behave unexpectedly. I opened an Issue on git2r to try to handle this upstream: ropensci/git2r#389 For now I catch this in workflowr and try to provide messaging similar to Git. I didn't display the problematic files because technically the print method does not have access to the location of the Git repo.
Thanks for this suggestion. Yes, I agree that we should improve the handling of an unstaged conflicting change. It would be great if you can add tests and update the message returned for git_merge_result. |
I've been investigating this issue further so that I can handle it properly with my workflowr package. A few updates:
Here is the example code that additionally includes staged conflicting changes, committed conflicting changes, and the effect of
And here are the results of running this example on Ubuntu 18.04 with the latest version of the master branch 0.26.1.9000: Click to see results
|
However, things get more complicated when there are both unstaged and committed conflicted changes at the time of the merge. The expected behavior should be to alert the user that the unstaged changes need to be handled before the merge is able to complete (i.e. this is what Git does). Instead, this is the current git2r behavior:
Here is example code to reproduce the behavior described above. It creates the same file on two different branches. After merging the first, it edits the file to create an unstaged change. Then it attempt to merge the second branch which has committed conflicting changes.
Click to see my results
|
Currently
merge
is designed to handle the following situations:This is reflected in the messaging:
git2r/R/merge.R
Lines 112 to 120 in 11ad162
However, it does not handle well the situation in which there is an unstaged conflicting change. First, it somehow returns
NULL
forfast_forward
,conflicts
, andsha
. In PR #321 we decided that these should always return a logical, logical, and a character vector, respectively.Second, the message is not helpful; it only returns
Merge
. In contrast, here is the type of message that Git provides:Could we update
merge
to handle this case? Please let me know if you'd like me to add tests and update the message returned forgit_merge_result
. I already tried to figure out how these values were set toNULL
, but it looks like they were all properly initialized in git2r_merge.c. I assume we need to also initialize them for the scenario where there are unstaged conflicting changes.Here is a reproducible example:
And here is what I get when I run the example using git2r built from the current master branch:
Created on 2019-05-23 by the reprex package (v0.2.1.9000)
The text was updated successfully, but these errors were encountered: