Hi Philip, 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). Ciao, Dscho
