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@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgplp6n0JvkYy.pgp
Description: PGP signature
