Suggested default git merge.ff behavior

29 views
Skip to first unread message

Daniel Lee

unread,
Nov 6, 2015, 2:55:47 PM11/6/15
to stan-dev mailing list
Ben, this question is mainly for you.

We're suggesting turning merge.ff to false:

Is there still a good reason to do this?

The merge bubbles are now causing issues with our submodules. What should we suggest our devs do?




Daniel

Ben Goodrich

unread,
Nov 6, 2015, 4:17:42 PM11/6/15
to stan development mailing list

I feel like I don't have a good enough understanding of why fast-forward merges are better or worse for submodules than for regular repositories. The wiki should probably recommend git >= 2.0 so that that you push to only one branch by default. I don't really ever push changes into the tree of a submodule; I just change what commit the submodule points to.

Ben


Daniel Lee

unread,
Nov 6, 2015, 4:26:45 PM11/6/15
to stan-dev mailing list
On Fri, Nov 6, 2015 at 4:17 PM, Ben Goodrich <goodri...@gmail.com> wrote:
I don't really ever push changes into the tree of a submodule; I just change what commit the submodule points to.

How do you do that? (what keystrokes / commands do you use?)

And how do you work on math or stan? Is that all done in its own repo?


Daniel
 

Ben Goodrich

unread,
Nov 6, 2015, 8:23:26 PM11/6/15
to stan development mailing list
On Friday, November 6, 2015 at 4:26:45 PM UTC-5, Daniel Lee wrote:
On Fri, Nov 6, 2015 at 4:17 PM, Ben Goodrich <goodri...@gmail.com> wrote:
I don't really ever push changes into the tree of a submodule; I just change what commit the submodule points to.

How do you do that? (what keystrokes / commands do you use?)

Like if I were doing something in rstan that needed a change in Stan Math, I do

cd StanHeaders/inst/include/mathlib
git branch | grep -F "*" # master
git pull -ff # lots of new branches and commits to branches other than master
git checkout develop # it is currently behind
git pull -ff #  43 files changed, 783 insertions(+), 687 deletions(-)
# do stuff in rstan, run tests, come back to this directory
git checkout master
git log --oneline | head -n 1 # 2060c2d


And how do you work on math or stan? Is that all done in its own repo?

Yeah.  I don't push to the math submodule inside cmdstan or rstan. I only push to github.com/stan-dev/math.

Ben
 

Ido Rosen

unread,
Nov 6, 2015, 9:28:33 PM11/6/15
to stan...@googlegroups.com
On Fri, Nov 6, 2015 at 8:23 PM, Ben Goodrich <goodri...@gmail.com> wrote:
On Friday, November 6, 2015 at 4:26:45 PM UTC-5, Daniel Lee wrote:
On Fri, Nov 6, 2015 at 4:17 PM, Ben Goodrich <goodri...@gmail.com> wrote:
I don't really ever push changes into the tree of a submodule; I just change what commit the submodule points to.

How do you do that? (what keystrokes / commands do you use?)

Like if I were doing something in rstan that needed a change in Stan Math, I do

cd StanHeaders/inst/include/mathlib
git branch | grep -F "*" # master

git symbolic-ref --short HEAD  # nitpick
 
git pull -ff # lots of new branches and commits to branches other than master

Do you mean "git git pull --rebase" or "git pull --ff-only"?  (Rebase would keep the history cleaner and avoid merge commits when you finally push to the submodule, and --ff is the default.)
 
git checkout develop # it is currently behind
git pull -ff #  43 files changed, 783 insertions(+), 687 deletions(-)

Same as above.
 
# do stuff in rstan, run tests, come back to this directory
git checkout master
git log --oneline | head -n 1 # 2060c2d


And how do you work on math or stan? Is that all done in its own repo?

Yeah.  I don't push to the math submodule inside cmdstan or rstan. I only push to github.com/stan-dev/math.


One major nuisance of gitflow is that it can make it difficult to have a nice simple linear commit history in each branch.  I always thought it'd be better to git pull --rebase before merging to the upstream branch to maintain linearity whenever possible... /rant

To update all submodules recursively to master and commit the changes to the outermost git repository, from the outermost one you can do this (git stashes inserted for safety, not necessary if your workdirs are clean):

git stash save --all
git submodule foreach --recursive 'git stash save --all && git pull --rebase master'
git commit -a -m "Updated submodules to upstream master."
git submodule foreach --recursive 'git stash pop'
git stash pop

Also note that you can use "git submodule update --init --rebase --recursive" from the outermost git repo to update all submodules to the revisions in the upstream repository if something was messed up by the above.

It seems like the level of confusion warrants setting up something like Chromium's depot_tools (or Android's "repo" is another option) to manage git superprojects/submodules through DEPS files the way the Chromium project does, rather than through git submodules directly.  (Or even CMake and ExternalProject_Add commands...)

While we're on the subject of dev environments, I know this has been tossed around before, but a Vagrantfile that sets up the dev environment in a VM for anyone wanting to (1) use stan or (2) hack on stan would make the bootstrapping process a lot easier.  You can bundle all this repo management stuff in that Vagrantfile and carry the dev env with you to wherever you go.  This Vagrantfile + vagrantbox can then be uploaded to Hashicorp's ATLAS as the DataScienceToolbox folks did and used as a basebox for any other Stan users (whether Virtualbox, VMware, AWS/EC2, Rackspace, DO, or bare metal)... 


And a pony, please.

Daniel Lee

unread,
Nov 6, 2015, 9:39:32 PM11/6/15
to stan-dev mailing list
Hi Ido,

Thanks, but most of this isn't relevant to the Stan development team's actual dev process, especially as it relates to our recommendation that developers set merge.ff to false.

If you have some practical advice, I'd love to hear it. Or help us fix this:
https://github.com/stan-dev/stan/wiki/Developer-Process#3--preventing-inadvertent-pushes


Daniel

P.S. We weren't really talking dev environments. If you want to bring that up, start a new thread, please.



--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Michael Betancourt

unread,
Nov 7, 2015, 4:54:43 AM11/7/15
to stan...@googlegroups.com
I love me some fast forward merges — please don’t make it
harder to develop than it already is.

Reply all
Reply to author
Forward
0 new messages