Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

From: Pierre Habouzit <madcoder@debian.org>
Date: Dec 11, 2007, 16:07 UTC
Message-ID: <20071211160744.GE15448@artemis.madism.org>
In-Reply-To: <20071211154841.GA29805@elte.hu>

On Tue, Dec 11, 2007 at 03:48:41PM +0000, Ingo Molnar wrote:

Show 10 quoted lines

> if we are growing legacies in git this fast it will turn itself into CVS 
> very quickly, give or take 20 years ;-) I think a straightforward usage 
> model is paramount, so phasing out such inconsistencies as early as 
> possible in the project's lifetime should be a priority IMHO. Git has a 
> very, very 'refreshing' approach to information management, and that 
> should permeate it all across. It's easy to be "fresh" in the beginning 
> of a project - maintaining freshness for years is a lot harder. (i dont 
> suggest to break compatibility, but to be aware of such inconsitencies 
> and make it a priority to get rid of them. It does not help that such 
> inconsistencies are only apparent to git newbies.)

  Well that's what deprecation is for, but you cannot do that on short
timeframes.

Show 7 quoted lines

> for example, if i type "git-checkout" in a Linux kernel tree, it just 
> sits there for up to a minute, and "does nothing". That is totally 
> wrong, human-interaction wise. Then after a minute it just returns. What 
> happened? Why? Where? A newbie would then try "git-checkout -v", using 
> the well-established "verbose" flag, but that gives:
> 
>  Usage: /usr/bin/git-checkout [-q] [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]

not anymore:

    $ git checkout -v
    error: unknown switch `v'
    usage: git-branch [options] [<branch>] [<paths>...]

	-b ...                create a new branch started at <branch>
	-l                    create the new branchs reflog
	--track               tells if the new branch should track the remote branch
	-f                    proceed even if the index or working tree is not HEAD
	-m                    performa  three-way merge on local modifications if needed
	-q, --quiet           be quiet

Not all commands are migrated to this new scheme though.

The next git has a _lot_ of things done better wrt UI and such issues. Though some backward incompatible changes must be introduced with the proper deprecation warnings, so that people can adapt.

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