Filemode mismatched type #121

Closed
opened 2014-10-17 12:39:36 -05:00 by ry · 1 comment
ry commented 2014-10-17 12:39:36 -05:00 (Migrated from github.com)

While trying to use @carlosmn's go.gitfs I ran into the following error:

.../github.com/carlosmn/go.gitfs# go build
# github.com/carlosmn/go.gitfs
./gitfs.go:94: invalid case git.FilemodeBlob in switch on v.entry.Filemode (mismatched types git.Filemode and int)
./gitfs.go:96: invalid case git.FilemodeTree in switch on v.entry.Filemode (mismatched types git.Filemode and int)
./gitfs.go:174: cannot use git.FilemodeTree (type git.Filemode) as type int in field value

It seems this problem was introduced in change 9bec36a0b0

The following patch fixes it, but I'm not sure if this is how you want to do it: https://gist.github.com/ry/21587c5d66e20ab0d123

While trying to use @carlosmn's go.gitfs I ran into the following error: ``` .../github.com/carlosmn/go.gitfs# go build # github.com/carlosmn/go.gitfs ./gitfs.go:94: invalid case git.FilemodeBlob in switch on v.entry.Filemode (mismatched types git.Filemode and int) ./gitfs.go:96: invalid case git.FilemodeTree in switch on v.entry.Filemode (mismatched types git.Filemode and int) ./gitfs.go:174: cannot use git.FilemodeTree (type git.Filemode) as type int in field value ``` It seems this problem was introduced in change 9bec36a0b070fc0b4ae444865a95c8e02afe0b69 The following patch fixes it, but I'm not sure if this is how you want to do it: https://gist.github.com/ry/21587c5d66e20ab0d123
carlosmn commented 2014-10-17 14:24:23 -05:00 (Migrated from github.com)

If that commit changes how the Filemode* constants work, then it seems that const blocks don't quite work like I remember (or thought I did). From what I remember, only the first entry in a const block needs the type and the rest would get the same type (which why the code is formatted this way).

But looking into this, it looks like that's only true if we don't assign a value to it. So I guess most or all of our const blocks are wrong and that this only used to work by chance.

I do think we should use the Filemode type in TreeEntry and IndexEntry since it represent those values which Git recognises for files.

If that commit changes how the `Filemode*` constants work, then it seems that const blocks don't quite work like I remember (or thought I did). From what I remember, only the first entry in a const block needs the type and the rest would get the same type (which why the code is formatted this way). But looking into this, it looks like that's only true if we don't assign a value to it. So I guess most or all of our const blocks are wrong and that this only used to work by chance. I do think we should use the `Filemode` type in `TreeEntry` and `IndexEntry` since it represent those values which Git recognises for files.
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: jcarr/git2go#121
No description provided.