Reserved keywords - Do Not Use these in your code

Do not use these names, you will get confusing errors...

Perl:

• sub import

Mojolicious:

• stash('data', ...)

How to apply a stash by name in git

1) In git it's easy to retrieve stashes by number like this:

git stash apply stash@{5}

But that number changes as you add more stashes to the list.

2) Instead you could perform some jiggery-pokery in bash to look up the stash by name:

git stash apply $(git stash list | grep "$NAME" | cut -d: -f1)

You can apply multiple stashes as long as they don't overlap.

3) Or you could save the commit and refer to it by tag:

git commit -m'The usual changes to aid debugging'
git tag foo
git reset --hard HEAD^
git cherry-pick -n foo

(-n is --no-commit)

This way if they overlap you can use git's merging/conflict mechanism.

(source)

Git show untracked stash files

Git stash can save untracked files like this:

git stash --all

But to see untracked files in the stash you need this special ^3 syntax:

git show stash@{1}^3

git show stash@{2}^3

git show stash@{99}^3

This shows stash numbers, 1, 2 and 99 respectively. The number 3 always remains 3.

(source)

How to apply a named stash in git

git stash apply stash^{/foo1}

where foo1 is the full name of your stash (keep names short, with no spaces).

(source)

Make it easy to review your code

tldr; It's difficult to arrange for a whole team of developers to follow and participate in code reviews, but if you use dedicated code review software then it's easy.

Of course you want a wide audience reading your code - in order to improve the quality of the code being produced by your team. You don't have anything to hide, do you? ;-)

Problem: Say you're not the "designated reviewer", and you want to see your team mates' code before it's merged to trunk, perhaps the following things have to happen:
    - Configure your email filters to pick out reviews from the hundreds of other update emails
    - Check out the code in your environment
    - Wait some time for the checkout to complete
    - Run a diff command to see the changes
    - Hope that your team is using version control tools which make it easy/possible to see only the commits they made, without mixing them up with all the code that was pulled from trunk/master along the way
    - Read the code
    - Copy and paste the lines of code you want to comment on (for context) into a message to the developer. As it's often easier and faster to use email, instant chat or a face to face meeting than adding comments to a bug tracking system, the rest of the team isn't part of the conversation and is denied the chance to learn about technique, see how to conform to house policy, etc.
    - Write the comments
    - The developer reads the comments and may or not make changes, you don't always know, and the rest of the team certainly doesn't know.
    - In a team where developers are expected to designate a single person to review each feature, attempting to give feedback on someone else's code out of turn could be seen as interfering and a distraction.

Solution: A better arrangement could be:
    - Use a code review tool: ReviewBoard, Stash or something similar
    - Click on a URL in the review notification email
    -  Read the code
    - Click on the line you want to comment on
    - Write the comments. The whole team gets notification emails of comments, so they can effortlessly follow along with conversations about the code.

    - The developer replies to the comments publicly, everyone is now aware of what technical decisions were made and why

    - Everyone is expected to review all code - it's not distracting because it becomes part of the general work of the team to ensure high code quality.

See all variables in Template Toolkit

[% USE Stash %]
[% USE Dumper Indent = 1%]
<pre>[% Dumper.dump_html( Stash.stash() ) %]</pre>

Template::Plugin::Stash docs