9 Jan

Weekly Update 135: Helpful GitHub improvements

This is a copy of our weekly newsletter for developers which you can subscribe to here.

Hello contributors,

There have been some important changes to GitHub recently and I'd like to highlight a couple that are good news for DuckDuckHackers. In particular they'll be helpful when there are problems with pull requests.

Maintainer changes to PRs

Firstly, you can now allow other developers to change your pull request (PR). If enabled, this means project maintainers and those with push access can make commits to your PR, fixing problems or editing code. There are a couple of cases where this is particularly useful:

  • When you've done most of the coding but aren't able to finish it off.
  • When you've been asked to make a change to a PR but are not sure what you should do.

Screenshot showing GitHub option for allowing changes to a pull request

This feature seems to be enabled by default but to make sure, check the "Allow edits from maintainers" option in the sidebar of your pull request, as in the screenshot above.

Easy merge conflict fixing

Secondly, those dreaded merge conflicts can now be kept under control with a new feature within the GitHub UI. Although it doesn't happen often in our repositories, if you do get a merge conflict message you can make changes to the problematic file without using the command line or even your local editor. The PR page itself will display an editable window where you remove sections that are no longer necessary and then mark the conflict as resolved. It's not suitable for complicated merge conflicts but in most cases it should avoid a lot of stress!

And with these improvements to the workflow, here are a few of the Instant Answer issues we're looking for help with...

Weekend Warriors

5-minute-ish Fixes

More open tasks here...

Quick Tip

Credit goes to Estelle Weyl for this CSS tip, although it's more of a sneaky hack (but still worth knowing).

As you may know, browsers use specificity when calculating what CSS properties to apply to HTML elements. This means a very specific selector (e.g. ul#animals li) would take precedence over a more vague selector (e.g. li), regardless of their order in the CSS file. Some people use !important after the value to override this but it's generally seen as bad practice. Estelle's alternative way of overriding specificity is still hacky but better than !important and not widely known. Let's see an example...

Assuming we have a list of animals, we can apply styles to all items like so:

ul#animals li {
   font-size: 2em;
   color: black;
}

If we try to change the color of a single item that has a #duck ID, the following code will have no effect:

#duck {
  color: red;
}

However, simply typing the property twice changes the specificity and in this case will change the color to red:

#duck#duck {
  color: red;
}

It seems silly but it works! Admittedly this kind of hack is something you should probably avoid in practice, but knowing of it's existence is helpful, especially when working with code from other developers.

You can read more about CSS specificity here and try out this example for yourself at JS Bin.

One more thing

From 2017 we'll publish this newsletter less frequently, probably about once a month. If there's particular content you'd like to see or tips you want to share, please leave a comment below or let us know on Twitter.

That's all for now — see you next time!

- The DuckDuckGo Staff

0 Tweet

This blog has been archived

Thank you for reading and contributing lively discussion to our blog! Read more posts about online privacy on our new blog at spreadprivacy.com.