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

From: Pierre Habouzit <madcoder@debian.org>
Date: Oct 30, 2008, 13:24 UTC
Message-ID: <20081030132453.GB24098@artemis.corp>
In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net>

On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote:

Show 6 quoted lines

> +Add/rm/reset/checkout/revert
> +----------------------------
> +
> +Many find these confusing.
> +
> +  * 'git stage' would do what 'git add' does now.

  -> git stage -i/-p shall do what git add -i/-p does.

> +
> +  * 'git unstage' would do what 'git reset --' does now

  -> likely we need a git unstage -i/-p to interactively unstage some
     bits.

* 'git track' would do what git add -N does now.

* 'git untrack' would do what 'git rm --cached' does now.

> +  * 'git undo' would do what 'git checkout HEAD --' does now

I'm not really a fan of this one. Undo is too unspecific (I know at least 2 people using that for git reset --hard HEAD~1 and 1 other for an alias to git reset --hard HEAD@{1}).

I have no constructive proposal to replace it though, but I believe git undo would cause lots of harm. Would it be for another command, it wouldn't be a problem, but git undo *LOSES* information by design (the local changes on a file), and it would override aliases that people could have done on it. Choosing it has consequences.

Show 7 quoted lines

> +Working with patches
> +--------------------
> +
> +  * 'git send-email' should prompt for all SMTP-related information
> +    about sending e-mail when it is running with no configuration.
> +    Because these days /usr/lib/sendmail is rarely configured
> +    correctly.

And when the user answer them, it should set them (a bit like zsh does when it's run from the first time e.g.)

Show 5 quoted lines

> +
> +  * other git send-email functionality which has bitten people -
> +    particularly building the recipient list - should prompt for
> +    confirmation until configured to be automatic.
> +

  * 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.

  * 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).

Show 16 quoted lines

> +  * 'git am -3' the default; with global option to make it not the
> +    default for those that prefer the speed of -2
> +
> +
> +Submodules
> +----------
> +
> +  * submodules should be able to refer to symbolic ref names, svn
> +    style - in the .gitmodules file.  The actual commit used is still
> +    recorded in the index.
> +
> +  * when switching branches, if the checked out revision of a submodule
> +    changes, then it should be switched as well
> +
> +  * 'git submodule update' should be able to be triggered when
> +    switching branches (but not be the default behaviour)

Actually on this one, I'd say that a submodule is either non initialized (in which case we don't care) or it is. If it is, switching branches should probably trigger a submodule update if the switch isn't possible (because the dereferenced sha1 doesn't exists). Or alternatively it should make the whole branch switch fail.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org