Re: [PATCH] Documentation: add a planning document for the next CLI revamp

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 2, 2008, 21:53 UTC
Message-ID: <7vy70123rr.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081030132453.GB24098@artemis.corp>

Pierre Habouzit <madcoder@debian.org> writes:

> * 'git track' would do what git add -N does now.
> * 'git untrack' would do what 'git rm --cached' does now.

Ok with me up to here.

>> +  * 'git undo' would do what 'git checkout HEAD --' does now
> ...
> I have no constructive proposal to replace it though, but I believe git
> undo would cause lots of harm.

I'm in agreement.

>   * git-send-email should be either more interactive, or less: either
>     just use the damn configuration, or propose a mode where it spawns
>     an editor for each patch so that you can add further comments.

In principle I'd agree, but I use send-email non-interactively myself (I type Meta/SE where Meta is an independent checkout of my 'todo' branch), so I am not sure if the "just use the configuration" is an added requirement. I also have this in .git/config in the repo:

        [sendemail]
                smtpserver = /usr/bin/msmtp
                to = git@vger.kernel.org
                suppressfrom
                signedoffcc = false

>   * git-send-email should be able to format-patches by himself (IOW
>     accept most of format-patch arguments and deal with the patch list
>     by himself, which is usable if the previous point is implemented).

I earlier was against this, mostly out of the "each tool to do the job it was designed to do well" principle, but with your workflow description and Peff's comment, I am open to add this kind of "run format-patch internally" wrapper behaviour to send-email which is already a Porcelain anyway.

>> +  * 'git am -3' the default; with global option to make it not the
>> +    default for those that prefer the speed of -2

I am moderately negative on this, but not because of performance concern.

The --3way fall back is done only when it is necessary, and there is no "prefer the speed" involved. It is between "stop when the patch does not apply because there may be something iffy going on" and "assume it is Ok in such an iffy case to pretend that you apply the patch to the original copy and cherry-pick the result to your updated tree". IOW, it is a safety concern.