From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: geoffrey.russell@gmail.com, sverre@rabbelier.nl,
Johannes Sixt <j.sixt@viscovery.net>,
Miklos Vajna <vmiklos@frugalware.org>,
git@vger.kernel.org
Subject: Re: [PATCH 2/2] git-merge-recursive-{ours,theirs}
Date: Fri, 20 Jun 2008 13:58:52 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.1.00.0806201351370.6439@racer> (raw)
In-Reply-To: <7vbq1wo8ck.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Fri, 20 Jun 2008, Junio C Hamano wrote:
> diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
> index 4aa28a1..a355e7a 100644
> --- a/builtin-merge-recursive.c
> +++ b/builtin-merge-recursive.c
> @@ -650,9 +655,26 @@ static int merge_3way(mmbuffer_t *result_buf,
> fill_mm(a->sha1, &src1);
> fill_mm(b->sha1, &src2);
>
> + if (index_only)
> + favor = 0;
> + else {
> + switch (merge_recursive_variants) {
> + case MERGE_RECURSIVE_OURS:
> + favor = XDL_MERGE_FAVOR_OURS;
> + break;
> + case MERGE_RECURSIVE_THEIRS:
> + favor = XDL_MERGE_FAVOR_THEIRS;
> + break;
> + default:
> + favor = 0;
> + break;
> + }
Hrm. I would have preferred something like this:
if (!index_only && merge_recursive_variants == MERGE_RECURSIVE_OURS)
favor = XDL_MERGE_FAVOR_OURS;
if (!index_only && merge_recursive_variants == MERGE_RECURSIVE_THEIRS)
favor = XDL_MERGE_FAVOR_THEIRS;
else
favor = 0;
> + }
> + flag = LL_MERGE_FLAGS(index_only, favor);
> +
> merge_status = ll_merge(result_buf, a->path, &orig,
> &src1, name1, &src2, name2,
> - index_only);
> + flag);
Sorry, but in my opinion this flag mangling makes the whole code uglier.
Why not just add another parameter?
Or if you are really concerned about future enhancements to ll_merge(),
use a struct.
> @@ -1379,11 +1401,18 @@ int cmd_merge_recursive(int argc, const char **argv, const char *prefix)
> struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
> int index_fd;
>
> + merge_recursive_variants = 0;
> if (argv[0]) {
> int namelen = strlen(argv[0]);
> if (8 < namelen &&
> !strcmp(argv[0] + namelen - 8, "-subtree"))
> - subtree_merge = 1;
> + merge_recursive_variants = MERGE_RECURSIVE_SUBTREE;
> + else if (5 < namelen &&
> + !strcmp(argv[0] + namelen - 5, "-ours"))
> + merge_recursive_variants = MERGE_RECURSIVE_OURS;
> + else if (7 < namelen &&
> + !strcmp(argv[0] + namelen - 7, "-theirs"))
> + merge_recursive_variants = MERGE_RECURSIVE_THEIRS;
This just cries out loud for a new function suffixcmp().
I will not say anything about the long lines in git-merge.sh, since I
fully expect builtin-merge to happen Real Soon Now.
Anyhow, your comments about this driving the wrong workflow still apply.
Maybe we want to display them really, really prominently in
Documentation/merge-strategies.txt.
Ciao,
Dscho
next prev parent reply other threads:[~2008-06-20 13:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-16 4:16 Guided merge with override Geoff Russell
2008-06-16 9:25 ` Miklos Vajna
2008-06-16 10:16 ` Johannes Sixt
2008-06-16 21:16 ` Miklos Vajna
2008-06-16 22:21 ` Sverre Rabbelier
2008-06-16 22:45 ` Geoff Russell
2008-06-17 20:04 ` Junio C Hamano
2008-06-18 15:19 ` Johannes Schindelin
2008-06-18 15:28 ` Johannes Schindelin
2008-06-18 16:31 ` Junio C Hamano
2008-06-18 19:29 ` Johannes Schindelin
2008-06-20 7:38 ` [PATCH 1/2] git-merge-file --ours, --theirs Junio C Hamano
2008-06-20 7:48 ` [PATCH 2/2] git-merge-recursive-{ours,theirs} Junio C Hamano
2008-06-20 12:58 ` Johannes Schindelin [this message]
2008-06-21 9:46 ` Junio C Hamano
2008-06-21 16:29 ` Johannes Schindelin
2008-06-21 16:56 ` Jakub Narebski
2008-06-17 6:16 ` Guided merge with override Johannes Sixt
2008-06-17 8:53 ` Sverre Rabbelier
2008-06-17 9:48 ` Johannes Schindelin
2008-06-17 9:53 ` Sverre Rabbelier
2008-06-17 10:17 ` Johannes Schindelin
-- strict thread matches above, loose matches on Subject: below --
2008-06-23 12:45 [PATCH 0/2] jc/merge-theirs, rebased on top of mv/merge-in-c Miklos Vajna
2008-06-23 12:45 ` [PATCH 2/2] git-merge-recursive-{ours,theirs} Miklos Vajna
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=alpine.DEB.1.00.0806201351370.6439@racer \
--to=johannes.schindelin@gmx.de \
--cc=geoffrey.russell@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@viscovery.net \
--cc=sverre@rabbelier.nl \
--cc=vmiklos@frugalware.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox