Re: [RFC/PATCH 11/18] merge: Add a new --index-only option, not yet implemented

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2016, 22:33 UTC
Message-ID: <xmqqzit3u3x5.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1460098726-5958-12-git-send-email-newren@gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 6 quoted lines

> +--index-only::
> +	Perform merge on index only, leaving working tree alone.  Most
> +	users do NOT want to use this flag, as it will leave the
> +	working tree and the index completely out of sync, which is
> +	very likely to confuse users and prevent a subsequent 'git
> +	merge --abort' from working.

This whole paragraph is a strong sign that this feature as-is is not a good addition.

On the other hand ...

> +	It is intended for script
> +	writers to have a way to easily check whether a merge would
> +	succeed and which files would conflict, typically from bare
> +	clones.

... this may be a good goal to aim for, but I think you are understating. You seem to be wanting a lot more than "easily check whether..."; isn't this more like "It is for scripts to create a merge and advance the branch when no need for manual conflict resolution in a bare repository, and to learn which paths would require manual conflicts when it fails", no?

I'd think either (1) limit this to bare repository only, or (2) do the "git merge --into master en/topic" I outlined in the other message, (or both) would be a sensible alternative for a feature whose description has to begin with "Most users do not want this".