Where should the project source code be hosted - Meta

Caleb replying to Faheem Mitha

No actually I really did mean Gitbucket there, I'm familiar with Bitbucket (and it is in a different list). Gitbucket is actually a different thing.

Caleb replying to David

Nope, that's a mistake an editor introduced.

David

@Caleb Did you mean to both include and exclude Bitbucket? (You might have.) I've used it for a couple collaborative projects. I could add it as an idepdendent answer if, on reflection, it adds anything to your WIP.

David

Ignore me: I'm just curious about how these emoji will show up: ✔️ ❌❓⚠️ and maybe use later.

Faheem Mitha

Never mind. Edited.

Faheem Mitha

Should be Easy, of course.

Faheem Mitha

👍 Easiy migration

Faheem Mitha

That should be Bitbucket, not Gitbucket.

Faheem Mitha

Not considered for lack of first hand knowledge: Buddy, Phabricator, Beanstalk, Gitbucket, Allura, Rhodecode, ...

PeterVandivier

not _what_ the things causing the additional effort _are_, rather what the cost/benefit is to dual host versus the lost benefit / opportunity cost of using the second-choice hosting service

PeterVandivier replying to Caleb

that was kind of my point. i was asking what the mental overhead is for the org members to dual host since the preferred service seemed to be gitlab but github was chosen to facilitate collaboration.

Caleb replying to PeterVandivier

Re your earlier question about dual hosting: `git` is a _distributed_ version control system, and you can easily setup official or unofficial mirrors on whatever platforms are needed. Yes we could easily mirror to Gitlab. The biggest issue is it gets confusing when contributions are coming in over multiple channels, and it's a lot easier to have a central place for issue / pr management than spreading it across systems.

Caleb replying to PeterVandivier

You got the notification because if my PR, and the link to the commit is in there. The screen shot show a direct link to a SHA id of a commit. On Github you can link to any SHA in a repository no matter what fork it is on. In this case they link to to the commit on the host repository even though the commit is currently only connected to a branch in my fork.

PeterVandivier

> 
> Caleb Maclennan <notifications@github.com>
>  
> 7:41 AM (3 hours ago)
>
> to topanswers/topanswers, Push

>@alerque pushed 1 commit.

> cc89426 Convert site index to Markdown and adapt as README
>
>—
> 
>You are receiving this because you are subscribed to this thread.
View it on GitHub or unsubscribe.

PeterVandivier

https://github.com/topanswers/topanswers/commit/cc894268464cafb05cc075474bff62ef25069a13

PeterVandivier

the screencap showing your commit is on topanswers/topanswers, not alerque/topanswers. also, i got the notification because of my subscription to topanswers/topanswers

Caleb

What isn't as you expect?

Caleb

In what sense? It's about as plain-jane a setup as you can get on Github, just normal fork and [this branch](https://github.com/alerque/topanswers/tree/patch-1) on my fork.

PeterVandivier replying to Caleb

if you say so 🤷‍♂️it doesn't appear to be like most of the forks i've worked with

Caleb replying to PeterVandivier

It isn't a branch on the main repository, it's on [my fork]. I actually have access, but even on projects where I own the canonical repository I much prefer a workflow that uses my own personal fork for messing around with feature branches and a PR workflow similar to what any other contributor would use for getting things into the canonical repo.

PeterVandivier

i didn't see a new branch listed in the drop down? is it hidden in the index or something? didn't bother to pull and inspect locally

Caleb replying to PeterVandivier

I don't think the Douglas clan has the workflow quite ironed out yet, I'm guessing they are still working on a canonical repository history elsewhere and only mirroring later to Github — that being said I don't actually see any evidence of a force push there. You are looking at _my_ commit (cc894268) on my feature branch on my fork, which was submitted based on the older commit on master and I did force/push a change it it. Since it hasn't been merged anywhere feature branches like that should be fair game for rebasing / force pushing.

PeterVandivier

![Screenshot 2020-01-08 at 09.16.25.png](/image?hash=07ca57eee2c4e636880aa9abb87278b6d87647a9b55d395f28f0304d880002a1)  
looks like a force push to origin/master?

Jack Douglas replying to Caleb

as easy as that :)

Caleb

org page -> peoole -> invite

Jack Douglas replying to Caleb

I'd like to do that but have no idea how — I will have a dig around after supper!

Caleb

By the way please feel free to add me to the org/repo and I'll help with issue management, repo setup, etc. If you don't think I can behave myself with `git` have a  look around at other projects / orgs I have access too ;-)

Caleb

@Jack Awesome to see source in the light of day. I'm sorry I spotted that too late in the day to dig in.

Jack Douglas

:P

PeterVandivier replying to Jack Douglas

you should open a PR for that 😜

Jack Douglas

that really should have a horizontal scroll bar!

Jack Douglas replying to PeterVandivier

I imagine it's very easy to have the source hosted on multiple sites if we ever want to do that — because of the distributed design of Git. Pushing to GitHub was two lines:   
```
git remote add origin https://github.com/topanswers/topanswers.git
git push -u origin master
```

PeterVandivier replying to Jack Douglas

is there a sensible model for dual-hosting sometime in the future that doesn't have too much overhead? seems like hosting on github is a sensible choice for encouraging community participation; but perhaps hosting a mirror on gitlab could be a thought (sort of like a reverse of how the [postgres github mirror](https://github.com/postgres/postgres) does it)

Jack Douglas

We probably need a meta question "How can I contribute" — but we can chat in here for now

Jack Douglas replying to holmanb

consider yourself officially notified :)

Caleb

Leaning mostly towards Github for the community crossover with Codidact contributors. The balance would probably have been in favor of Github if it wasn't for that.

holmanb

Github would definitely get the most community engagement, but GitLab is very similar and also has a decently large community.  (Honestly I'm just commenting in hopes that I get notified when the src is released as I would like to contribute).

Jack Douglas replying to Caleb

Have you had any further thoughts on whether we should use GitHub (for convenience) rather than GitLab?

Jack Douglas replying to Caleb

that is good to know, thanks @Caleb

Caleb replying to Jack Douglas

Worktrees are a great feature and I think underutilized actually. It was a lat addition (relatively speaking) and a lot of people had established workflows before it was an option, so uptake has been slow. That being said they map 1→1 with normal branches, so can be pushed, pulled, merged, and whatever else just like usual. Mixing that into a workflow that includes a shared "hub" repository won't be hard. Even if some people are using worktrees and some switching branches it's okay to mix and match inside a team.

Jack Douglas replying to Caleb

I did not know any of that :) I can't even remember why I found them more convenient when I first started using them on soe other project…

Caleb

Oh okay, Practically speaking the same anyway, worktrees just share object stores with the same clone and block you from checking out the same branch.

Jack Douglas replying to Caleb

I forgot to say the branched are worktrees rather than clones

Caleb replying to Jack Douglas

So you have 4 clones/working directories where the remotes are folders on the local machine (production, test, you, james) and no off-file-system remotes?

Caleb

So you have 4 clones/working directories where the remotes are folders on the local machine (production, test, you, james) and no off-file-system remotes?

Jack Douglas

of course we also have commands we run to publish our changes to the production and test areas. We both have a url that runs our working area code, but then we publish to 'test' before merging with 'master' and publishing to 'live'

Jack Douglas

Is it potentially just a matter of adding a single extra step on the end, to push our changes to GitLab/Hub/whatever?

Jack Douglas replying to Caleb

Thanks for the offer, much appreciated. Our current workflow is that we work on the server exclusively. James and I create a branch to work on, and before merging changes, we will check if another commit has gone in since our branch was created. In that case we stash and rebase, test our changes again and then merge (so every merge is a fast-forward). My initial question is about how to integrate that workflow with and external repo.

Caleb replying to Jack Douglas

Ping for good measure. And the offer to help with git stuff is open pretty much any time, and also not necessarily dependent on picking a project management platform.

Caleb

Git itself being distributed it won't really matter and we could mirror to other hosts anyway, but for the same of any contributors interested in both spaces it would be easier not to split across two project management bubbles.

2 Answers