git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: git-log on a file, and merges
Date: Fri, 2 Aug 2019 21:21:28 +0200	[thread overview]
Message-ID: <CAA01CspHCKA3itmTxFO1NeNB6DpdFx3CTbXKtO=TvtznLn_zAg@mail.gmail.com> (raw)
In-Reply-To: <05c77291-48d1-a592-6296-d8a8bdb16b02@gmail.com>

On Fri, Aug 2, 2019 at 4:22 PM Derrick Stolee <stolee@gmail.com> wrote:
>
> On 8/2/2019 5:38 AM, Piotr Krukowiecki wrote:
> > Hi,
> >
> > I have merged a branch into master.
> >
> > When on master I do "git log -- some/file", it does not show commits
> > from merged branch (which I know they changed the file).
> > I have to add "--full-history" to see the commits.
> > When I run "git log" (without "-- some/file") I can see the commits
> > without using "--full-history".
> >
> > This seems not logical, and contrary to user expectations. Harmful even ;)
> >
> > Am I missing something?
>
> Hi Piotr,
>
> You are falling victim to an issue related to file history simplification [1]
> and a (probably) bad merge. You can read more about how this can happen at [2].
>
> When git log reaches a merge commit and one of the parents matches that path
> exactly, only that parent is walked. The other is ignored. In some sense, the
> other commit did not contribute changes to that file (because we only took
> changes from the other parent). This makes the history look good and enables
> some performance boosts.
>
> Basically, someone must have gotten a merge conflict and used "-S ours" to
> wipe away the changes from the other branch on that file. You can find that
> merge by running
>
>         git log --full-history --simplify-merges -- some/file
>
> You will see the merge commit that un-did the change somewhere above the
> commit you are expecting to see in the history.
>
> Thanks,
> -Stolee
>
>
> [1] https://git-scm.com/docs/git-log#_history_simplification
> [2] https://docs.microsoft.com/en-us/azure/devops/repos/git/git-log-history-simplification?view=azure-devops

Thanks for explaining.

There was no "bad" merge. The file was modified only on the branch
(and previously in common history).

There were two commits to this file on the branch, older one did some
changes, later one reverted the changes (among other things).

So my understanding is that git looked at the merge commit, saw that
this file was the same as it was before the merge, and assumed that
there were no commits which modified this file in the branches being
merged, so it didn't bother looking at the branch history.

At this moment I'm not sure myself if I consider this a bug or not.
Maybe if I look at merge commits as a special entity - not a diverging
history, but rather a single commit which introduces some changes -
then maybe I could accept it.
But on the other hand I feel this generates wrong results. Falsifies
history. If I was asking about "diff", I would understand if it showed
nothing, as there was no difference. But I'm asking for "log".
Especially that I remembered/checked that there were some changes to
this file, and wanted to see them.


Anyway, is there a way to disable this behavior (enable
"--full-history"?) by default?
I suspect that this behavior will bite me in future, and I guess the
"performance gains" are not big enough to validate it...



-- 
Piotr Krukowiecki

  reply	other threads:[~2019-08-02 19:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02  9:38 Piotr Krukowiecki
2019-08-02 14:22 ` Derrick Stolee
2019-08-02 19:21   ` Piotr Krukowiecki [this message]
2019-08-02 19:32     ` Junio C Hamano
2019-08-03  8:31       ` Piotr Krukowiecki

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CAA01CspHCKA3itmTxFO1NeNB6DpdFx3CTbXKtO=TvtznLn_zAg@mail.gmail.com' \
    --to=piotr.krukowiecki@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=stolee@gmail.com \
    --subject='Re: git-log on a file, and merges' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

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