mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <>
To: Thijs ter Horst <>
Cc: Git Mailing List <>
Subject: Re: Resetting files during a merge causes loss of resetted change, invisible in commit logs.
Date: Fri, 17 May 2019 09:56:37 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Thijs,

On Fri, May 17, 2019 at 3:47 AM Thijs ter Horst <> 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 '', along with
> a shell script ( 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 may be of interest
to you)?


      reply	other threads:[~2019-05-17 16:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-17 10:28 Resetting files during a merge causes loss of resetted change, invisible in commit logs Thijs ter Horst
2019-05-17 16:56 ` Elijah Newren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).