Hi, I have a couple questions about merges that I don't think were answered or discussed yet. - Suppose I make a change in the superproject, bootstrap.sh, on develop branch, due to Boost.Build change. I also want to merge it to master, but I can't really use 'git merge', since it will merge references to 'develop' versions of all components - not something we want to do. It appears cherry-pick is what I want to do. I think that's not a problem, as we never modify 'master' directly, and therefore we won't get any merge conflicts in future. Does anybody see a problem? - Suppose next release is nearing, and I've tested 'develop' branch of my library, and it works fine. I want to put it on master (whether I use intermediate release branch is not relevant here). Gitflow say to use something like this: git merge --no-ff release-1.2 I imagine that most people want 'master' to be identical to 'develop', or to 'release-1.2', after such merge, and the above command does not guarantee that. In past, I could use git merge -s theirs release-1.2 which would make current branch identical to the branch we're merging. But then, git folks decided they don't like this flexibility, like this: http://marc.info/?l=git&m=121637513604413&w=2 and removed 'theirs' merge strategy. What this presumably means, is that I shall do this instead git merge -no-ff release-1.2 git diff HEAD release-1.2 and if the last command reports any difference, go and fix them by hand. This might be actually better than '-s theirs', in that if any fix is mistakenly put to 'master' but not merged to 'develop', this diff will find it, whereas '-s their' will silently wipe it away. But anyway, this 'git diff' invocation probably shall be documented. Am I missing something? Thanks, Volodya
On 12/18/2013 08:24 AM, Vladimir Prus wrote:
- Suppose I make a change in the superproject, bootstrap.sh, on develop branch, due to Boost.Build change. I also want to merge it to master, but I can't really use 'git merge', since it will merge references to 'develop' versions of all components - not something we want to do. It appears cherry-pick is what I want to do. I think that's not a problem, as we never modify 'master' directly, and therefore we won't get any merge conflicts in future. Does anybody see a problem?
If you want to merge a single file, you could use git checkout master git checkout develop bootstrap.sh Disclaimer: I have not used the above myself.
On 18.12.2013 14:57, Bjorn Reese wrote:
On 12/18/2013 08:24 AM, Vladimir Prus wrote:
- Suppose I make a change in the superproject, bootstrap.sh, on develop branch, due to Boost.Build change. I also want to merge it to master, but I can't really use 'git merge', since it will merge references to 'develop' versions of all components - not something we want to do. It appears cherry-pick is what I want to do. I think that's not a problem, as we never modify 'master' directly, and therefore we won't get any merge conflicts in future. Does anybody see a problem?
If you want to merge a single file, you could use
git checkout master git checkout develop bootstrap.sh
Disclaimer: I have not used the above myself.
This is roughly equivalent to cherry-pick, except I need to commit by hand and copy the commit message by hand. - Volodya
On 18 December 2013 07:24, Vladimir Prus <ghost@cs.msu.su> wrote:
- Suppose I make a change in the superproject, bootstrap.sh, on develop branch, due to Boost.Build change. I also want to merge it to master, but I can't really use 'git merge', since it will merge references to 'develop' versions of all components - not something we want to do. It appears cherry-pick is what I want to do. I think that's not a problem, as we never modify 'master' directly, and therefore we won't get any merge conflicts in future. Does anybody see a problem?
There's a problem, but there's a simple solution. Just move content out of the super-project. Scripts in the super project should just call a script from a submodule which does all the work. Then track what's left manually - make sure there's little to track so that it shouldn't be too hard. Other than that you'll just have to deal with it manually. Another solution is to use Peter Dimov's suggested work flow, since with that master was merging in changes from develop. The latest/unstable branch could be automatically updated with changes from develop.
- Suppose next release is nearing, and I've tested 'develop' branch of my library, and it works fine. I want to put it on master (whether I use intermediate release branch is not relevant here). Gitflow say to use something like this:
git merge --no-ff release-1.2
I imagine that most people want 'master' to be identical to 'develop', or to 'release-1.2', after such merge, and the above command does not guarantee that.
Generally git-flow ensures that everything in master has been merged into develop, since hotfixes and release branches are merged into both master and develop. So I think they can only diverge if you've been doing tricky things, such as a hotfix which results in a merge conflict. In which case you really should be checking that the merge result manually before pushing.
I could use
git merge -s theirs release-1.2
which would make current branch identical to the branch we're merging. But then, git folks decided they don't like this flexibility, like this:
http://marc.info/?l=git&m=121637513604413&w=2
and removed 'theirs' merge strategy.
I don't agree with the reason for removing '-s theirs', but you can still use 'git merge -s ours master' from your release branch.
On 18.12.2013 15:48, Daniel James wrote:
On 18 December 2013 07:24, Vladimir Prus <ghost@cs.msu.su> wrote:
- Suppose I make a change in the superproject, bootstrap.sh, on develop branch, due to Boost.Build change. I also want to merge it to master, but I can't really use 'git merge', since it will merge references to 'develop' versions of all components - not something we want to do. It appears cherry-pick is what I want to do. I think that's not a problem, as we never modify 'master' directly, and therefore we won't get any merge conflicts in future. Does anybody see a problem?
There's a problem, but there's a simple solution. Just move content out of the super-project. Scripts in the super project should just call a script from a submodule which does all the work. Then track what's left manually - make sure there's little to track so that it shouldn't be too hard. Other than that you'll just have to deal with it manually.
It seems that bootstrap.sh is hard to move, it should be at the top level.
Another solution is to use Peter Dimov's suggested work flow, since with that master was merging in changes from develop. The latest/unstable branch could be automatically updated with changes from develop.
Yes, Peter's proposal will work just fine, and I think having superproject's develop branch point and submodule master only sounds confusing, but is in fact fairly logical.
- Suppose next release is nearing, and I've tested 'develop' branch of my library, and it works fine. I want to put it on master (whether I use intermediate release branch is not relevant here). Gitflow say to use something like this:
git merge --no-ff release-1.2
I imagine that most people want 'master' to be identical to 'develop', or to 'release-1.2', after such merge, and the above command does not guarantee that.
Generally git-flow ensures that everything in master has been merged into develop, since hotfixes and release branches are merged into both master and develop. So I think they can only diverge if you've been doing tricky things, such as a hotfix which results in a merge conflict. In which case you really should be checking that the merge result manually before pushing.
In general, yes. If everybody follows the right merge paths, it's OK. But everybody will eventually forget to.
I could use
git merge -s theirs release-1.2
which would make current branch identical to the branch we're merging. But then, git folks decided they don't like this flexibility, like this:
http://marc.info/?l=git&m=121637513604413&w=2
and removed 'theirs' merge strategy.
I don't agree with the reason for removing '-s theirs', but you can still use 'git merge -s ours master' from your release branch.
That would make the release branch be identical to master, so you'd still have to merge from develop and make sure that merge results are identical to develop. Well, not a big deal to remember to do this. - Volodya
On 18 December 2013 12:27, Vladimir Prus <ghost@cs.msu.su> wrote:
It seems that bootstrap.sh is hard to move, it should be at the top level.
Why not: #!/bin/sh exec submodule/booststrap_impl.sh
Another solution is to use Peter Dimov's suggested work flow, since with that master was merging in changes from develop. The latest/unstable branch could be automatically updated with changes from develop.
Yes, Peter's proposal will work just fine, and I think having superproject's develop branch point and submodule master only sounds confusing, but is in fact fairly logical.
We do need to have a better idea of how the branches are to be used, the current situation is unclear. I'm not sure git-flow is actually appropriate for the super project though, as the rolling release model doesn't quite fit. But this is a discussion for another thread.
I don't agree with the reason for removing '-s theirs', but you can still use 'git merge -s ours master' from your release branch.
That would make the release branch be identical to master
No it wouldn't. It's run from the release branch, so the release branch would stay exactly the same, then when merged into master it would not merge anything from master because all of master is already in its history (unless of course something was pushed to master after "merge -s ours" was run).
On 18.12.2013 16:59, Daniel James wrote:
On 18 December 2013 12:27, Vladimir Prus <ghost@cs.msu.su> wrote:
It seems that bootstrap.sh is hard to move, it should be at the top level.
Why not:
#!/bin/sh exec submodule/booststrap_impl.sh
That would create a module with two or three files in it. Putting this in tools/build is not really appropriate, and that one is meant to be independent. It seems more trouble than doing cherry-pick.
Another solution is to use Peter Dimov's suggested work flow, since with that master was merging in changes from develop. The latest/unstable branch could be automatically updated with changes from develop.
Yes, Peter's proposal will work just fine, and I think having superproject's develop branch point and submodule master only sounds confusing, but is in fact fairly logical.
We do need to have a better idea of how the branches are to be used, the current situation is unclear. I'm not sure git-flow is actually appropriate for the super project though, as the rolling release model doesn't quite fit. But this is a discussion for another thread.
I don't agree with the reason for removing '-s theirs', but you can still use 'git merge -s ours master' from your release branch.
That would make the release branch be identical to master
No it wouldn't. It's run from the release branch, so the release branch would stay exactly the same, then when merged into master it would not merge anything from master because all of master is already in its history (unless of course something was pushed to master after "merge -s ours" was run).
Yep, you're right. Speaking of which, "git merge master" might be better, as that will actually merge any potentially unmerged changes from master. Thanks, Volodya
On 18 December 2013 13:08, Vladimir Prus <ghost@cs.msu.su> wrote:
On 18.12.2013 16:59, Daniel James wrote:
On 18 December 2013 12:27, Vladimir Prus <ghost@cs.msu.su> wrote:
It seems that bootstrap.sh is hard to move, it should be at the top level.
Why not:
#!/bin/sh exec submodule/booststrap_impl.sh
That would create a module with two or three files in it. Putting this in tools/build is not really appropriate, and that one is meant to be independent. It seems more trouble than doing cherry-pick.
I don't really want to get into an argument about this, as I don't care that much and it's a bit of a bike shed, but there are a lot of boost specific files that could go into a submodule, such as the test build. Maybe some of the documentation stuff as well. This submodule could also have wider write access than the super project.
On Wed, Dec 18, 2013 at 5:21 PM, Daniel James <daniel@calamity.org.uk> wrote:
On 18 December 2013 13:08, Vladimir Prus <ghost@cs.msu.su> wrote:
On 18.12.2013 16:59, Daniel James wrote:
On 18 December 2013 12:27, Vladimir Prus <ghost@cs.msu.su> wrote:
It seems that bootstrap.sh is hard to move, it should be at the top level.
Why not:
#!/bin/sh exec submodule/booststrap_impl.sh
That would create a module with two or three files in it. Putting this in tools/build is not really appropriate, and that one is meant to be independent. It seems more trouble than doing cherry-pick.
I don't really want to get into an argument about this, as I don't care that much and it's a bit of a bike shed, but there are a lot of boost specific files that could go into a submodule, such as the test build. Maybe some of the documentation stuff as well. This submodule could also have wider write access than the super project.
BTW, that's a very good point because test failures markup are supposed to be writable for everyone, unless modularized too.
On 18.12.2013 17:21, Daniel James wrote:
On 18 December 2013 13:08, Vladimir Prus <ghost@cs.msu.su> wrote:
On 18.12.2013 16:59, Daniel James wrote:
On 18 December 2013 12:27, Vladimir Prus <ghost@cs.msu.su> wrote:
It seems that bootstrap.sh is hard to move, it should be at the top level.
Why not:
#!/bin/sh exec submodule/booststrap_impl.sh
That would create a module with two or three files in it. Putting this in tools/build is not really appropriate, and that one is meant to be independent. It seems more trouble than doing cherry-pick.
I don't really want to get into an argument about this, as I don't care that much and it's a bit of a bike shed, but there are a lot of boost specific files that could go into a submodule, such as the test build. Maybe some of the documentation stuff as well. This submodule could also have wider write access than the super project.
I don't care much either, as soon as 'a submodule' is something separate from 'build'. (Which presumably means that things stay as they are in immediate future). - Volodya
participants (4)
-
Andrey Semashev -
Bjorn Reese -
Daniel James -
Vladimir Prus