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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
>> 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.