repositories in flux

[Bob Carpenter]

The repositories seem to be in a bit of flux now, so
I'd recommend holding off committing anything or trying
to create pull requests until Daniel puts up the go flag.

We're using me as a guinea pig and I'm trying to write up
the process in a way that new users (like me) can understand.

- Bob

[Marcus Brubaker]

Can anything that's written up get posted somewhere easy to find and
refer to? Sending an email is good, but having a reference for
something like this would be great. Maybe it can be added to the
stan-future wiki: https://github.com/stan-dev/stan-future/wiki ?

Also, it would be great to include things like tips to keep your
commit history clean, how to write/run tests, etc. Basically, a "how
to contribute to Stan development" document.

Cheers,
Marcus

> --
> 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/groups/opt_out.
>
>

[Daniel Lee]

Yes, that's in the works. But as soon as we get it straightened out.

[Bob Carpenter]

Yes, the wiki is where I plan to put it. And yes, it'll have
all of this information at a low enough level that even I can
follow it.

What we also need is something with an overview of our build
and testing process and a basic description of the components.

I'll work on this when Humpty Dumpty's back together again.

- Bob

[Ben Goodrich]

Daniel and I have been Gchatting about the transition. I don't know git well enough to make sure we're not stepping into quicksand, so I want to throw this out there to see if anyone can spot a problem:

1) Rename master as develop with

git branch -m master develop

2) Create a new master branch starting at the v1.3.0 tag with

git branch master v1.3.0

3) Pushing everything to github with

git push -f origin master

This idea was based largely based on the commentary in these two posts

http://stackoverflow.com/questions/2862590/how-to-replace-master-branch-in-git-entirely-from-another-branch
http://stackoverflow.com/questions/2763006/change-the-current-branch-to-master-in-git

The central problem with a transition to the gitflow paradigm is that there are an untold number of branches out there in the world that have branched off our master branch prior to today that in the future need to be capable of being merged into develop and subsequently master. I'm theorizing that with the rename in step 1), git would be able to sort that out because the reflog goes with it.

Another issue is that maybe in the next week or two, we will need to branch the v1.4.0 release branch from the develop branch and when it is ready to release, merge that into master without inducing bad merge conflicts or creating Back to the Future Part II git history that would doom every future git bisect.

And there maybe other problems that I haven't considered yet. So, thoughts?

Ben

[Bob Carpenter]

On 5/17/13 6:44 PM, Ben Goodrich wrote:
> Daniel and I have been Gchatting about the transition. I don't know git well enough to make sure we're not stepping into
> quicksand,

My concern exactly. Git(Hub) is insanely complicated and
seems constrained in surprising ways in terms of what
it will and won't let you do, like set permissions on
a branch by branch basis or clone your own repository.

> so I want to throw this out there to see if anyone can spot a problem:
>
> 1) Rename master as develop with
>
> |
> git branch -m master develop
> |
>
> 2) Create a new master branch starting at the v1.3.0 tag with
>
> |
> git branch master v1.3.0
> |
>
> 3) Pushing everything to github with
>
> |
> git push -f origin master
> |
>
> This idea was based largely based on the commentary in these two posts
>
> http://stackoverflow.com/questions/2862590/how-to-replace-master-branch-in-git-entirely-from-another-branch
> http://stackoverflow.com/questions/2763006/change-the-current-branch-to-master-in-git
>
> The central problem with a transition to the gitflow paradigm is that there are an untold number of branches out there
> in the world that have branched off our master branch prior to today that in the future need to be capable of being
> merged into develop and subsequently master. I'm theorizing that with the rename in step 1), git would be able to sort
> that out because the reflog goes with it.

That's a good point. I doubt we have enough people out
there working on it who haven't told us about it to
worry about. At worst, they'd just have to recreate the
new branch.

> Another issue is that maybe in the next week or two, we will need to branch the v1.4.0 release branch from the develop
> branch and when it is ready to release, merge that into master without inducing bad merge conflicts or creating Back to
> the Future Part II git history that would doom every future git bisect.
>
> And there maybe other problems that I haven't considered yet. So, thoughts?

Can't we just now

* leave "master" branch as is

* create a "develop" branch from "master" as it stands

Then in the future

* push all "feature/" branches to "develop"

* push all "hotfix/" branches to "master" and "develop"

* push all "release/" branches to "master" and "develop"

Is the issue that if you create the branch from "master"
you have to push it back into "master"? If so, can we
just merge all the branches we have back into "master"
before we start the above?

That's actually a question for everybody --- I don't have any
work in branches to save. I'll make another post.

- Bob

[Bob Carpenter]

On 5/17/13 6:44 PM, Ben Goodrich wrote:

> Daniel and I have been Gchatting about the transition. I don't know git well enough to make sure we're not stepping into
> quicksand,

The best way to avoid this is to set up a test
account or repository to mirror the organization of
what we currently have and try it on that.

I think everything Ben suggests below can be tested.

- Bob

[Ben Goodrich]

On Friday, May 17, 2013 8:05:06 PM UTC-4, Bob Carpenter wrote:

Can't we just now

  * leave "master" branch as is

  * create a "develop" branch from "master" as it stands

I think that is a strong possibility also, but it would leave us in a state that is outside the gitflow paradigm. That is why Daniel was thinking about rewinding master to v1.3.0 and at some point in the next week or two merging a release branch (that was branched off develop) into (the "new" yet at v1.3.0) master. I don't know if that would go well or not.
 

Then in the future

  * push all "feature/" branches to "develop"

  * push all "hotfix/" branches to "master" and "develop"

  * push all "release/" branches to "master" and "develop"

Yes, that is just basic gitflow philosophy.
 

Is the issue that if you create the branch from "master"
you have to push it back into "master"?  

That is possible in general, but I don't know about ultimately pushing it into a rewinded master without doing bad things to the history. These operations are vaguely akin to reverting a merge, which is always a last resort, and can be complicated in the best of circumstances

http://git-scm.com/blog/2010/03/02/undoing-merges.html
 

If so, can we
just merge all the branches we have back into "master"
before we start the above?

I think if a branch is finished, it should get merged into master before we start transitioning so that it is less likely to get lost. At some level, we'll probably have to take our chances with branches that are currently unfinished, but I hope they could be merged under the proposal I originally outlined.

Ben

[Marcus Brubaker]

On Fri, May 17, 2013 at 9:09 PM, Ben Goodrich <goodri...@gmail.com> wrote:
> On Friday, May 17, 2013 8:05:06 PM UTC-4, Bob Carpenter wrote:
>>
>> Can't we just now
>>
>> * leave "master" branch as is
>>
>>
>> * create a "develop" branch from "master" as it stands

I would support this transition plan. It seems the least likely to
disrupt existing branches and I don't really see a down side. That
our history doesn't follow gitflow is fine as, well, we *weren't*
using that paradigm before now.

As an alternative, we could continue using master as the "develop"
branch until we're ready for a 1.4/2.0 release. At which point master
becomes the real master, and we branch develop and continue working
off of that.

I really don't see a need to rush this and try to perform some kind of
git surgery, although I'd be interested to hear if anyone does see a
need.

Cheers,
Marcus

[Ben Goodrich]

I favored waiting to create develop until the next release as well, but Daniel wanted to transition to gitflow before the next release. So, there are two or three ways we might try to do that, which we can test to some extent.

Ben

[Daniel Lee]

Thanks all for replying, but I'm thinking about this pragmatically. I know we can just bite the bullet and do it once. If there are any issues, I will take care of them.

Here are the people who have said / shown that they're not heavily dependent on master:

- Daniel

- Bob

- Jiqiang

- Michael (by forking)

- Marcus

The only ones that I don't know about are:

- Peter (but he'll either figure it out or I can help him)

- Ben (but I'm not so worried cause he's a git ninja)

I'm going through with changes to the repository. It won't hurt that much. I'll send an email with directions for everyone on how to use it. Bob's going to rewrite it so it's nice and clear. If anyone has problems, feel free to call me out. I'll help, even if that means typing in each change line by line.

By the way, we're going to follow the workflow suggested by this blog post:
http://nvie.com/posts/a-successful-git-branching-model/

Except merges into develop will be done through pull requests. I'll outline in another email once I'm done fixing up the repository.

Daniel