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

Thijs ter Horst· May 17, 2019, 10:28 UTC · lore

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

Elijah Newren· May 17, 2019, 16:56 UTC · re: Thijs ter Horst · lore

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

Hi Thijs,

On Fri, May 17, 2019 at 3:47 AM Thijs ter Horst <gmterhorst@gmail.com> wrote:

Show 24 quoted lines

>
> 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