Initial version of shears.sh

The purpose of the garden shears is to provide a much more advanced way
to work with a thicket of development branches than an interactive,
merge-preserving rebase. It supports not only rebasing topic branches
while keeping their merge structure intact but also allows for
reordering commits, as well as integrating msysGit's 'merging rebase'
strategy.

To support all that, this introduces a couple of new "rebase commands"
that are translated after editing the edit script, making use of a
temporary alias called ".r" that simply calls shears.sh itself.

The new commands are: "merge", "start_merging_rebase" and "cleanup".

To make appropriate  use of those new commands, we refuse blatantly to
let "git rebase -p" write the edit script, but generate it ourselves
instead. As a consequence, the edit scripts look very different from
current 'rebase -p' scripts.

Example:

	start_merging_rebase "2fb434d"
	exec git update-ref refs/rewritten/onto HEAD

	exec git reset --hard refs/rewritten/onto
	pick 780e6c6 Add a ZipInputStream
	exec git update-ref refs/rewritten/780e6c6 HEAD

	exec git reset --hard refs/rewritten/onto
	merge refs/rewritten/780e6c6 -C 2fb434d # Merge branch 'zip-input-stream' into HEAD

	cleanup  780e6c6

Subsequent commits will improve this script further.

Since this developer designed git-rebase's --preserve-merges support in
a very unfortunate, awfully short-sighted manner, it was sadly not
possible to provide this functionality as a patch series improving
git-rebase--interactive itself, but it is rather an add-on script that
circumvents parts of git-rebase--interactive altogether.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
shears.sh: support fixup! and squash!

One of the most powerful feature added to the already powerful
interactive rebase was to allow workflows where you *add* commits with
the intention to amend ("fix up") other commits in the topic branch at
a later stage, through "git rebase -i --autosquash". Such commits are
added by crafting special-format commit messages, or by using the
convenient --fixup or --squash options of "git commit".

However, with the garden shears, we side-step the original interactive
rebase, therefore we have to re-implement that very convenient
fixup/squash handling.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
shears.sh: simplify marking rewritten commits

It is nicer to read

	mark deadbeef

than

	exec git update-ref refs/rewritten/deadbeef HEAD

not to mention easier to write when modifying the edit script.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
shears.sh: provide hints as to branch names

It is quite convenient to know what branch is started by a

	exec git reset --hard refs/rewritten/onto

so let's try hard to find a branch name for each of them.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
shears.sh: introduce the 'rewind' shortcut

It is much nicer to read

	rewind onto

than

	exec git reset --hard refs/rewritten/onto

in the rebase script... ;-)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
shears.sh: make merge nicer to use

When modifying edit scripts, it is quite convenient to be able to
split branches by inserting

	mark my-new-branch
	rewind onto

and later just adding the line

	merge my-new-branch

to make new merge commits from scratch, instead of calling a clunky

	exec git merge --no-ff -m "Merge 'my-new-branch'" refs/rewritten/my-new-branch

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
shears.sh: introduce 'bud' and 'finish' commands

The most common operations during splitting a bunch of commits into
neatly-packaged topic branches are:

1) 'finish': name a branch & mark it for merging at the end, and

2) 'bud': start a new branch from the 'onto' commit

Since multiple branches most often want to branch off from a common base
commit, the 'finish' command implies a 'bud' after marking the HEAD for
later merging.

For example, when given an edit script as this:

	pick abcdef Adds an initial README.md file
	pick 012345 Adds a FAQ section to the README
	pick 987654 Fix an off-by-one bug

you might want to put the first two commits into the 'readme' branch
while the third commit wants to live in the 'fixes' branch. This can be
accomplished by inserting two 'finish' lines:

	pick abcdef Adds an initial README.md file
	pick 012345 Adds a FAQ section to the README
	finish readme

	pick 987654 Fix an off-by-one bug
	finish fixes

Since 'finish' implies a 'bud', this will result in a rewritten
history like this:

	* 3141592 Merge 'fixes' into HEAD
	|\
	| * cafebabe Fix an off-by-one bug
	* |  badf00d Merge 'readme' into HEAD
	|\ \
	| * | c0eddad Adds a FAQ section to the README
	| * | d1bad00 Adds an initial README.md file
	|/ /
	o-' fa7d00d Start the merging-rebase

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
shears.sh: introduce --recrate=<merge-commit> option

This option will try to recreate the branch that was merged by the
specified commit.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
shears.sh: delete existing rewritten refs with --force

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
shears.sh: use branch names instead of short commit names whenever possible

It is nicer to read

	merge refs/rewritten/hide-dotgit -C bdb8cb3

than

	merge refs/rewritten/90116a7 -C bdb8cb3

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use the garden shears in merging-rebase.sh

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a script to determine the commit order implied by their changes

The idea comes from darcs: a (non-merge) commit can be easily exchanged
with its parent commit if -- and only if -- their respective diffs touch
different parts of the files they modify.

With merge commits thrown into the fray, it gets slightly more unwieldy,
and what we are really interested in is not so much to actually exchange
the commits, but to know their relationship.

Therefore, this tool only determines the commit topology implied by
their respective changes, and then shows the topology via gitk or `git
log --graph`.

Note that we let renaming commits be implied parents of subsequent
changes. This is somewhat unintuitive because commits can be
cherry-picked sometimes when the modified files in question have been
renamed. However, this is not really reliable due to the rename
detection failing when too many changes happened in the meantime, so
we'll err on the safe side.

Also, while it would have been nice to use `git log -p -m` to read the
original commit history at the same time as the diffs -- without having
to launch new processes, so as to avoid challenging Windows and other
operating systems whose filesystem and process management technology
fell a little behind -- but we need to use custom commit message
formatting to obtain both short and long commit names at the same time
(to accomodate command-line length limitations imposed by Windows), and
there is simply no support in Git to retrieve the *current* parent in
custom commit messages when using '-m' (showing diffs relative to *all*
parents in case of merge commits).

In contrast to darcs, we do not use Haskell (which would essentially
lock out the 99% of programmers who do not speak that language) and we
do not try to explain the concept by employing oh-so-intuitive quantum
physics theory.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>