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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 23, 2018, 12:20 UTC
Message-ID: <nycvar.QRO.7.76.6.1804231405230.15174@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <b05915e6-2259-5dee-69d8-90a5a524662d@talktalk.net>

Hi Phillip,

On Sat, 21 Apr 2018, Phillip Wood wrote:

Show 11 quoted lines

> On 21/04/18 11:33, Johannes Schindelin wrote:
> > This patch is part of the effort to reimplement `--preserve-merges` with
> > a substantially improved design, a design that has been developed in the
> > Git for Windows project to maintain the dozens of Windows-specific patch
> > series on top of upstream Git.
> > 
> > The previous patch implemented the `label` and `reset` commands to label
> > commits and to reset to labeled commits. This patch adds the `merge`
> > command, with the following syntax:
> 
> The two patches seem to have been fused together in this series.

Indeed. I have yet to investigate further how that happened, it could be a bug in my series after all.

Show 9 quoted lines

> If the reset command fails because it would overwrite untracked files it
> says
> 
> error: Untracked working tree file 'b' would be overwritten by merge.
> 
> Followed by the hint to edit the todo file. Saying 'merge' rather 'reset' is
> possibly confusing to users. Perhaps it could call
> setup_unpack_trees_porcelain(), though that would need to be extended to
> handle 'reset'.

Yes, and it changes global state :-(

Maybe we can leave it as-is for now? After all, it should be clear to the user what is happening. The most important part is the "Untracked working tree file"...

> Also it currently refuses to overwrite ignored files which is either
> annoying or safe depending on one's point of view.

Let me think about that. My gut feeling says: if it is easy to do, then let's nuke ignored files, but keep untracked files. But I do not think that the unpack-trees machinery was taught to know about .gitignore...

Seeing as `label` and `reset` really are mostly about revisions we see along the lines, I think that the common case will *not* overwrite any untracked files, ever. You would have to use `reset` on a not-previously-seen commit and/or add `exec` commands designed to interfere with the `reset`.

So I tend to want to not bother with discerning between untracked and ignored files here.

Ciao, Dscho