threads / discuss / 6672

'git config' vs 'git repo-config'

Subject: 'git config' vs 'git repo-config'

## tl;dr

7 messages between Feb 4, 2007 and Feb 4, 2007.

replies: 6people: 3as markdown or json

Marco Costalba· Feb 4, 2007, 09:38 UTC · lore
Hi Junio,
  I've seen that 'git repo-config' has been renamed 'git config', but
old name is still available for back compatibility.
Do you plan to remove it in a near future?
Probably you already now why I'm asking this ;-)

Thanks Marco

Junio C Hamano· Feb 4, 2007, 09:47 UTC · re: Marco Costalba · lore

Re: 'git config' vs 'git repo-config'

"Marco Costalba" <mcostalba@gmail.com> writes:
>  I've seen that 'git repo-config' has been renamed 'git config', but
> old name is still available for back compatibility.

Exactly. While I do not think qgit uses them, fsck-objects and init-db also got shorter-and-sweeter synonyms.

> Do you plan to remove it in a near future?

Not me personally. The recent shorter-and-sweeter synonyms are too young to kick out their original names. We probably should wait for at least 6 months, preferrably longer, after the first major release that introduced them.

> Probably you already now why I'm asking this ;-)

No. But we should certainly draw up deprecation/removal schedule. It simply could be "never" ;-).

Marco Costalba· Feb 4, 2007, 10:00 UTC · re: Junio C Hamano · lore

Re: 'git config' vs 'git repo-config'

On 2/4/07, Junio C Hamano <junkio@cox.net> wrote:
Show 7 quoted lines
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > Probably you already now why I'm asking this ;-)
>
> No.  But we should certainly draw up deprecation/removal
> schedule.  It simply could be "never" ;-).
>
qgit needs to handle the text codec information 'i18n.commitencoding'
Junio C Hamano· Feb 4, 2007, 10:09 UTC · re: Marco Costalba · lore

Re: 'git config' vs 'git repo-config'

"Marco Costalba" <mcostalba@gmail.com> writes:
Show 9 quoted lines
> On 2/4/07, Junio C Hamano <junkio@cox.net> wrote:
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>>
>> > Probably you already now why I'm asking this ;-)
>>
>> No.  But we should certainly draw up deprecation/removal
>> schedule.  It simply could be "never" ;-).
>
> qgit needs to handle the text codec information 'i18n.commitencoding'
I thought you already fixed the header parser.  Is that a news?

I wonder what it has to do with the command deprecation/removal schedule...

Marco Costalba· Feb 4, 2007, 10:23 UTC · re: Junio C Hamano · lore

Re: 'git config' vs 'git repo-config'

On 2/4/07, Junio C Hamano <junkio@cox.net> wrote:
Show 7 quoted lines
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> >
> > qgit needs to handle the text codec information 'i18n.commitencoding'
>
> I thought you already fixed the header parser.  Is that a news?
>
The parser is fixed from some week already.

Codec info is shown to user when opens settings dialog and could be manually set by user there. If not present utf8 is assumed.

> I wonder what it has to do with the command deprecation/removal
> schedule...
>

I plan to release a point release after git-1.5 is out, so I'm wondering if renaming git-repo-config --> git-config also in qgit.

BTW  'git-repo-config' seems to be currently used also by StGit
Jakub Narebski· Feb 4, 2007, 10:36 UTC · re: Marco Costalba · lore

Re: 'git config' vs 'git repo-config'

Marco Costalba wrote:
> I plan to release a point release after git-1.5 is out, so I'm
> wondering if renaming git-repo-config --> git-config also in qgit.

This would mean that you cannot use new qgit with older git instalations. Not a good idea, I think...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Junio C Hamano· Feb 4, 2007, 10:52 UTC · re: Marco Costalba · lore

Re: 'git config' vs 'git repo-config'

"Marco Costalba" <mcostalba@gmail.com> writes:
Show 6 quoted lines
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> I plan to release a point release after git-1.5 is out, so I'm
> wondering if renaming git-repo-config --> git-config also in qgit.
>
> BTW  'git-repo-config' seems to be currently used also by StGit

It's really up to you and Catalin, but if you expect people might run with git 1.4.4, it would make more sense to stick with the tried-and-proven names and wait until you are reasonably sure that everybody you care about are running at least 1.5.0.

The only reason the in-tree scripts git.git ships with use the new names is because they know they are part of a revision that has them.

← back to recent threads