Re: Git's inconsistent command line options

Stefan Beller venit, vidit, dixit 01.09.2015 19:56: > On Tue, Sep 1, 2015 at 10:50 AM, Barry Warsaw wrote: >> On Sep 01, 2015, at 09:42 AM, Junio C Hamano wrote: >> >>> That way, you are forcing all the existing scripts to be updated to >>> say "git -c ..." for _all_ invocations

Re: Git's inconsistent command line options

David Aguilar venit, vidit, dixit 01.09.2015 11:28: > On Mon, Aug 31, 2015 at 10:25:58AM -0400, Barry Warsaw wrote: >> On Aug 31, 2015, at 05:10 PM, Duy Nguyen wrote: >> >>> I'm probably shot down for this. But could we go with a clean plate >>> and create a new command prefix (something like

Re: Git's inconsistent command line options

On Tue, Sep 1, 2015 at 10:50 AM, Barry Warsaw wrote: > On Sep 01, 2015, at 09:42 AM, Junio C Hamano wrote: > >>That way, you are forcing all the existing scripts to be updated to >>say "git -c ..." for _all_ invocations of Git they have, aren't you? > > No, why? If the default

Re: Git's inconsistent command line options

On Sep 01, 2015, at 09:42 AM, Junio C Hamano wrote: >That way, you are forcing all the existing scripts to be updated to >say "git -c ..." for _all_ invocations of Git they have, aren't you? No, why? If the default value enables the current ui, then no scripts need changing. Users can enable

Re: Git's inconsistent command line options

On Mon, Aug 31, 2015 at 10:25:58AM -0400, Barry Warsaw wrote: > On Aug 31, 2015, at 05:10 PM, Duy Nguyen wrote: > > >I'm probably shot down for this. But could we go with a clean plate > >and create a new command prefix (something like git-next, git2, or > >gt...)? We could then redesign the

Re: Git's inconsistent command line options

(Administrivia) please do not cull CC list when replying. Barry Warsaw writes: > On Sep 01, 2015, at 02:28 AM, David Aguilar wrote: > >>While a script writer could write, "git -c core.cliversion=1 ...", >>no one does that, no one wants to do that, and it just seems >>like a

Re: Git's inconsistent command line options

On Sep 01, 2015, at 02:28 AM, David Aguilar wrote: >While a script writer could write, "git -c core.cliversion=1 ...", >no one does that, no one wants to do that, and it just seems >like a bad idea that's best left unexplored. Sure, no one will do that from the command line, but I don't think

Re: Git's inconsistent command line options

On Aug 31, 2015, at 05:10 PM, Duy Nguyen wrote: >I'm probably shot down for this. But could we go with a clean plate >and create a new command prefix (something like git-next, git2, or >gt...)? We could then redesign the entire UI without worrying about >backward compatibility. At some point we

Re: Git's inconsistent command line options

On Wed, Aug 26, 2015 at 6:43 AM, Junio C Hamano wrote: > ... > > I do not see a good way to do such a safe transition with command > words approach, *unless* we are going to introduce new commands, > i.e. "git list-tag", "git create-tag", etc. I'm probably shot down for this.

Re: Git's inconsistent command line options

On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote: But notice that I said if you really want to. I personally think it is a road to madness. Agreed. I don't believe in command line API here. I think we'd need a better solution. My gut says: Live with the warts on old

Re: Git's inconsistent command line options

On Tue, Aug 25, 2015 at 11:28 PM, Andreas Schwab sch...@linux-m68k.org wrote: Jacob Keller jacob.kel...@gmail.com writes: if you really mean to create a tag named create, use git tag -- create master In all other uses of -- refs must be put on the *left* side. Andreas. Oops that

Re: Git's inconsistent command line options

Jacob Keller jacob.kel...@gmail.com writes: if you really mean to create a tag named create, use git tag -- create master In all other uses of -- refs must be put on the *left* side. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5

Re: Git's inconsistent command line options

Hilco Wijbenga hilco.wijbe...@gmail.com writes: On 25 August 2015 at 16:43, Junio C Hamano gits...@pobox.com wrote: I do not see a good way to do such a safe transition with command words approach, *unless* we are going to introduce new commands, i.e. git list-tag, git create-tag, etc.

Re: Git's inconsistent command line options

On Wed, Aug 26, 2015 at 3:52 PM, Philip Oakley philipoak...@iee.org wrote: From: Jacob Keller jacob.kel...@gmail.com On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote: But notice that I said if you really want to. I personally think it is a road to madness.

Re: Git's inconsistent command line options

From: Jacob Keller jacob.kel...@gmail.com On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote: But notice that I said if you really want to. I personally think it is a road to madness. Agreed. I don't believe in command line API here. I think we'd need a better solution.

Re: Git's inconsistent command line options

Jacob Keller jacob.kel...@gmail.com writes: On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote: But notice that I said if you really want to. I personally think it is a road to madness. Agreed. I don't believe in command line API here. I think we'd need a better

Re: Git's inconsistent command line options

On Wed, Aug 26, 2015 at 4:02 PM, Jacob Keller jacob.kel...@gmail.com wrote: On Wed, Aug 26, 2015 at 3:52 PM, Philip Oakley philipoak...@iee.org wrote: From: Jacob Keller jacob.kel...@gmail.com On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote: But notice that I said

Re: Git's inconsistent command line options

On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys grae...@gmail.com wrote: Even though I have worked with Git since 2009, I still have to reference the help to remind me of what parameter to use in certain situation simply because similar tasks differ so much. Maybe we could address this in

Re: Git's inconsistent command line options

On Tue, Aug 25, 2015 at 4:43 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: $ git tag --delete master $ echo $? # 0 # actually works as of today! $ git tag delete master # Due to the planned switch to command words, this doesn't work. # For

Git's inconsistent command line options

Hi, I've used Git for years and this has always bothered me. Has anybody else noticed the inconsistent command line parameteres for seemingly similar tasks. There are many examples, but I'll list only two (I can supply a more extensive list if needed). eg: Renaming things. * When working with

Re: Git's inconsistent command line options

On Tue, Aug 25, 2015 at 2:49 PM, Jacob Keller jacob.kel...@gmail.com wrote: On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano gits...@pobox.com wrote: On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys grae...@gmail.com wrote: Even though I have worked with Git since 2009, I still have to

Re: Git's inconsistent command line options

On Tue, Aug 25, 2015 at 3:06 PM, Stefan Beller sbel...@google.com wrote: On Tue, Aug 25, 2015 at 2:49 PM, Jacob Keller jacob.kel...@gmail.com wrote: On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano gits...@pobox.com wrote: On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys grae...@gmail.com

Re: Git's inconsistent command line options

Stefan Beller sbel...@google.com writes: $ git tag --delete master $ echo $? # 0 # actually works as of today! $ git tag delete master # Due to the planned switch to command words, this doesn't work. # For details see road map at `man git commandwords-roadmaps` $ echo $? # 128

Re: Git's inconsistent command line options

On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano gits...@pobox.com wrote: On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys grae...@gmail.com wrote: Even though I have worked with Git since 2009, I still have to reference the help to remind me of what parameter to use in certain situation

Re: Git's inconsistent command line options

On 25 August 2015 at 16:43, Junio C Hamano gits...@pobox.com wrote: I do not see a good way to do such a safe transition with command words approach, *unless* we are going to introduce new commands, i.e. git list-tag, git create-tag, etc. Perhaps we could introduce a more explicit notion (in