From: Junio C Hamano <gitster@pobox•com>
To: Linus Torvalds <torvalds@linux-foundation•org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix•de>,
"Stephen Rothwell" <sfr@canb•auug.org.au>,
"James Morris" <jmorris@namei•org>,
linux-next@vger•kernel.org, linux-kernel@vger•kernel.org,
git@vger•kernel.org, "Jeff King" <peff@peff•net>
Subject: Re: linux-next: manual merge of the security-testing tree with the tree
Date: Thu, 30 Jun 2011 11:52:17 -0700 [thread overview]
Message-ID: <7v4o37qhi6.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <BANLkTi=usrsF60Popfu55v3_dXe7Yo0GrA@mail.gmail.com> (Linus Torvalds's message of "Thu, 30 Jun 2011 09:20:35 -0700")
Linus Torvalds <torvalds@linux-foundation•org> writes:
> It would be lovely if "git show" (and log operations) had some option
> to do a "expensive merge check" and did actually figure out the common
> ancestor and at least took that into account.
>
> It would be doable to do it at least better than we do now - the
> common ancestor is not cheap to compute, but it's much cheaper than a
> full merge, and would at least allow us to flag dangerous merges. Of
> course, it gets fun when there are multiple common ancestors and
> renames. It's entirely possible that it's never going to be practical
> to do anything but "re-do the merge and compare result".
I would have to say that it would boil down to "re-do the merge" whichever
way we implement it, and it is not necessarily a bad thing.
There are ideas to implement a mode of "git merge" that works entirely
in-core without touching the working tree (it may have to write temporary
blobs and possibly trees to the object store, though). It would let sites
like github to let its users accept a trivial pull request that can merge
cleanly on site in the browser without necessarily having to have a local
checkout used for conflict resolution.
If such an "in-core merge" feature is implemented cleanly in a reusable
way, it would be just the matter of comparing the output from it with the
actual committed result.
Of course, if the committed result was deliberately made by "-s ours",
comparison between an auto-merge result and the committed result would
produce a lot of noise, but that is really the point of "expensie merge
check", so the noise in that scenario is a feature, not a bug.
next prev parent reply other threads:[~2011-06-30 18:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 4:29 linux-next: manual merge of the security-testing tree with the tree Stephen Rothwell
2011-06-30 4:33 ` Stephen Rothwell
2011-06-30 4:39 ` Stephen Rothwell
2011-06-30 5:22 ` James Morris
2011-06-30 5:53 ` Stephen Rothwell
2011-06-30 7:25 ` Uwe Kleine-König
2011-06-30 9:30 ` Stephen Rothwell
2011-06-30 12:17 ` Uwe Kleine-König
2011-06-30 16:20 ` Linus Torvalds
2011-06-30 18:52 ` Junio C Hamano [this message]
2011-06-30 19:13 ` Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v4o37qhi6.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jmorris@namei$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=torvalds@linux-foundation$(echo .)org \
--cc=u.kleine-koenig@pengutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox