Re: [OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/12/2016 11:02 AM, Jacob Carlborg wrote:

On 2016-11-09 20:07, Nick Sabalausky wrote:


Although I have my doubts it would explain all the issues I've hit upon
with git's CLI. For example: I don't see why annotated tags aren't the
default. Or why non-annotated ones even exist at all. When I made
, I noticed that it'll
*only* work if the version tags are "annotated" tags. Because otherwise
"git describe" doesn't retrieve the tag. Doesn't even matter one bit
*what* the tag's message is, just that it exists. Why? Who knows! It's
git!


If you add the --tags flag to "describe" it will work.



Ok, I see (sorta). But it does work without --tags if it's an annotated 
tag. Clear as mud.


Yea, see, these are the reasons I consider git's cli to be god-awful.

Re: [OT] Re: CTFE Status

[Jacob Carlborg via Digitalmars-d]

On 2016-11-10 06:31, Dicebot wrote:


I think it is related, but is not necessary consequence. My
understanding is that for a long time command line design was given zero
thoughts on its own - it was directly exposing whatever git does
internally with no usability considerations. Which is why it is so
awkward to use unless you really do know internal object model in great
details.


It has the porcelain commands now, compared to the more low level 
pluming commands. I guess at one point only the pluming commands existed.


--
/Jacob Carlborg

Re: [OT] Re: CTFE Status

[Jacob Carlborg via Digitalmars-d]

On 2016-11-09 20:07, Nick Sabalausky wrote:


Although I have my doubts it would explain all the issues I've hit upon
with git's CLI. For example: I don't see why annotated tags aren't the
default. Or why non-annotated ones even exist at all. When I made
, I noticed that it'll
*only* work if the version tags are "annotated" tags. Because otherwise
"git describe" doesn't retrieve the tag. Doesn't even matter one bit
*what* the tag's message is, just that it exists. Why? Who knows! It's git!


If you add the --tags flag to "describe" it will work.

--
/Jacob Carlborg

Re: [OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/10/2016 09:31 AM, Dicebot wrote:

On 11/10/2016 06:07 AM, Nick Sabalausky wrote:

Its things like that. I'd be surprised if that has much to do with git's
nature as a "dumb" DAG tool. It's just the general good-design principle
of "The thing you *want to* or *should* do or *expect* 99% of the time
should be the DEFAULT, not the obscure incantation".


I think it is related, but is not necessary consequence. My
understanding is that for a long time command line design was given zero
thoughts on its own - it was directly exposing whatever git does
internally with no usability considerations. Which is why it is so
awkward to use unless you really do know internal object model in great
details.



Yea, see that's the stuff I mean when I say I dislike git's CLI, and 
would really like to fix with a front-end. A few years back, someone 
here compared it to driving a car by leaning under the hood pulling on 
various wires. I like that comparison. Git always did give off that 
kinda feel to me.


Somebody else pointed out gitless. At a quick glance, it looks like it 
has at least some potential. I'll have to take a closer look. Although I 
suspect I'll find a bunch of "oh, hmm, I'd have done that differently" 
just because...well, I tend to be like that ;)

Re: [OT] Re: CTFE Status

[Dicebot via Digitalmars-d]

On 11/10/2016 06:07 AM, Nick Sabalausky wrote:
> On 11/08/2016 02:11 PM, Antonio Corbi wrote:
>>
>> Maybe this one is useful for you:
>>
>> http://eagain.net/articles/git-for-computer-scientists/
> On 11/08/2016 03:01 PM, H. S. Teoh via Digitalmars-d wrote:
>> Nothing immediately comes to mind, but thanks to Dr. Google, I found
>> this page that's sorta helpful:
>>
>> http://ericsink.com/vcbe/html/directed_acyclic_graphs.html
>>
>> And perhaps these:
>>
>> http://eagain.net/articles/git-for-computer-scientists/
>> http://marklodato.github.io/visual-git-guide/index-en.html
>>
> 
> Ok, so it looks like each node in the DAG is a commit. I'll definitely
> have to read further. Thanks, both.
> 
> Although I have my doubts it would explain all the issues I've hit upon
> with git's CLI. For example: I don't see why annotated tags aren't the
> default. Or why non-annotated ones even exist at all. When I made
> , I noticed that it'll
> *only* work if the version tags are "annotated" tags. Because otherwise
> "git describe" doesn't retrieve the tag. Doesn't even matter one bit
> *what* the tag's message is, just that it exists. Why? Who knows! It's git!

Studying git object model in more details actually explains that.
Annotated tag is a first class git object (like commit), while plain tag
is simply a reference to existing object (like branch). From usability
PoV difference can be negligible but impact on git internals is huge.

The fact that the default is non-annotated tag is still just plain bad
decision though :)

> Its things like that. I'd be surprised if that has much to do with git's
> nature as a "dumb" DAG tool. It's just the general good-design principle
> of "The thing you *want to* or *should* do or *expect* 99% of the time
> should be the DEFAULT, not the obscure incantation".

I think it is related, but is not necessary consequence. My
understanding is that for a long time command line design was given zero
thoughts on its own - it was directly exposing whatever git does
internally with no usability considerations. Which is why it is so
awkward to use unless you really do know internal object model in great
details.



signature.asc
Description: OpenPGP digital signature

Re: [OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/09/2016 11:27 PM, Stefan Koch wrote:

Please cut down on the OT guys.

This thread serves as my development log :)
As well as providing a place for discussion of the new engine.

Though that discussion seems to be very quiet at the moment.


Although the default web-based front-end for this newsgroup suggests 
otherwise, this *is* a tree-based message system. Uninteresting 
sub-trees can simply be ignored without resorting to content policing.

Re: [OT] Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Thursday, 10 November 2016 at 04:22:10 UTC, Nick Sabalausky 
wrote:

On 11/08/2016 11:40 PM, Chris Wright wrote:

On Tue, 08 Nov 2016 11:44:50 -0500, Nick Sabalausky wrote:
I really wish Google would take that to heart. They seem to 
make a habit

of ripping things out *before* having replacements in place.

I think they just simply love deleting code.


I've seen this more internally than externally. The joke was 
that there
are two versions of everything: the deprecated one, and the 
one that

doesn't work yet.



It's REALLY poor project management.


Please cut down on the OT guys.

This thread serves as my development log :)
As well as providing a place for discussion of the new engine.

Though that discussion seems to be very quiet at the moment.

Re: [OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/08/2016 11:40 PM, Chris Wright wrote:

On Tue, 08 Nov 2016 11:44:50 -0500, Nick Sabalausky wrote:

I really wish Google would take that to heart. They seem to make a habit
of ripping things out *before* having replacements in place.

I think they just simply love deleting code.


I've seen this more internally than externally. The joke was that there
are two versions of everything: the deprecated one, and the one that
doesn't work yet.



It's REALLY poor project management.

[OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/08/2016 02:11 PM, Antonio Corbi wrote:
>
> Maybe this one is useful for you:
>
> http://eagain.net/articles/git-for-computer-scientists/
On 11/08/2016 03:01 PM, H. S. Teoh via Digitalmars-d wrote:

Nothing immediately comes to mind, but thanks to Dr. Google, I found
this page that's sorta helpful:

http://ericsink.com/vcbe/html/directed_acyclic_graphs.html

And perhaps these:

http://eagain.net/articles/git-for-computer-scientists/
http://marklodato.github.io/visual-git-guide/index-en.html



Ok, so it looks like each node in the DAG is a commit. I'll definitely 
have to read further. Thanks, both.


Although I have my doubts it would explain all the issues I've hit upon 
with git's CLI. For example: I don't see why annotated tags aren't the 
default. Or why non-annotated ones even exist at all. When I made 
, I noticed that it'll 
*only* work if the version tags are "annotated" tags. Because otherwise 
"git describe" doesn't retrieve the tag. Doesn't even matter one bit 
*what* the tag's message is, just that it exists. Why? Who knows! It's git!


So it means that unlike hg users, who can just make their tags with "hg 
tag v1.2.0" and everything's fine, git users can't just say "git tag 
v1.2.0". In git, making a tag like that will work for SOME use-cases but 
not all. Instead, git users have to use the less-obvious "git tag -a 
v1.2.0 -m '...whatever...'" incantation or else "git describe" won't 
freaking work right, therefore gen-package-version won't be able to 
determine the working copy's current tag name.


So then why do the non-annotated tags even exist? Why not just have 
"annotated" tags with *optional* messages? Why even have the "-a" flag 
for "git tag" at all? Why not have "git tag tagname" make a tag with no 
message, and "git tag tagname -m '...'" to make a tag with a message, 
and ditch the whole "-a" nonsense? Because it wouldn't be stupid enough 
that way? I don't get it.


Its things like that. I'd be surprised if that has much to do with git's 
nature as a "dumb" DAG tool. It's just the general good-design principle 
of "The thing you *want to* or *should* do or *expect* 99% of the time 
should be the DEFAULT, not the obscure incantation".




Or maybe I should write my own article about git being based on a DAG.
:-P



You should! :)

I've given a lot of thought over the years to the concepts of learning 
and teaching. As I see it, the big key to both is taking seemingly 
complex things, finding a model that makes them simple, and then finding 
a way to communicate that model in a way that preserves its inherent 
simplicity.


The big key there is actually having a simple, well-understood mental 
model, and it sounds like you have that on this, so I'd love to read 
anything you'd have to write about it.

Re: [OT] Re: CTFE Status

[Chris Wright via Digitalmars-d]

On Tue, 08 Nov 2016 11:44:50 -0500, Nick Sabalausky wrote:
> I really wish Google would take that to heart. They seem to make a habit
> of ripping things out *before* having replacements in place.
> 
> I think they just simply love deleting code.

I've seen this more internally than externally. The joke was that there 
are two versions of everything: the deprecated one, and the one that 
doesn't work yet.

[OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/05/2016 04:57 PM, Andrei Alexandrescu wrote:


That's good thinking - leave short term to the short term and long term
to the long term. As the Romanian proverb goes: "Don't sell the skin of
the bear before you shoot it." -- Andrei



I really wish Google would take that to heart. They seem to make a habit 
of ripping things out *before* having replacements in place.


I think they just simply love deleting code.