Resetting files during a merge causes loss of resetted change, invisible in commit logs.

Resetting files during a merge causes loss of resetted change, invisible in commit logs.

[Thijs ter Horst]

Dear all,

Disclaimer: I have never done a bug report / worked with mailing lists
before, so if I'm doing things wrong I'd gladly hear.

As the title describes, git can change files without logging the
change. I'm not sure how to describe it shortly, so I've made a
minimal reproduction at 'https://github.com/gmth/git_test', along with
a shell script (git_debug.sh) that reproduces what I think is a
problem. In that repo "text1.txt" changes back when according to
commit logs it shouldnt have.

I ran into this when I lost some changes in my codebase that I could
not find in the commit logs, and a merge commit ('feature' into
'master') showed that that commit reverted a file to an earlier state,
while that change was not visible in any commits in 'feature'. The
cause in my case was probably that I accidentally clicked the
"Discard" button on a file in SmartGit, but the shell script shows how
to reproduce it with commandline git. Therefore I do not think this
has to do with SmartGit.

I am unsure if I'm allowed to attach the reproducing shell script to
this email, so that's why I haven't (spam filters etc).

Kind regards,

Thijs ter Horst

Re: Resetting files during a merge causes loss of resetted change, invisible in commit logs.

[Elijah Newren]

Hi Thijs,

On Fri, May 17, 2019 at 3:47 AM Thijs ter Horst <gmterhorst@gmail.com> wrote:
>
> Dear all,
>
> Disclaimer: I have never done a bug report / worked with mailing lists
> before, so if I'm doing things wrong I'd gladly hear.
>
> As the title describes, git can change files without logging the
> change. I'm not sure how to describe it shortly, so I've made a
> minimal reproduction at 'https://github.com/gmth/git_test', along with
> a shell script (git_debug.sh) that reproduces what I think is a
> problem. In that repo "text1.txt" changes back when according to
> commit logs it shouldnt have.
>
> I ran into this when I lost some changes in my codebase that I could
> not find in the commit logs, and a merge commit ('feature' into
> 'master') showed that that commit reverted a file to an earlier state,
> while that change was not visible in any commits in 'feature'. The
> cause in my case was probably that I accidentally clicked the
> "Discard" button on a file in SmartGit, but the shell script shows how
> to reproduce it with commandline git. Therefore I do not think this
> has to do with SmartGit.
>
> I am unsure if I'm allowed to attach the reproducing shell script to
> this email, so that's why I haven't (spam filters etc).

We tend to just like them inline, but no big deal.

Which part is unexpected for you?  Is it that the reset command will
reset a file to an older version (maybe there's something about the
reset documentation we need to improve?), that certain flags to the
log command didn't show you test1.txt (which flags?  perhaps we need
to improve the documentation on those flags?), or was it that you knew
the existing log flags wouldn't show you test1.txt based on their
documentation and you expected there to be some kind of flag for the
log command that would highlight this 'evil' merge where by 'evil' I
mean that it differs from an automatic-merge-and-accept-conflicts and
particularly in an area that's not conflicted (in which case
https://bugs.chromium.org/p/git/issues/detail?id=12 may be of interest
to you)?

Elijah