jcmvbkbc

Latest versions of these scripts are available in git repository https://github.com/jcmvbkbc/esp32-linux-build

xiaokangwang

#!/bin/bash

# Thanks to https://gist.github.com/wenzhixin/43cf3ce909c24948c6e7
# Execute this script in your home directory. Lines 17 and 21 will prompt you for a y/n

# Install Oracle JDK 8
add-apt-repository ppa:webupd8team/java
apt-get update
apt-get install -y oracle-java8-installer
apt-get install -y unzip make expect # NDK stuff

Pulimet

adb help // List all comands

== Adb Server
adb kill-server
adb start-server 

== Adb Reboot
adb reboot
adb reboot recovery 
adb reboot-bootloader

jpierson

If you are like me you find yourself cloning a repo, making some proposed changes and then deciding to later contributing back using the GitHub Flow convention. Below is a set of instructions I've developed for myself on how to deal with this scenario and an explanation of why it matters based on jagregory's gist.

To follow GitHub flow you should really have created a fork initially as a public representation of the forked repository and the clone that instead. My understanding is that the typical setup would have your local repository pointing to your fork as origin and the original forked repository as upstream so that you can use these keywords in other git commands.

1. Clone some repo (you've probably already done this step)

   git clone git@github...some-repo.git

kuccello

/*
  Copyright 2013 Google Inc. All Rights Reserved.
  
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at
  
      http://www.apache.org/licenses/LICENSE-2.0
  
  Unless required by applicable law or agreed to in writing, software