From: Junio C Hamano <gitster@pobox•com>
To: Thomas Rast <tr@thomasrast•ch>
Cc: git@vger•kernel.org
Subject: Re: [PATCH v2 8/8] log --remerge-diff: show what the conflict resolution changed
Date: Wed, 26 Feb 2014 16:40:30 -0800 [thread overview]
Message-ID: <xmqqbnxt1j7l.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <75c29215c6a61fe1dc3f088f0fcd9acfa54f24fa.1393059605.git.tr@thomasrast.ch> (Thomas Rast's message of "Sat, 22 Feb 2014 10:17:56 +0100")
Thomas Rast <tr@thomasrast•ch> writes:
> diff --git a/log-tree.c b/log-tree.c
> index 30b3063..9b831e9 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -11,6 +11,8 @@
> #include "gpg-interface.h"
> #include "sequencer.h"
> #include "line-log.h"
> +#include "cache-tree.h"
> +#include "merge-recursive.h"
>
> struct decoration name_decoration = { "object names" };
>
> @@ -723,6 +725,300 @@ static int do_diff_combined(struct rev_info *opt, struct commit *commit)
> }
>
> /*
> + * Helpers for make_asymmetric_conflict_entries() below.
> + */
> +static char *load_cache_entry_blob(struct cache_entry *entry,
> + unsigned long *size)
> +{
I briefly wondered if this helper need to know about contents
conversions (e.g. smudge/clean or crlf), but not doing any of that
*is* the right thing to do. IOW, I agree with what this part of the
patch does.
But it feels, at least to me, that this helper function ...
> +static void strbuf_append_cache_entry_blob(struct strbuf *sb,
> + struct cache_entry *entry)
> +{
... and this one are overly specific. Why should they know about
(and limit themselves to operate on) cache-entry type? Isn't it too
much to ask for the caller to say "entry->sha1" instead of "entry"?
I do not have an issue with a "load_blob()" helper that makes sure
what it reads is a blob, though, of course.
> +static void assemble_conflict_entry(struct strbuf *sb,
> + const char *branch1,
> + const char *branch2,
> + struct cache_entry *entry1,
> + struct cache_entry *entry2)
> +{
> + strbuf_addf(sb, "<<<<<<< %s\n", branch1);
> + strbuf_append_cache_entry_blob(sb, entry1);
> + strbuf_addstr(sb, "=======\n");
> + strbuf_append_cache_entry_blob(sb, entry2);
> + strbuf_addf(sb, ">>>>>>> %s\n", branch2);
> +}
> +
> +/*
> + * For --remerge-diff, we need conflicted (<<<<<<< ... >>>>>>>)
> + * representations of as many conflicts as possible. Default conflict
> + * generation only applies to files that have all three stages.
> + *
> + * This function generates conflict hunk representations for files
> + * that have only one of stage 2 or 3. The corresponding side in the
> + * conflict hunk format will be empty. A stage 1, if any, will be
> + * dropped in the process.
> + */
> +static void make_asymmetric_conflict_entries(const char *branch1,
> + const char *branch2)
> +{
I should comment on this one in a separate message after I read it
over once again.
> +}
> +
> +/*
> + * --remerge-diff doesn't currently handle entries that cannot be
> + * turned into a stage0 conflicted-file format blob. So this routine
> + * clears the corresponding entries from the index. This is
> + * suboptimal; we should eventually handle them _somehow_.
> +*/
> +static void drop_non_stage0()
"static void drop_non_stage0(void)"
prev parent reply other threads:[~2014-02-27 0:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-22 9:17 [PATCH v2 0/8] log --remerge-diff Thomas Rast
2014-02-22 9:17 ` [PATCH v2 1/8] merge-recursive: remove dead conditional in update_stages() Thomas Rast
2014-02-22 9:17 ` [PATCH v2 2/8] merge-recursive: internal flag to avoid touching the worktree Thomas Rast
2014-02-22 9:17 ` [PATCH v2 3/8] merge-recursive: -Xindex-only to leave worktree unchanged Thomas Rast
2014-02-23 9:07 ` Eric Sunshine
2014-02-23 11:57 ` Thomas Rast
2014-02-23 18:42 ` Eric Sunshine
2014-02-22 9:17 ` [PATCH v2 4/8] combine-diff: do not pass revs->dense_combined_merges redundantly Thomas Rast
2014-02-22 9:17 ` [PATCH v2 5/8] Fold all merge diff variants into an enum Thomas Rast
2014-02-22 9:17 ` [PATCH v2 6/8] merge-recursive: allow storing conflict hunks in index Thomas Rast
2014-02-22 9:17 ` [PATCH v2 7/8] name-hash: allow dir hashing even when !ignore_case Thomas Rast
2014-02-23 9:19 ` Eric Sunshine
2014-09-06 17:46 ` Thomas Rast
2014-02-27 23:20 ` Junio C Hamano
2014-02-22 9:17 ` [PATCH v2 8/8] log --remerge-diff: show what the conflict resolution changed Thomas Rast
2014-02-27 0:40 ` 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=xmqqbnxt1j7l.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