Do update_rerere_cache earlier to update nightly.conf too.

Something slightly changed in the git log output and the regex fell
appart.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Fairly basic. We might want to put them all into a new dim branch
subcommand eventually. Especially if I ever get around to doing
per-branch working copies.

v2: Correct help text formatting and sprinkle $DRY_RUN (Jani)

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

I plan to add more of these ...

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

In case qa contact no. 1 is on vacation.

Eventually we'll forget to keep the script and the conf in sync if there
are changes to remotes in nightly.conf. At the time of writing we fetch
driver core for no reason at all. Make it automatic.

Make it all easier to read and understand at a glance. The output will
look something like this:

Updating rerere cache... Done.
Merging origin/drm-intel-next-queued... Reset. Done.
Merging origin/drm-intel-next-fixes... Done.
Merging origin/drm-intel-fixes... Done.
Merging drm-upstream/drm-next... Fast-forward. Done.
Merging drm-upstream/drm-fixes... Using override sha1: d753856c9f9ae33a980192aa7b81d8b97d79dec2... Fast-forward. Done.
Merging origin/topic/core-stuff... Done.
Merging origin/topic/atomic-core... Done.
Merging origin/topic/atomic-helpers... Fast-forward. Done.
Merging sound-upstream/for-next... Done.
Adding integration manifest drm-intel-nightly: 2015y-01m-08d-16h-03m-27s UTC... Done.
Pushing drm-intel-nightly... Done.
Updating rerere cache... Nothing changed. Pushing rerere cache... Done.

This reduces copy-paste but also prints all conflict markers found,
giving an idea of the scale of the conflict.

Apparently this needs an explicit repack to work, which reduces risks
with pruning. So do this only in the setup functions.

Prep work for multiple workdir checkouts, but already saves an
impressive 3G here.

Because one day I'm going to send a pull request signed with "Cheers,
Daniel".

With the overview abstracted, also merge prep_pull_mail_tags into
prep_pull_mail that can handle both cases depending on the tags passed
as parameters.

We've had tons of fun in the past with -nightly merge commits, e.g.

commit e47410aa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Sep 8 08:52:41 2014 +0200

    dim: cope better with silent conflict fixup patches

Now another kind of fun showed up, namely when a merge is just a
fast-forward without any content changes. That lead to the git diff
--cached check failing, which lead to not committing the merge, which
lead to to all subsequent merges failing too.

Since this is all too fragile rework the logic a bit and first filter
out the fast-forward merges. With those handled we know that there
will be a real merge and so always something to commit. Which also
means that we'll never have fun again with fixup patches getting lost.
Hopefully.

This has the added benefit of not calling dim script again.

dim pull-request-topic gets renamed pull-request as the generic
pull-request command, and the old dim pull-request for features becomes
pull-request-next.

Basically rewrite the documentation highlighting the similarities and
differencies between the commands.

Now we have all pull requests handled neatly in one place.

Realize that it's more of the same, really.

Similar to pull-request-fixes and pull-request.

For reuse.

This reverts commit 614869a7.

It makes things too ugly. We can return to this if we can come up with
neater ways.

It's still a lot of manual work and every time I need to check again
how the fixup patch naming scheme works.

Makes the setup process slightly more helpful.

Refer to the main maintainer repo for objects to save bandwidth and
nerves.

Require all referenced variables to have been set.

- quilt patches can be listed with the git forwarding using qf branch
- bash completion is done
- qf pull is done

Similar to git fetch + git merge @{upstream}

v2: Also support --rebase, like git pull --rebase. Also don't forget
bash completion.

Suggested by Jani.

Almost ended up tagging a random local wip branch ...

Also make it a bit more informative

Add support for checking a given range of commits using dim check-patch
instead of just one.

Without arguments to 'dim check-patch', the topmost commit (i.e. HEAD)
is checked like before. With a single commit-ish, 'dim check-patch
commit-ish' will check a range of commits commit-ish..HEAD instead of
just commit-ish like before. Finally, with a range expression 'dim
check-patch commit-ish..commit-ish' the given range is checked.

Use a local var for the commit for clarity. Print oneline commit summary
before the output. Use checkpatch.pl -q option to reduce output. Reduce
newlines printed for errors and warnings. Return 1 instead of exit 1 on
errors so we can continue as needed.

All of this is to better support other uses for dim_checkpatch in follow
up work.

The current approach has a bunch of problems:
- It relies on the local maintainer's latest upstream version tags, so
  can flip-flop if they don't match.
- It's not really precise around the merge window.

The new approach should work a bit better:
- Unconditionally push -fixes.
- For the for-linux-next branch either push dinf or dinq. If dinf is ahead
  of -fixes then push dinf, assuming that drm-next is frozen already and
  that we've accumulated fixup patches already. If -fixes is ahead of dinf
  then push dinq assuming that the merge window has closed already.

This means we need to refine our process a bit to make sure this works
correctly:
- Only push -fixes forward to the new release past -rc1. Use dinf for fixup
  patches while the merge window is still open.
- As soon as -fixes has overtaken dinf don't roll it forward until drm-next
  is frozen for the next merge window.

v2: Run this in -nightly instead of -rerere

Mostly copypasta

With rebase -i the default upstream is the remote branch, so no need
to specify that explicitly.