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 git-n
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 of Git they have,
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 value enables the c
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 th
(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 bad idea that's best
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 peo
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 entir
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 ca
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. But could we go with
On Wed, Aug 26, 2015 at 4:02 PM, Jacob Keller wrote:
> On Wed, Aug 26, 2015 at 3:52 PM, Philip Oakley wrote:
>> From: "Jacob Keller"
>>>
>>> On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano
>>> wrote:
But notice that I said "if you really want to". I personally think
it is a roa
On Wed, Aug 26, 2015 at 3:52 PM, Philip Oakley wrote:
> From: "Jacob Keller"
>>
>> On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano
>> 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
From: "Jacob Keller"
On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano
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 o
Jacob Keller writes:
> On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano 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 wit
On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano 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 commands and try
Hilco Wijbenga writes:
> On 25 August 2015 at 16:43, 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.
>
> Perhaps we could introduce a more
On Tue, Aug 25, 2015 at 11:28 PM, Andreas Schwab wrote:
> Jacob Keller 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 wouldn't be consistent then. Normally
Jacob Keller 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 214B 8276 4ED5
"An
On Tue, Aug 25, 2015 at 4:43 PM, Junio C Hamano wrote:
> Stefan Beller 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 a
On 25 August 2015 at 16:43, 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.
Perhaps we could introduce a more explicit notion (in .git/config)
Stefan Beller 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 maybe ?
On Tue, Aug 25, 2015 at 3:06 PM, Stefan Beller wrote:
> On Tue, Aug 25, 2015 at 2:49 PM, Jacob Keller wrote:
>> On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano wrote:
>>> On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys
>>> wrote:
Even though I have worked with Git since 2009, I st
On Tue, Aug 25, 2015 at 2:49 PM, Jacob Keller wrote:
> On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano wrote:
>> On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys wrote:
>>>
>>> Even though I have worked with Git since 2009, I still have to
>>> reference the help to remind me of what parameter
On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano wrote:
> On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys 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
On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys 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 the next ma
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 b
25 matches
Mail list logo
