search

attic-labs / noms

The versioned, forkable, syncable database
Apache License 2.0
7.44k stars 266 forks source link

Should noms-show refs render as #abc not abc? #2321

Open kalman opened 8 years ago

kalman commented 8 years ago

I noticed that if a value contains a ref then it renders as abc..., but should it render as #abc...? We seem to be standardising[*] on including the # in several places, this is one that makes sense to me.

Of course this doesn't only affect noms-show, but anywhere that uses the human readable serialization.

[*] an example of a place where it would just be distracting: commit hash in noms-log

@arv @aboodman

kalman commented 8 years ago

One might argue that these are refs not hashes so the inclusion of # isn't right. Either way it would be good to do something other than just the stringification of the ref's target hash.

aboodman commented 8 years ago

What is the value in doing it?

On Tue, Aug 9, 2016 at 10:27 AM, Ben Kalman notifications@github.com wrote:

One might argue that these are refs not hashes so the inclusion of # isn't right. Either way it would be good to do something other than just the stringification of the ref's target hash.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/attic-labs/noms/issues/2321#issuecomment-238627166, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE6BE7Lg8fjEF__FzBIxeOWRo8qy4A8ks5qeLibgaJpZM4JgUDl .

kalman commented 8 years ago

Consistency?

aboodman commented 8 years ago

It doesn't strike me as inconsistent the way it is. The * notation is when you use a hash as part of a path. Alone, the hash doesn't need that. That's just the way I see it though.

On Tue, Aug 9, 2016 at 11:23 AM, Ben Kalman notifications@github.com wrote:

Consistnecy?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/attic-labs/noms/issues/2321#issuecomment-238644314, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE6BCMURPT0N3r-OQQhBLyAuTvWBir1ks5qeMWRgaJpZM4JgUDl .

kalman commented 8 years ago

I've come across a case when the preceding hash would be nice. When writing perf tests, I record the environment as a ref, and alongside it the git hash. It looks like:

> noms show
...
    environment: kg7vkvcea4m0cvmc4a0aj3lbhnp2jntc,
    nomsVersion: "b425af6658a992915b0c72277df1cd850f8fd93c",
    testdataVersion: "a6289aa1e8757f19c98629c10e89922cc549940f",
...

It's hard to tell those apart at a glance. More generally, the difference between a string which looks like a hash, and a hash itself, is hard to tell apart. IMO it would look better as

> noms show
...
    environment: #kg7vkvcea4m0cvmc4a0aj3lbhnp2jntc,
    nomsVersion: "b425af6658a992915b0c72277df1cd850f8fd93c",
    testdataVersion: "a6289aa1e8757f19c98629c10e89922cc549940f",
...
aboodman commented 8 years ago

still not convinced, sorry :)

On Tue, Aug 16, 2016 at 3:32 PM, Ben Kalman notifications@github.com wrote:

I've come across a case when the preceding hash would be nice. When writing perf tests, I record the environment as a ref, and alongside it the git hash. It looks like:

noms show ... environment: kg7vkvcea4m0cvmc4a0aj3lbhnp2jntc, nomsVersion: "b425af6658a992915b0c72277df1cd850f8fd93c", testdataVersion: "a6289aa1e8757f19c98629c10e89922cc549940f", ...

It's hard to tell those apart at a glance. More generally, the difference between a string which looks like a hash, and a hash itself, is hard to tell apart. IMO it would look better as

noms show ... environment: #kg7vkvcea4m0cvmc4a0aj3lbhnp2jntc, nomsVersion: "b425af6658a992915b0c72277df1cd850f8fd93c", testdataVersion: "a6289aa1e8757f19c98629c10e89922cc549940f", ...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/attic-labs/noms/issues/2321#issuecomment-240260208, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE6BP6bCYTDZIiQhVqcMa3b0aOuqwcdks5qgjp0gaJpZM4JgUDl .