# Problem with S_IFGITLINK 6 messages from 2011-08-24 to 2011-08-24. Participants: Adam Kłobukowski, Michael J Gruber, Michael Schubert, Nguyen Thai Ngoc Duy. Thread: https://gitlist.dev/t/28205 ## Adam Kłobukowski, 2011-08-24 12:49 Subject: Problem with S_IFGITLINK Message-ID: <4E54F364.7000503@gmail.com> URL: https://gitlist.dev/e/4E54F364.7000503%40gmail.com ``` 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 ``` ## Michael J Gruber, 2011-08-24 14:43 Subject: Re: Problem with S_IFGITLINK Message-ID: <4E550E03.3080104@drmicha.warpmail.net> URL: https://gitlist.dev/e/4E550E03.3080104%40drmicha.warpmail.net In-Reply-To: <4E54F364.7000503@gmail.com> ``` 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 ``` ## Michael Schubert, 2011-08-24 14:57 Subject: Re: Problem with S_IFGITLINK Message-ID: <4E55115D.9000909@elegosoft.com> URL: https://gitlist.dev/e/4E55115D.9000909%40elegosoft.com In-Reply-To: <4E54F364.7000503@gmail.com> ``` 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? ``` ## Adam Kłobukowski, 2011-08-24 15:26 Subject: Re: Problem with S_IFGITLINK Message-ID: <4E55180D.1040207@gmail.com> URL: https://gitlist.dev/e/4E55180D.1040207%40gmail.com In-Reply-To: <4E55115D.9000909@elegosoft.com> ``` 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 ``` ## Adam Kłobukowski, 2011-08-24 15:30 Subject: Re: Problem with S_IFGITLINK Message-ID: <4E551904.303@gmail.com> URL: https://gitlist.dev/e/4E551904.303%40gmail.com In-Reply-To: <4E550E03.3080104@drmicha.warpmail.net> ``` 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 ``` ## Nguyen Thai Ngoc Duy, 2011-08-24 23:15 Subject: Re: Problem with S_IFGITLINK Message-ID: URL: https://gitlist.dev/e/CACsJy8Dgz92YqBnqjvMS9KqtNoNTyrP_0ZqEqTurGnVfTzriUQ%40mail.gmail.com In-Reply-To: <4E551904.303@gmail.com> ``` 2011/8/24 Adam Kłobukowski : > 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 ```