Is there a simple way to delete all tracking branches whose remote equivalent no longer exists? Example: Branches (local and remote) master origin/master origin/bug-fix-a origin/bug-fix-b origin... Remove tracking branches no longer on remote EmailThis Premium lets you save unlimited bookmarks, PDF, DOCX files, PPTs and images. It also gives you a PDF copy of every page that you save. Upgrade to Premium → I wouldn't normally answer a question that already has 16 answers, but all the other answers are wrong, and the right answer is so simple. The question says, "Is there a simple way to delete all tracking branches whose remote equivalent no longer exists?" If "simple" means deleting them all in one go, not fragile, not dangerous, and without reliance on tools that not all readers will have, then the right answer is: no. Some answers are simple, but they don't do what was asked. Others do what was asked, but are not simple: all rely on parsing Git output through text-manipulation commands or scripting languages, which may not be present on every system. On top of that, most of the suggestions use porcelain commands, whose output is not designed to be parsed by script ("porcelain" refers to the commands intended for human operation; scripts should use the lower-level "plumbing" commands). Further reading: why you shouldn't parse git branch output in a script. tracking branches and the differences between git remote prune, git prune, git fetch --prune If you want to do this safely, for the use case in the question (garbage-collect tracking branches which have been deleted on the server but still exist as local branches) and with high-level Git commands only, you have to git fetch --prune (or git fetch -p, which is an alias, or git prune remote origin which does the same thing without fetching, and is probably not what you want most of the time). Note any remote branches that are reported as deleted. Or, to find them later on, git branch -v (any orphaned tracking branch will be marked "[gone]"). git branch -d [branch_name] on each orphaned tracking branch (which is what some of the other answers propose). If you want to script a solution, then for-each-ref is your starting point, as in Mark Longair's answer here and this answer to another question, but I can't see a way to exploit it without writing a shell script loop, or using xargs or something. Background explanation To understand what's happening, you need to appreciate that, in the situation of tracking branches, you have not one branch, but three. (And recall that "branch" means simply a pointer to a commit.) Given a tracking branch feature/X, the remote repository (server) will have this branch and call it feature/X. Your local repository has a branch remotes/origin/feature/X which means, "This is what the remote told me its feature/X branch was, last time we talked," and finally, the local repository has a branch feature/X which points to your latest commit, and is configured to "track" remotes/origin/feature/X, meaning that you can pull and push to keep them aligned. At some point, someone has deleted the feature/X on the remote. From that moment, you are left with your local feature/X (which you probably don't want any more, since work on feature X is presumably finished), and your remotes/origin/feature/X which is certainly useless because its only purpose was to remember the state of the server's branch. And Git will let you automatically clean up the redundant remotes/origin/feature/X -- that's what git fetch --prune does -- but for some reason, it doesn't let you automatically delete your own feature/X... even though your feature/X still contains the orphaned tracking information, so it has the information to identify former tracking branches that have been fully merged. (After all, it can give you the information that lets you do the operation by hand yourself.) Source: https://stackoverflow.com/questions/7726949/remove-tracking-branches-no-longer-on-remote Please check the attached file. EmailThis was not able to extract useful content from the website. Hence, we have saved the webpage to a PDF file. You can find that attached along with this email. Upgrade to Premium Plan ✔ Save unlimited bookmarks. ✔ Save PDFs, DOCX files, images and Excel sheets as email attachments. ✔ Get priority support and access to latest features. Upgrade to Premium EmailThis Send web pages & articles to your email inbox. If you have any suggestions, bug reports or comments, please let me know at bharani@hq.emailthis.me. You can also Tweet to us at @EmailThis_

When you search google on how to change / reset user password most tips includes changing this from the database. Yet there is imho better… Quick tip. How to change Laravel user password from command line. EmailThis Premium lets you save unlimited bookmarks, PDF, DOCX files, PPTs and images. It also gives you a PDF copy of every page that you save. Upgrade to Premium → When you search google on how to change / reset user password most tips includes changing this from the database. Yet there is imho better way that use Laravels Tinker Laravel REPL All Laravel applications include Tinker, a REPL powered by the PsySH package. Tinker allows you to interact with your entire Laravel application on the command line, including the Eloquent ORM, jobs, events, and more. To enter the Tinker environment, run the tinker Artisan command: Chaning password (or any other Model data) Launch the console from main folder with php artisan tinker After that you enters Laravels console — all commands from now are interpreted as php code. So to change user@example.com password you would just run. $user = App\User::where('email', 'user@example.com')->first(); $user->password = Hash::make('password'); $user->save(); That's it. Password changed. Source: https://medium.com/qunabu-interactive/quick-tip-how-to-change-laravel-user-password-from-command-line-515f55c9d295 Upgrade to Premium Plan ✔ Save unlimited bookmarks. ✔ Save PDFs, DOCX files, images and Excel sheets as email attachments. ✔ Get priority support and access to latest features. Upgrade to Premium EmailThis Send web pages & articles to your email inbox. If you have any suggestions, bug reports or comments, please let me know at bharani@hq.emailthis.me. You can also Tweet to us at @EmailThis_

Black Friday Sale! Save 50% on EmailThis Lifetime Plan 🎉

Our Black Friday sale has launched early! Starting today, you can save 50% on the EmailThis Lifetime Subscription. Grab this deal before it's gone! Our Black Friday sale has launched early! Starting today, you can save 50% on the EmailThis Lifetime Subscription. Grab this deal before it's gone! The regular price for this plan is $79, but right now it is available for only $39 (50% off). This plan helps you turn your email inbox into your personal reading list. You can save unlimited ad-free web pages to your email inbox, attach notes & keywords and save a PDF copy of every web page. Unlock the Black Friday deal → You are receiving this email because you subscribed on our website (emailthis.me). If you no longer wish to receive our emails, click the link below: Unsubscribe

If you own a Mac* and an Apple* developer account, you can utilize Web Inspector in Safari* to remotely debug an iOS* Cordova app in a way that is analogous to using Remote Chrome* DevTools with an Android* device running a Cordova app. This process requires that you use a Mac and that your iOS device is attached to the Mac via a USB cable. Some configuration of Safari* on your Mac* and on your iOS* device is required to make this work, and is described below. Using Web Inspector Remote to Debug iOS* Cordova Apps EmailThis Premium lets you save unlimited bookmarks, PDF, DOCX files, PPTs and images. It also gives you a PDF copy of every page that you save. Upgrade to Premium → If you own a Mac* and an Apple* developer account, you can utilize Web Inspector in Safari* to remotely debug an iOS* Cordova app in a way that is analogous to using Remote Chrome* DevTools with an Android* device running a Cordova app. This process requires that you use a Mac and that your iOS device is attached to the Mac via a USB cable. Some configuration of Safari* on your Mac* and on your iOS* device is required to make this work, and is described below. Additional instructions regarding the use of Web Inspector with a USB-attached iOS device can be found in this Apple document titled Safari Web Inspector Guide. The instructions below will only get you connected and started, they do not explain how to use Web Inspector to debug your application. Enable "web inspector" on your iOS device Open "Settings" on your iOS device Choose "Safari" Choose "Advanced" Set the "Web Inspector" button to "on" (make it green) Enable "device debug" in Safari on your Mac Select "Preferences" from the Safari menu Choose the "Advanced" tab Check the "Show Develop menu in menu bar" option (as shown in the image below) Build your app using a development provisioning file and install the IPA onto your iOS device It is important that you build your app with a "Development" certificate and a matching "Development" mobile provisioning file. You need to import your "Development" p12 certificate into the Intel XDK certificate management tool. Make sure you then select that certificate from the pulldown in the iOS tab in the Build Settings (on the Projects tab) before you build your app. Also, be sure to select the matching mobile provisioning file in the same Build Settings section for your project. An example of a "Development" mobile provisioning file is shown below. Note that in this example the provisioning file is a "wildcard" provisioning file, which means that it can be used with any App ID (because the provisioning file's App ID is '*'). The app you build with this "Development" provisioning file (and the matching "Development" certificate) can only be installed onto those devices that are part of the authorized "Device" list (there are seven authorized devices for the certificate shown below). Alternatively, you can re-sign a previously built app with a development provisioning file If you choose this route, the easiest way to re-sign your app is with a free open-source app named iReSign. You can download it directly from this GitHub repo and move the iReSign.app folder to your /Applications folder (or wherever you like to store such utilities...). See the README.md in the iResign GitHub repo for basic instructions. This app does require that Xcode is installed on your Mac. Install the Built App onto Your iOS Device If you imported a "Development" certificate into your Intel XDK certificate management console and used that certificate and the matching "Development" mobile provisioning file to build your app, you can most easily install your app by sharing the app via the build tile. Using the share feature on the iOS build tile from the Build tab allows you to email your built app to your device. From the iOS device, open the shared email with the native email app on your iOS device and select the OTA link to download and install the built app onto your device. If you downloaded the IPA file directly to your Mac, you can use Xcode to install your IPA file on an iOS device for testing: Start Xcode on your Mac. Connect your iOS device to your Mac, via a USB cable.  In the Xcode menu, choose Window > Devices and find your device in the list. Click the Add button (+) below the Installed Apps table. Locate your IPA file in the dialog that appears and click Open. You can also use iTunes to install the IPA file onto your device, by following the instructions below. Attach the iOS device to your Mac via a USB cable Open iTunes* and select the USB-attached iOS device so you can see the apps that are on the device. Drag the IPA file you re-signed to the iTunes icon on your Mac's "Dock." Make sure you select "install" next to the name of the app you dragged to the iTunes Dock icon. It should appear in the list of apps shown for the iOS device in iTunes. Once you select "install" the button should change so it says "will install." In the image below we are going to install the app named "HelloCordova" for remote debugging over USB. Sync iTunes with your iOS device This is necessary to install the built app onto your device with iTunes. You "sync" iTunes with your device by pushing the "Apply" button in the lower right corner of iTunes. Do not remove the USB cable from your Mac, the next step requires that your iOS device remain connected to your Mac via the USB cable. Start Debugging the App on Your iOS Device First, start the app on your iOS device; an icon for the app to be debugged should have appeared if you successfully installed your IPA using one of the side-loading steps above. To start debugging with Safari on the Mac: select "Develop" from the Safari menu select the "name of the attached device" select the "name of the app to be debugged" select "index.html" (see the image below) Safari Web Inspector will start on your Mac and you will have a full debug environment (similar to Chrome DevTools) for the app that is running on your USB-connected iOS device. For difficult debugging situations, especially those where the app crashes immediately on start, you may have to change the logic in your app to pause any action until, for example, you start a function manually from the JavaScript* console. Debugging a built app does not require rebuilding your app to test changes or experiment with your code. The best debugging experience will come from taking advantage of the interactive JavaScript console to redefine functions within your app and then run those redefined functions directly from the console or restart your app, in situ, using the window.location.reload() function. An example of using this technique can be seen in this video, starting at about 18:30. The video is demonstrating the use of the weinre debugger, but the debugging techniques can also be applied to remote CDT and remote Web Inspector when debugging a built app. Notice in the Web Inspector image above, the <p> tag is highlighted. In the screenshot below you can see the highlighted <p> element, it is similar to debugging a browser window with Safari Web Inspector. The screenshot below was taken from an iPhone* that was attached via USB to a Mac running the Web Inspector session shown above. The Web Inspector session, above, is debugging the app running on the iPhone, below. For more complete information about compiler optimizations, see our Optimization Notice. Source: https://software.intel.com/en-us/xdk/docs/using-web-inspector-remote-to-debug-ios-cordova-apps Upgrade to Premium Plan ✔ Save unlimited bookmarks. ✔ Save PDFs, DOCX files, images and Excel sheets as email attachments. ✔ Get priority support and access to latest features. Upgrade to Premium EmailThis Send web pages & articles to your email inbox. If you have any suggestions, bug reports or comments, please let me know at bharani@hq.emailthis.me. You can also Tweet to us at @EmailThis_