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

From: Pierre Habouzit <madcoder@debian.org>
Date: Oct 31, 2008, 08:20 UTC
Message-ID: <20081031082015.GA21015@artemis.corp>
In-Reply-To: <1225435238.20883.18.camel@maia.lan>

On Fri, Oct 31, 2008 at 06:40:38AM +0000, Sam Vilain wrote:

Show 8 quoted lines

> On Thu, 2008-10-30 at 20:31 -0400, Jeff King wrote:
> > >  Some suggestions, which have been briefly scanned over by some of the
> > >  (remaining) GitTogether attendees.  Please keep it constructive!  :)
> > Thanks for putting this together.
> 
> No problem!  Thanks for responding.  I've been amazed that it seems to
> have been largely taken well :)  But there are still very important
> changes required.

Well, most of it we discussed IRL, that helps tremendously ;)

> I still think it's OK to use 'git revert-files' for this; it just seems
> so long.  Switches could specify where to and from.

Well the point is we will probably just deprecate git-revert and remove it alltogether in git 2.6. At that time you will be able to define git-revert as an alias to git cherry-pick -R if you're an old fart, or git revert-files if you're an svn user ;)

But I see no convincing name that hasn't "revert" in them, hence will be long :/

> Of course 'git branch -q' would then be the quick version, or 'git
> br' (after git config --global alias.br 'branch -q')

oh no, not -q please, -q is quiet, -h is help, -v is verbose. I mean POSIX should define these. Do not give those switch any other kind of sementics anymore, we've done that, and it hurts. -Q is fine with me though.

> Another command people often want is 'git info' to tell them stuff like
> they might get from 'git status' or 'git remote' but without all the
> file details...

And to say to them if they're in the midle of a merge, of a rebase, an am, on a detached, head, .... what is in the __git_ps1 of bash actually.

Show 18 quoted lines

> > > +  * 'git init --server' (or similar) should do everything required for
> > > +    exporting::
> > > +----
> > > +chmod -R a+rX
> > > +touch git-daemon-export-ok
> > > +git gc
> > > +git update-server-info
> > > +chmod u+x .git/hooks/post-update
> > > +git config core.sharedrepository=1
> > > +----
> > 
> > But not all of those things are necessarily related, and some of them
> > have security implications. I would hate to get a bug report like "I
> > used --server because I wanted to share my content via dumb http, but my
> > repo was p0wned because of too-loose group permissions."
> 
> ok.  That should come down to the detail of how '--server' is specified,
> I think.  I'll expand on that during round 2.

What about git init --svn-like ? /me *ducks*

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