From: Elijah Newren <newren@gmail.com>
Date: Mon, 18 Mar 2019 15:40:43 GMT
Subject: Re: [PATCH v2] unpack-trees: fix oneway_merge accidentally carry over stage index
Message-ID: <CABPp-BFDy4ppUqmC_J_hx4kFWaC+otBZ=mbuaJK13Wxzcz_urQ@mail.gmail.com>
In-Reply-To: <20190318113822.6195-1-pclouds@gmail.com>

On Mon, Mar 18, 2019 at 4:38 AM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
>
> Phillip found out that 'git checkout -f <branch>' does not restore
> conflict/unmerged files correctly. All tracked files should be taken
> from <branch> and all non-zero stages removed. Most of this is true,
> except that the final file could be in stage one instead of zero.
>
> "checkout -f" (among other commands) does this with one-way merge, which
> is supposed to take stat info from the index and everything else from
> the given tree. The add_entry(.., old, ...) call in oneway_merge()
> though will keep stage index from the index.
>
> This is normally not a problem if the entry from the index is
> normal (stage #0). But if there is a conflict, stage #0 does not exist
> and we'll get stage #1 entry as "old" variable, which gets recorded in
> the final index. Fix it by clearing stage mask.
>
> This bug probably comes from b5b425074e (git-read-tree: make one-way
> merge also honor the "update" flag, 2005-06-07). Before this commit, we
> may create the final ("dst") index entry from the one in index, but we
> do clear CE_STAGEMASK.
>
> I briefly checked two- and three-way merge functions. I think we don't
> have the same problem in those.
>
> Reported-by: Phillip Wood <phillip.wood123@gmail.com>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>

This is awesome; thanks for tracking it down and fixing.