Problem with S_IFGITLINK

Problem with S_IFGITLINK

[Adam Kłobukowski]

Hello

I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT 
anyone? :)) and I encountered problem with S_IFGITLINK.

Unfortunately, on my system S_IFGITLINK = S_IFLNK, and it breaks build 
in entry.c write_entry.

Should I report a bug? (where?, I could not find any reference to 
bugtracker on git pages)

Can I fix it somehow? Can I change value of S_IFGITLINK to something else?

AdamK

Re: Problem with S_IFGITLINK

[Michael J Gruber]

Adam Kłobukowski venit, vidit, dixit 24.08.2011 14:49:
> Hello
> 
> I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT 
> anyone? :)) and I encountered problem with S_IFGITLINK.
> 
> Unfortunately, on my system S_IFGITLINK = S_IFLNK, and it breaks build 
> in entry.c write_entry.
> 
> Should I report a bug? (where?, I could not find any reference to 
> bugtracker on git pages)

Yes. Here.

A short log of the build break would be nice.

> Can I fix it somehow? Can I change value of S_IFGITLINK to something else?

From git's cache.h:

/*
 * A "directory link" is a link to another git directory.
 *
 * The value 0160000 is not normally a valid mode, and
 * also just happens to be S_IFDIR + S_IFLNK
 *
 * NOTE! We *really* shouldn't depend on the S_IFxxx macros
 * always having the same values everywhere. We should use
 * our internal git values for these things, and then we can
 * translate that to the OS-specific value. It just so
 * happens that everybody shares the same bit representation
 * in the UNIX world (and apparently wider too..)
 */

Time to implement that translation :|

Michael

Re: Problem with S_IFGITLINK

[Michael Schubert]

On 08/24/2011 02:49 PM, Adam Kłobukowski wrote:
> I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT
> anyone? :)) [...]

Out of interest: just for fun?

Re: Problem with S_IFGITLINK

[Adam Kłobukowski]

W dniu 24.08.2011 16:57, Michael Schubert pisze:
> On 08/24/2011 02:49 PM, Adam Kłobukowski wrote:
>> I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT
>> anyone? :)) [...]
>
> Out of interest: just for fun?

Hobby. There are still active developers and users, but they're 'ugly 
and stupid' ;) (I mean: using CVS) for FreeMiNT kernel development. I 
would like to propose to switch ti GIT, but I need to be able to compile 
native binary first.

AdamK

Re: Problem with S_IFGITLINK

[Adam Kłobukowski]

W dniu 24.08.2011 16:43, Michael J Gruber pisze:
> Adam Kłobukowski venit, vidit, dixit 24.08.2011 14:49:
>> Hello
>>
>> I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT
>> anyone? :)) and I encountered problem with S_IFGITLINK.
>>
>> Unfortunately, on my system S_IFGITLINK = S_IFLNK, and it breaks build
>> in entry.c write_entry.
>>
>> Should I report a bug? (where?, I could not find any reference to
>> bugtracker on git pages)
>
> Yes. Here.
>
> A short log of the build break would be nice.
>
>> Can I fix it somehow? Can I change value of S_IFGITLINK to something else?
>
>  From git's cache.h:
>
> /*
>   * A "directory link" is a link to another git directory.
>   *
>   * The value 0160000 is not normally a valid mode, and
>   * also just happens to be S_IFDIR + S_IFLNK
>   *
>   * NOTE! We *really* shouldn't depend on the S_IFxxx macros
>   * always having the same values everywhere. We should use
>   * our internal git values for these things, and then we can
>   * translate that to the OS-specific value. It just so
>   * happens that everybody shares the same bit representation
>   * in the UNIX world (and apparently wider too..)
>   */
>
> Time to implement that translation :|

I may try to implement it, but I my knowledge of Git internals is equal 
to zero. If someone can point me what has to be done - I'll be gratefull.

AdamK

Re: Problem with S_IFGITLINK

[Nguyen Thai Ngoc Duy]

2011/8/24 Adam Kłobukowski <adamklobukowski@gmail.com>:
> I may try to implement it, but I my knowledge of Git internals is equal to
> zero. If someone can point me what has to be done - I'll be gratefull.

Git stores mode in the index (struct cache_entry#ce_mode, cache.h) and
in tree objects (see tree-walk.c). Basically you define a new set of
S_IS* and S_IF* macros and use them instead of standard ones.
Translations from struct stat#st_mode will be needed, I think
ce_mode_from_stat() does that job.

So:
 - read index and checkout: entry.c
 - read and update index: read-cache.c
 - read tree objects: tree-walk.c
 - write tree objects: cache-tree.c
 - anywhere that checks struct cache_entry#ce_mode needs to convert to
use the new defines

Another way, less changes, is redefine S_IS* and S_IF* and ignore
system values. Then make wrapper for stat() and lstat(), convert
system values to git values. You can put these wrappers in compat
directory. See git-compat-util.h, mingw port for example already
redefine these functions for Windows platform.
-- 
Duy