Skip to content

Introduce 'dry-merge' command #141

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

Closed
wants to merge 1 commit into from

Conversation

willi-mueller
Copy link

I would appreciate a command to check if a merge can be performed automatically or which files need manual merging. In this pull request I already implemented a simple version of it.

Proposal:

git dry-merge <branchname> prints which files can be automatically merged and which files need a manual merge.

Current Implementation

It currently just runs

git merge --no-commit --no-ff $1
git merge --abort # to unstage automatically merged files

Future Work

It should check the result of git merge --no-commit --no-ff $1. If it states 'Already up-to-date' it exits and prints no 'fatal: There is no merge to abort (MERGE_HEAD missing)'.
In addition it should not stop at the first 'error: Your local changes to the following files would be overwritten by merge' and just print one file that would be overwritten but ALL the files that would be overwritten.

What is your opinion about it?


Note: I was inspired by: http://stackoverflow.com/questions/501407/

It shows if an automatic merge would succeed and which files could be automatically merged.
It stops at the first conflict which needs a manual merge.
Including bash completion for dry-merge.
@domoritz
Copy link

domoritz commented Oct 7, 2012

Interesting idea. What is the use-case for such a command? Would you use it before you do a merge?

If your answer is yes, I just wonder if another approach which involves "asking for forgiveness instead of permission" would be more sensible. I chose the optimistic approach, which is doing the merge and if something goes horribly wrong just git reset --merge. This way I only need one command in case the merge works fine (which should be the case in 98% of all cases) and two commands if something goes horribly wrong.

I can see the use case in situations where you cannot afford to risk a conflict during a merge (such as shell scripts).

@willi-mueller
Copy link
Author

My main use case is when working on a feature branch feature/foo. Ideally I want to see if there were conflicts introduced between feature/foo and feature/bar. I want to see a list of files or even better: the exact lines. Then I can rethink what I am about to do and ask my colleagues working on feature/bar because I know our versions diverged. In addition I know if I may need help for a merge before starting it.

All in all I see it as a complement to git diff which shows me all the differences, not just the conflicts.

And yes, git reset --merge seems to be more what I want. Thanks for that remark, I'll investigate it further.

@hemanth
Copy link
Collaborator

hemanth commented Jul 9, 2014

@jups23 Still interested?

@github-actions github-actions bot added the Stale label Apr 26, 2025
Copy link

This PR was closed because it has been stalled for 365 days with no activity. Feel free to make a new PR if you wish to continue

@github-actions github-actions bot closed this May 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants