Thomas Rast writes:
> Michael Haggerty writes:
>
> On IRC you said you would like a version that always acts as
> --no-commit, and simply returns the conflict/no conflict bit as usual.
> The caller would then proceed using commit-tree itself. I think that is
> probably a saner solution than thi
Michael Haggerty writes:
> On 07/09/2013 02:08 PM, Thomas Rast wrote:
>> Michael Haggerty writes:
>>
>>> Since you've already implemented a way to merge into the index (even an
>>> alternative index) without touching the working copy, I'll just cross my
>>> fingers and hope for the appearance o
On 07/09/2013 02:08 PM, Thomas Rast wrote:
> Michael Haggerty writes:
>
>> Since you've already implemented a way to merge into the index (even an
>> alternative index) without touching the working copy, I'll just cross my
>> fingers and hope for the appearance of an option that makes merge leave
Michael Haggerty writes:
> Since you've already implemented a way to merge into the index (even an
> alternative index) without touching the working copy, I'll just cross my
> fingers and hope for the appearance of an option that makes merge leave
> HEAD, MERGE_HEAD, etc. untouched.
The most ann
On 07/08/2013 05:44 PM, Thomas Rast wrote:
> Michael Haggerty writes:
>
>> [Resend because of address confusion in replied-to email.]
>>
>> On 07/07/2013 08:00 PM, Thomas Rast wrote:
>>> I recently looked into making merge-recursive more useful as a modular
>>> piece in various tasks, e.g. Michae
Michael Haggerty writes:
> [Resend because of address confusion in replied-to email.]
>
> On 07/07/2013 08:00 PM, Thomas Rast wrote:
>> I recently looked into making merge-recursive more useful as a modular
>> piece in various tasks, e.g. Michael's git-imerge and the experiments
>> I made in show
[Resend because of address confusion in replied-to email.]
On 07/07/2013 08:00 PM, Thomas Rast wrote:
> I recently looked into making merge-recursive more useful as a modular
> piece in various tasks, e.g. Michael's git-imerge and the experiments
> I made in showing evil merges.
>
> This miniseri
[Michael, sorry for the double mail -- I typoed the list address on
the first round.]
I recently looked into making merge-recursive more useful as a modular
piece in various tasks, e.g. Michael's git-imerge and the experiments
I made in showing evil merges.
This miniseries is the extremely low-ha
8 matches
Mail list logo