Git development
 help / color / mirror / Atom feed
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

  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