From: "Johannes Schindelin" <Johannes.Schindelin@xxxxxx>
On Mon, 23 Apr 2018, Philip Oakley wrote:
From: "Johannes Schindelin" <Johannes.Schindelin@xxxxxx> : 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).
thanks for clarifying. Yes my reasoning was a total brain fade ... Along
with the fact that it's a soft/safe/gentle reset.
--
Philip
