Re: Joining cg-*-id

From: Petr Baudis <pasky@suse.cz>
Date: Sep 19, 2005, 22:58 UTC
Message-ID: <20050919225838.GH18320@pasky.or.cz>
In-Reply-To: <1127169021.26772.58.camel@dv>

Dear diary, on Tue, Sep 20, 2005 at 12:30:21AM CEST, I got a letter where Pavel Roskin <proski@gnu.org> told me that...

Show 10 quoted lines

> On Mon, 2005-09-19 at 23:56 +0200, Petr Baudis wrote:
> > Dear diary, on Mon, Sep 19, 2005 at 11:40:49PM CEST, I got a letter
> > where Pavel Roskin <proski@gnu.org> told me that...
> > > I believe Cogito should keep the command list short.  When the *-id
> > > utilities got the cg-prefix, the list became longer by 3 commands.
> > 
> > well, those commands are semi-public, actually. E.g. cg-help does not
> > list them.
> 
> But cg-<TAB><TAB> does.

Good point.

Show 13 quoted lines

> > > What if we join cg-commit-id, cg-parent-id and cg-tree-id into one cg-id
> > > (or cg-admin-id) utility?  It would work like cg-commit-id in absence of
> > > switches, -p would make it work like cg-parent-id, and -t would make it
> > > cg-tree-id.
> > 
> > Perhaps cg-object-id? I'm not principially opposed to that, but I don't
> > see much value in it either. Perhaps if this would come along with
> > the usage of git-rev-parse (see below)...
> 
> The value is having one command, one manpage and one place to fix little
> bugs and add more functionality.  Potentially, cg-Xnormid could be
> incorporated into that script, so bash wouldn't have to open one more
> file.

Well, cg-Xnormid is basically pointless if it's not going to be a common backend for multiple other commands. So I'd say either supersede it with git-rev-parse or just merge it with cg-object-id.

> Please don't apply my patch yet - I forgot to document the optional
> argument.  I'll try to make cg-object-id now.

Which patch?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.