From: Kevin Bracey <kevin@bracey.fi>
To: git@vger.kernel.org
Subject: Re: Locating merge that dropped a change
Date: Thu, 11 Apr 2013 20:28:37 +0300 [thread overview]
Message-ID: <5166F2C5.4020803@bracey.fi> (raw)
In-Reply-To: <51645749.8090402@bracey.fi>
On 09/04/2013 21:00, Kevin Bracey wrote:
>
> So, how to automatically find a merge that ignored a known change?
I think I've found the problem. It only doesn't work _if you specify the
file_.
Specifically, if I was missing an addition, my first attempt to find it
would be
git log -p -m -S<addition> <file>
If the addition was lost in a merge, that doesn't even show the
addition, which is surprising, but intentional. The addition isn't part
of the HEAD version of <file>, so no point going down that path of the
merge. Fine. However, I expected this to work:
git log --full-history -p -m -S<addition> <file>
But it doesn't. It finds the addition, but _not_ the loss in the merge
commit.
But this does work:
git log -p -m -S<addition>
That really feels like a bug to me. By specifying a file, I've made it
miss the change, and I can see no way to get the change without making
it a full-tree operation.
Looking at try_to_simplify_commit() it appears the merge that removed
the addition is excluded because it's TREESAME to its _other_ parent.
But with --full-history, we should only be eliminating a merge if its
TREESAME to all parents, surely? Otherwise we have this case that we
show a commit but not its reversion.
And the code doing this looks broken, or at least illogical - the parent
loop sets "tree_same" for a same parent in --full-history, rather than
immediately setting the TREESAME flag, so maybe previous authors were
thinking about this. But setting tree_same guarantees that TREESAME is
always set on exit anyway, so it's pointless (unless I'm missing something).
It does appear this is documented behaviour in the manual: "full-history
without parent rewriting" .. "P and M were excluded because they are
TREESAME to _a_ parent." I would say that they should have been excluded
due to being TREESAME to _all_ parents. I really don't want a merge
where one version of my file was chosen over another excluded from its
so-called "full history".
Now, obviously in a sane environment, most merges won't be that
interesting, as they'll just be propagating wanted patches from the real
commits already in the log. But I'd like some way to find merges that
drop code in a specified file, and surely "--full-history" is it?
Kevin
next prev parent reply other threads:[~2013-04-11 17:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 18:00 Locating merge that dropped a change Kevin Bracey
2013-04-11 17:28 ` Kevin Bracey [this message]
2013-04-11 19:21 ` Junio C Hamano
2013-04-22 19:23 ` [RFC/PATCH] Make --full-history consider more merges Kevin Bracey
2013-04-22 19:49 ` Junio C Hamano
2013-04-23 16:35 ` Kevin Bracey
2013-04-24 22:34 ` Junio C Hamano
2013-04-25 1:59 ` Junio C Hamano
2013-04-25 15:48 ` Kevin Bracey
2013-04-25 16:51 ` Junio C Hamano
2013-04-25 17:11 ` Kevin Bracey
2013-04-25 18:19 ` Junio C Hamano
2013-04-26 19:18 ` Kevin Bracey
2013-04-26 19:31 ` [RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges Kevin Bracey
2013-04-26 19:31 ` [RFC/PATCH 2/3] simplify-merges: never remove all TREESAME parents Kevin Bracey
2013-04-27 23:02 ` Junio C Hamano
2013-04-28 7:10 ` Kevin Bracey
2013-04-28 18:09 ` Junio C Hamano
2013-04-26 19:31 ` [RFC/PATCH 3/3] simplify-merges: drop merge from irrelevant side branch Kevin Bracey
2013-04-27 22:36 ` [RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges Junio C Hamano
2013-04-27 22:57 ` David Aguilar
2013-04-28 7:03 ` Kevin Bracey
2013-04-28 18:38 ` Junio C Hamano
2013-04-29 17:46 ` Kevin Bracey
2013-04-29 18:11 ` Junio C Hamano
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=5166F2C5.4020803@bracey.fi \
--to=kevin@bracey.fi \
--cc=git@vger.kernel.org \
/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
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
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).