Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve diff for []byte values #272

Closed
rogpeppe opened this issue Aug 12, 2021 · 3 comments · Fixed by #294
Closed

improve diff for []byte values #272

rogpeppe opened this issue Aug 12, 2021 · 3 comments · Fixed by #294

Comments

@rogpeppe
Copy link
Contributor

[]byte is commonly used to encode strings, so it's hard to read the diff when it's phrased in terms of hex bytes rather than strings.

For example, compare the two diff outputs in this example:

  []string{
- 	"hello",
  	"foo",
+ 	"foo",
  	"barbaz",
- 	"blahdieblah",
+ 	"added",
+ 	"here",
+ 	"hrmph",
  }

  [][]uint8{
- 	{0x68, 0x65, 0x6c, 0x6c, 0x6f},
  	{0x66, 0x6f, 0x6f},
+ 	{0x66, 0x6f, 0x6f},
  	{0x62, 0x61, 0x72, 0x62, ...},
+ 	{0x61, 0x64, 0x64, 0x65, 0x64},
+ 	{0x68, 0x65, 0x72, 0x65},
- 	{0x62, 0x6c, 0x61, 0x68, 0x64, 0x69, 0x65, 0x62, 0x6c, 0x61, 0x68},
+ 	{0x68, 0x72, 0x6d, 0x70, 0x68},
  }

I think it would be better to see something like this instead:

  [][]byte{
- 	[]byte("hello"),
  	[]byte("foo"),
+ 	[]byte("foo"),
  	[]byte("barbaz"),
- 	[]byte("blahdieblah"),
+ 	[]byte("added"),
+ 	[]byte("here"),
+ 	[]byte("hrmph"),
  }
@dsnet
Copy link
Collaborator

dsnet commented Aug 12, 2021

The output doesn't have to be valid Go (it already isn't), we could probably simplify it:

  [][]byte{
- 	"hello",
  	"foo",
+ 	"foo",
  	"barbaz",
- 	"blahdieblah",
+ 	"added",
+ 	"here",
+ 	"hrmph",
  }

@rogpeppe
Copy link
Contributor Author

It would be quite nice if that were valid Go.

@rogpeppe
Copy link
Contributor Author

FWIW I just had an idea that the output might be nicer if we used a Transform step to translate []byte to string
(https://play.golang.org/p/nlUN8xivsef), and it is but not by much. I wonder if it might be better if all the diff output looked the same:

  [][]uint8{
- 	{0x68, 0x65, 0x6c, 0x6c, 0x6f},
  	Inverse(bytesTostring, string("foo")),
+ 	{0x66, 0x6f, 0x6f},
  	Inverse(bytesTostring, string("barbaz")),
- 	Inverse(bytesTostring, string("blahdieblah")),
+ 	Inverse(bytesTostring, string("added")),
+ 	{0x68, 0x65, 0x72, 0x65},
+ 	{0x68, 0x72, 0x6d, 0x70, 0x68},
  }

dsnet added a commit that referenced this issue Apr 24, 2022
If a slice of bytes is mostly text, format them as text
instead of as []byte literal with hexadecimal digits.

Avoid always printing the type. This is technically invalid Go code,
but is unnecessary in many cases since the type is inferred
from the parent concrete type.

Fixes #272
dsnet added a commit that referenced this issue Apr 24, 2022
If a slice of bytes is mostly text, format them as text
instead of as []byte literal with hexadecimal digits.

Avoid always printing the type. This is technically invalid Go code,
but is unnecessary in many cases since the type is inferred
from the parent concrete type.

Fixes #272
dsnet added a commit that referenced this issue Apr 24, 2022
If a slice of bytes is mostly text, format them as text
instead of as []byte literal with hexadecimal digits.

Avoid always printing the type. This is technically invalid Go code,
but is unnecessary in many cases since the type is inferred
from the parent concrete type.

Fixes #272
dsnet added a commit that referenced this issue Apr 24, 2022
If a slice of bytes is mostly text, format them as text
instead of as []byte literal with hexadecimal digits.

Avoid always printing the type. This is technically invalid Go code,
but is unnecessary in many cases since the type is inferred
from the parent concrete type.

Fixes #272
dsnet added a commit that referenced this issue Apr 25, 2022
If a slice of bytes is mostly text, format them as text
instead of as []byte literal with hexadecimal digits.

Avoid always printing the type. This is technically invalid Go code,
but is unnecessary in many cases since the type is inferred
from the parent concrete type.

Fixes #272
dsnet added a commit that referenced this issue Apr 25, 2022
If a slice of bytes is mostly text, format them as text
instead of as []byte literal with hexadecimal digits.

Avoid always printing the type. This is technically invalid Go code,
but is unnecessary in many cases since the type is inferred
from the parent concrete type.

Fixes #272
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants