Re: force "unmerged" for same-file auto-merges
- From
Sitaram Chamarty <sitaramc@gmail.com>
- Date
- Mar 27, 2010, 08:56 UTC
- Message-ID
- <2e24e5b91003270156r11ae9155s6e00a2ab27e9f479@mail.gmail.com>
- In-Reply-To
- <hobqoc$5h3$1@dough.gmane.org>
On Wed, Mar 24, 2010 at 7:14 AM, Neal Kreitzinger <neal@rsss.com> wrote:
> Scenario: "same-file auto-merge": when two different people change the > same file in their separate repos. Their changes do not conflict in the > sense that they are changes to the same lines. However, their changes do > conflict in the sense that the resulting merged logic is incorrect.
You're not being pessimistic enough :-) A ".h" file that changed only on one side can cause the same logic issues
Show 6 quoted lines
> Desired Solution: > Perform same-file auto-merge and produce auto-merge results, but mark all > such auto-merged files as "unmerged" so that they must be reviewed/resolved > before a git-commit. The "unmerged" status allows git-mergetool to be run > (e.g. kdiff3) so that the merged lines can be reviewed. In this way, all > auto-merged files are reviewed.
No. What you need is a full blown diff for the merge, with both sides being compared with respect to the common merge-base. That diff will be pretty big, although I'm not sure what diff options would actually produce that (but I'll bet "-m" figures somewhere).