Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixing operatingsystem for Amazon Linux #111

Merged
merged 1 commit into from
Sep 8, 2016
Merged

Conversation

bleiva
Copy link

@bleiva bleiva commented Aug 10, 2016

We had an issue with Amazon Linux servers. This fix is for avoiding the legend 'Operating system is not supported'

@seefood
Copy link

seefood commented Aug 14, 2016

I was just about to patch this in! Can you please approve the PR?

@bastelfreak bastelfreak closed this Sep 4, 2016
@bastelfreak bastelfreak reopened this Sep 4, 2016
@bastelfreak
Copy link
Member

@bleiva can you rebase against latest master? This should make travis green

@jyaworski jyaworski merged commit c13d694 into voxpupuli:master Sep 8, 2016
@jyaworski
Copy link
Member

Merging since this is so trivial. Rebasing is best practices, but people only have so much time.

@seefood
Copy link

seefood commented Sep 8, 2016

Rebasing is tricky business sine it kills many fine features of git's merge abilities. I'm a little scared of it, and all the books and manpages warn against mixing rebase and merge in the same repo, which sounds like very sensible advice to me. merge is the default in git, and in most github projects I have bumped into to date, so I'll stick to that :)

@bastelfreak
Copy link
Member

Hi @seefood, sounds interesting, I have never heard of that also never experienced issues. Do you have a link to that information?

@JimPanic
Copy link

JimPanic commented Sep 8, 2016

There's no problem mixing merge and rebase in the same repository. But you shouldn't mix merges and rebases in the same PR/branch divergence.

Rebasing a PR onto master is still best practices since it neither scrambles the history, nor any of the "fine features" take away the possibility to reason about your PR.

Not saying merging is bad or the features wouldn't be fine in most cases; in case of revitalizing PRs however, rebasing is a very safe strategy.

@seefood
Copy link

seefood commented Sep 8, 2016

@bastelfreak either you were lucky or you are aware of the possible pitfalls of rewriting commit history and manage to steer carefully around them. when rebase rewrites the history, it gives commits new hashes, so diamond merges don't have history to work with and such. So if not careful, you end up patching the same change twice and other headaches that would not happen if the history was not lost.

@seefood
Copy link

seefood commented Sep 8, 2016

Well, I had a few cases where I could not wait for a repo owner to accept a PR and pulled it into my branch, knowing it would be merged by the time I send in my PR. with rebase it would have meant the same changes would be merged with different hashes, which may mean a painful manual merge. Maybe there are better examples, I'm just glad I have not had to deal with them.

EmRowlands pushed a commit to EmRowlands/puppet-selinux that referenced this pull request Mar 29, 2023
Fixing operatingsystem for Amazon Linux
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants