From: Junio C Hamano <gitster@pobox•com>
To: Thomas Rast <tr@thomasrast•ch>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 0/9] remerge diff proof of concept/RFC
Date: Tue, 04 Feb 2014 15:04:35 -0800 [thread overview]
Message-ID: <xmqq1tzi7a4c.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <cover.1391549294.git.tr@thomasrast.ch> (Thomas Rast's message of "Tue, 4 Feb 2014 23:17:29 +0100")
Thomas Rast <tr@thomasrast•ch> writes:
> log --remerge-diff: show what the conflict resolution changed
Yay ;-)
> This series explores another angle, which I call "remerge diff". It
> works by re-doing the merge in core, using features from patches 1-3
> and 7. Likely that will result in conflicts, which are formatted in
> the usual <<<<<<< way. Then it diffs this "remerge" against the
> merge's tree that is recorded in history.
Yup, that is the obvious way to recreate what would have been shown
to the person who recorded the merge result. I like that approach.
> So I would welcome comments, and/or better ideas, on the following
> proposed resolution:
>
> * Implement what I described last, to take care of delete/modify
> conflicts.
Naively, I would have thought that
- If the recorded result of the merge does not have the path, then
show the deletion of the contents relative to the side that
modified it.
- If the recorded result of the merge has the path, then show the
change between the side that modified it and the recorded result.
might be more useful. Then we will know what we lost in full (if
the recorded result is to "delete" it), but it is very likely that
we won't see anything if the recorded result blindly took what the
modifying side left. Comparing with the synthetic stages 2+3 will
at least show us there was something funky going on, so your
approach would be reasonable in this case.
> * Punt on more complex conflicts, by removing those files from the
> index, and emitting a warning about those files instead.
Sensible.
prev parent reply other threads:[~2014-02-04 23:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 22:17 [PATCH 0/9] remerge diff proof of concept/RFC Thomas Rast
2014-02-04 22:17 ` [PATCH 1/9] merge-recursive: remove dead conditional in update_stages() Thomas Rast
2014-02-04 22:17 ` [PATCH 2/9] merge-recursive: internal flag to avoid touching the worktree Thomas Rast
2014-02-04 22:17 ` [PATCH 3/9] merge-recursive: -Xindex-only to leave worktree unchanged Thomas Rast
2014-02-04 22:17 ` [POC PATCH 4/9] pretty: refactor add_merge_info() into parts Thomas Rast
2014-02-04 22:17 ` [POC PATCH 5/9] log: add a merge base inspection option Thomas Rast
2014-02-04 22:17 ` [PATCH 6/9] combine-diff: do not pass revs->dense_combined_merges redundantly Thomas Rast
2014-02-04 22:17 ` [PATCH 7/9] Fold all merge diff variants into an enum Thomas Rast
2014-02-04 22:17 ` [PATCH 8/9] merge-recursive: allow storing conflict hunks in index Thomas Rast
2014-02-04 22:17 ` [RFC PATCH 9/9] log --remerge-diff: show what the conflict resolution changed Thomas Rast
2014-02-04 23:04 ` Junio C Hamano [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:
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=xmqq1tzi7a4c.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=tr@thomasrast$(echo .)ch \
/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