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

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

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

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

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

+  * '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