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

From: "Johannes Schindelin" <redacted>

On Mon, 23 Apr 2018, Philip Oakley wrote:

quoted

From: "Johannes Schindelin" <redacted> : Monday, April 23,
2018 1:03 PM
Subject: Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

[...]

quoted

quoted

quoted

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.

quoted

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).

thanks for clarifying. Yes my reasoning  was a total brain fade ... Along with the fact that it's a soft/safe/gentle reset.
--
Philip