The "----" in the diff above shows that several ebuilds were removed ("----" means many lines were removed) in the experimental branch, and bash-4.2_p10.ebuild had slight modifications. This looks like a good candidate for grabbing from experimental to replace entirely what is in master. Here's an example of something that is not a good candidate for a wholesale replacement:

In this example above, sys-apps/pciutils had a lot of cleanups in experimental, but the output above indicates that there is a new pciutils-3.1.8-1.ebuild in master that is not experimental. If we replace what is in master with that in experimental, we will lose the new ebuild! So we wouldn't want to do a wholesale replacement in this case. Old ebuilds that disappear are cleanups, but new ebuilds that disappear are not. Be sure to pay attention to whether the ebuilds that are being removed are old or new.

Back to our bash example. To inspect changes in more detail to make sure they are acceptable, specify the modified ebuild directly and drop the --stat option:

OK, these look like changes we want to merge into the master branch. Actually, we want to basically 'adopt' all these bash changes into master -- a wholesale import so that app-shells/bash in master looks exactly like that in experimental. To do this, we want to wipe out what is currently in the master branch related to app-shells/bash, and replace it entirely with the exact contents of app-shells/bash in the experimental branch.

Looks good. These changes are already staged for commit -- notice the --cached option above. If you don't use --cached, you won't see any changes, because they're already cached for commit. Let's commit them:

If we made any local changes to existing files that had not yet been added, and wanted to include those with the commit, we could use the -a option with git commit, above. Once the commit has been made, you should no longer see anything related to app-shells/bash listed when doing a diff of the branches.