search for: stefansundin

..., > and that saves us from destroying the origin. Git, on the other hand, > allows anyone with write access to completely wipe out the repo. I > don't think anyone would want to, but accidents do happen in git. This is why git has "hooks": for example https://gist.github.com/stefansundin/d465f1e331fc5c632088 You can prevent from rewriting the history on the server side, which eliminate risk of "accidents". (You can have a whitelist of people allowed to rewrite the history...). > > As was said earlier, "git doesn't destroy data" in the sense that &g...

...e: > GitHub offers a simple *raw* git hosting. All the fork&pull-request is sugar in the web interface. You don't *have to* use it. I mentioned this below. I was referring how GitHub *expects* to be used. > This is why git has "hooks": for example https://gist.github.com/stefansundin/d465f1e331fc5c632088 > > You can prevent from rewriting the history on the server side, which eliminate risk of "accidents". (You can have a whitelist of people allowed to rewrite the history...). Right, this solves most of the problems. > Not sure how this part relates to git...

...s us from destroying the origin. Git, on the other hand, > > allows anyone with write access to completely wipe out the repo. I > > don't think anyone would want to, but accidents do happen in git. > > This is why git has "hooks": for example https://gist.github.com/stefansundin/d465f1e331fc5c632088 > > You can prevent from rewriting the history on the server side, which eliminate risk of "accidents". (You > can have a whitelist of people allowed to rewrite the history...). One downside of hooks is that you're relying on everyone who has commit acc...

...ow. We can continue in the current style on github as well.(Though as a side note, I don't think we are far away from the github model as phabricator revisions feel pretty similar to pull requests). > > >> This is why git has "hooks": for example https://gist.github.com/stefansundin/d465f1e331fc5c632088 >> >> You can prevent from rewriting the history on the server side, which eliminate risk of "accidents". (You can have a whitelist of people allowed to rewrite the history...). > > Right, this solves most of the problems. So far my experience has...

Kristof, Chandler, I think most of the responses seem favourable of the move, the concerns being which Git repo we'll use (GitHub, GitLab, BitBucket), but they're essentially identical on the git side. Infrastructure decisions will need to be taken into account, but that doesn't interfere with the "how we commit" discussion in any way. On 25 February 2016 at 08:55,

Ah - I do commit to the test-suite from time to time. So, could the github-based project be set up so that we can just do 'git push'? Or would we have to go through the pull requests route on every commit? I'm afraid I've never committed to any github project before, so I am a bit confused on how committing would work in practice. Obviously, I hope for the mechanism to commit to