-
Notifications
You must be signed in to change notification settings - Fork 8
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
[Q] Why can't i merge next into master? #5
Comments
I am doing this manually so that I understand what you were talking about without using your aliases. kkkk just noticed one reason why one should not do this or actually why you may want to do this. When the pu/next branches are merged into master, the default merge log messages that say "merged blah/topic into next" will remain in the log history. I think this can be used for posterity to know if a topic went thru the normal cycle if so desired, but it is not as clean as when the topic branches mergers are done on the master branch directly. The only problem I was having was the order of the merges. Actually I noticed that I had to do the merges in the order they were done in the working next branch otherwise some unexpected changes will happen to the code. eg if you have two topics' commits that do changes to the same file and you commit the last commit first and the earlier one last, it will remove the changes that the later commit does and leave the working tree unclean. To get around it I just followed the merge commits as they happened in next. Whether I to do them one by one or as a group of commits in a single merge, I had to do them in that order i see in But maybe you could give a more educated reason why one should not merge next or pu directly onto master. |
@emahuni Yes, I would say the primary reason is to keep the Merging the individual topics into
The subsequent command has to be run multiple times in case of intermediate conflict resolutions -- however it works well as a repeatable idempotent command (git reports "up-to-date" for branches already merged). Another tip: if you were not the one to do all the merges into
This is the kind of thing for which we should add scripts into this repo, but I'd like them to soak and/or get feedback from people such as yourself before doing that. Let me know how it goes. |
oh ok. just what i was after. |
I remember you mentioning this in your tute, but you didn't explain why.
Ok, I have the four branches and I have created a topic and all went well. Then I went thru pu and then next processes. Did the same to other nine topics and eventually had 10 of them.
Now we want to cut a release after CI passes on next. If I got it right you said master and next never merge nor does pu and next nor pu and master. It means I have to merge those topic branches one by one into master, so why not just merge next into master seeing that is the state of the project we want to release?
The keyphrase here is:
What's wrong with that since they all have a common ancestor?
Will something bad happen when we reset next and pu to master?
Is there a caveat in
git checkout master && git merge --no-ff next && git checkout next && git reset --hard master
approach, when the state of next branch is what we want to release?The text was updated successfully, but these errors were encountered: