Re: [PATCH] unpack-trees: don't shift conflicts left and right

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 16, 2013, 00:56 UTC
Message-ID: <7va9mqlvpu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1371339883-22775-1-git-send-email-rene.scharfe@lsrfire.ath.cx>

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> If o->merge is set, the struct traverse_info member conflicts is shifted
> left in unpack_callback, then passed through traverse_trees_recursive
> to unpack_nondirectories, where it is shifted right before use.

Show 23 quoted lines

> @@ -807,13 +802,6 @@ static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, str
>  
>  	/* Now handle any directories.. */
>  	if (dirmask) {
> -		unsigned long conflicts = mask & ~dirmask;
> -		if (o->merge) {
> -			conflicts <<= 1;
> -			if (src[0])
> -				conflicts |= 1;
> -		}
> -
>  		/* special case: "diff-index --cached" looking at a tree */
>  		if (o->diff_index_cached &&
>  		    n == 1 && dirmask == 1 && S_ISDIR(names->mode)) {
> @@ -832,7 +820,7 @@ static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, str
>  			}
>  		}
>  
> -		if (traverse_trees_recursive(n, dirmask, conflicts,
> +		if (traverse_trees_recursive(n, dirmask, mask & ~dirmask,
>  					     names, info) < 0)
>  			return -1;
>  		return mask;

This loses the bottom bit (i.e. are we merging and do have an index entry?) passed to traverse_trees_recursive(), but when that bitmask comes back to our callback, we immediately discard the bottom bit by shifting before using it in unpack_nondirectories(), so this seems a valid clean-up.

One thing renaming df_conficts to conflicts really proves is that this field is not used by the traverse_trees machinery at all.

Before this patch, the bits in conflicts (now df_conflicts) mask had the semantics that is not consistent with the dirmask/mask the tree-walk machinery uses to communicate with its callers and callbacks. Everything in tree-walk.[ch] is about "walk N trees", and bit 0 of dirmask and mask always means the first tree, not "first tree, or in index if the callback is doing a merge", which is used in the conflicts field before this patch.

I think the true source of the confusion is that the "conflicts" field does not logically belong there. It is not needed in the general "walk N trees" machinery.

The information is only useful for the unpack_trees callback, and "info->data" is a more appropriate place to hang such a callback specific data.

Perhaps we should use info->data field to point at

	struct {
        	struct unpack_trees_options *o;
                unsigned long df_conflict;
	};

and get rid of info->conflicts field?