Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

> On Mon, 23 Apr 2018, Philip Oakley wrote:
>
>> From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de> : Monday, April 
>> 23,
>> 2018 1:03 PM
>> Subject: Re: [PATCH v8 06/16] sequencer: introduce the `merge` command
>>
>> [...]
>> >
>> > > > label onto
>> > > >
>> > > > # Branch abc
>> > > > reset onto
>> > >
>> > > Is this reset strictly necessary. We are already there @head.
>> >
>> > No, this is not strictly necessary, but
>>
>> I've realised my misunderstanding. I was thinking this (and others) was
>> equivalent to
>>
>> $  git reset <thatHead'onto'> # maybe even --hard,
>>
>> i.e. affecting the worktree
>
> Oh, but it *is* affecting the worktree. In this case, since we label HEAD
> and then immediately reset to the label, there is just nothing to change.
>
> Consider this example, though:
>
> label onto
>
> # Branch: from-philip
> reset onto
> pick abcdef something
> label from-philip
>
> # Branch: with-love
> reset onto
> pick 012345 else
> label with-love
>
> reset onto
> merge -C 98765 from-philip
> merge -C 43210 with-love
>
> Only in the first instance is the `reset onto` a no-op, an incidental one.
> After picking `something` and labeling the result as `from-philip`,
> though, the next `reset onto` really resets the worktree.
>
>> rather that just being a movement of the Head rev (though I may be having
>> brain fade here regarding untracked files etc..)
>
> The current way of doing things does not allow the `reset` to overwrite
> untracked, nor ignored files (I think, I only verified the former, not the
> latter).
>
> But yeah, it is not just a movement of HEAD. It does reset the worktree,
> although quite a bit more gently (and safely) than `git reset --hard`. In
> that respect, this patch series is a drastic improvement over the Git
> garden shears (which is the shell script I use in Git for Windows which
> inspired this here patch series).
>