Re: [PATCH v2 0/4] Let the builtin rebase call the git am command directly

Junio C Hamano [off-list ref] writes:

"Johannes Schindelin via GitGitGadget" [off-list ref]
writes:

quoted

Especially on Windows, where Unix shell scripting is a foreign endeavor, and
an expensive one at that, we really want to avoid running through the Bash.

This not only makes everything faster, but also more robust, as the Bash we
use on Windows relies on a derivative of the Cygwin runtime, which in turn
has to jump through a couple of hoops that are sometimes a little too tricky
to make things work. Read: the less we rely on Unix shell scripting, the
more likely Windows users will be able to enjoy our software.

Changes since v1:

 * Rebased on top of master to avoid merge conflicts.

I do not appreciate this very much.  

We already have a good resolution prepared when merging this to
either 'next' or 'master', which also resolves conflict with the
other topic that requires this topic to add "--topo-order" in its
call.  Rebasing series means invalidating the previous work recorded
in rerere.

	side note. The rerere database entry can be recovered from
	master..pu with contrib/rerere-train.sh).

I prepared a set of patches rebased back on top of the previous base
and applied them on top of the previous base (call the result X).

Applying the posted patches directly on top of master, and merging X
into master, produces the same tree.

So I'll keep the X (i.e. these patches backward-rebased to the
previous base) and replace js/rebase-am with it.  That is safer when
recreating 'pu' and merging it to 'next', which I hope we can do
soonish.

Will take a look.  Thanks.

They were pleasant and smooth read.  Crafted nicely.

Thanks.