[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: namespace conflict != package Conflict?



ucko@debian.org (Aaron M. Ucko) wrote:
> > The cogito /usr/bin/git is a tiny little helper script hardly worth its
> > inode, but it's in the upstream package and I dont want to remove it or
> > rename it.
> 
> As others have asked, why not?  Does anything actually rely on the
> script existing by that name?

I believe the nature of cogito's "git" command is such that renaming it
would make less sense than removing it.  And just removing it from the
upstream package seems pretty lame, but maybe that's the thing to do.

cogito currently includes & extends an upstream package called 'git'
(they may split in the future, let's hope they rename git-as-in-cogito
before then).  Cogito's git includes many commands with names of
the form "git-$FUNCTION-script", with the idea that it's easier to
command-line-complete them if the $FUNCTION is part of the command-name
(as opposed to "svn commit", etc).  The loyal opposition was placated
with the "git" command, which runs "git-$1-script" with the remaining
arguments.

Renaming git to something longer & more complicated seems to contradict
this goal; users would be better off calling the original commands that
git wraps.


That was my thinking.


Aaron Ucko's suggestion of trying to tell, from the command-line
arguments, wether the user wants git-from-cogito or git-from-git seems
incredibly brittle.  git-from-git can take a directory as the first
argument, so if you try to use git-from-git to look at a directory with
a name like "log" or "tag", it'll run git-from-cogito instead (because
git-log-script and git-tag-script exist).


Hm, given that git-from-cogito seems to have a fatal flaw (it doesnt
shift the script name out of the arguments list), I'm guessing it's
not widely used.  I'll request that the upstream people remove it from
the distribution.

If they agree, the issue will be solved I think.  (cogito wants to install
a git(7) manpage, which will not conflict with GNU Interactive Tools'
git(1) page.)

If they dont agree (and they're a cantankerous bunch, hi to all my
friends on the git list) we'll have to come up with something else...


-- 
Sebastian Kuzminsky



Reply to: