Page MenuHomePhabricator

git f*ck up? can't find revision (has 2 hashes) and file is unchanged on server
Closed, ResolvedPublic

Description

hi cedric,

while i was bored i tried understanding what lead to the accidental cloexec fd 0 in T5606. you don't need to read on if commit rEFL17507bab is not supposed to be live (was just for testing or so). but if it is, it's somewhere in git, but the file is unchanged on the server.

i wanted to look up locally but couldn't find your changes in src/lib/ecore/efl_io_closer_fd.c. moreover git on commit says unknown revision or path not in the working tree. before you try to tell me to pull, i'm up to date today. moreover, your commit is not listed on the server, neither in master nor in the branch feater/eo_theme.

locally it's commit 17507bab43e18b3a29fb045302de6c4f88fef594. in phab it's also rEFL17507bab43e18b3a29fb045302de6c4f88fef594

is there some f*ck up or is this intentional?

cedric triaged this task as Normal priority.Dec 20 2018, 4:57 PM
cedric added subscribers: stefan_schmidt, beber.

This seems like a cache issue on git.e.org. I have no clue on how to fix that. @beber , @stefan_schmidt ? Anyone ?

ProhtMeyhet added a comment.EditedThu, Jan 10, 7:19 PM

oh, forgot: it's been over one whole year since i opened this, so "cache issue" sounds unlikely @cedric

ummm errrr? i don't know. cgit might have caches like @cedric says and these somehow got stale or unwritable or... ?

ummm errrr? i don't know. cgit might have caches like @cedric says and these somehow got stale or unwritable or... ?

yes, but this makes this install of git quite unreliable. especially since this is about a possible security issue.

what do we do?

it's just the cgit gui web - git has all the right state/content. that's what matters at the end of the day.

it's just the cgit gui web - git has all the right state/content. that's what matters at the end of the day.

NO IT DOES NOT.

My local git, after git pull still reads, as does the file on the server

typedef struct _Efl_Io_Closer_Fd_Data
{
   int fd;
   Eina_Bool close_on_exec;
   Eina_Bool close_on_destructor;
} Efl_Io_Closer_Fd_Data;

where it should read

typedef struct _Efl_Io_Closer_Fd_Data
{
   int fd;

   Eina_Bool close_on_exec;
   Eina_Bool close_on_destructor;
   Eina_Bool initialized;
} Efl_Io_Closer_Fd_Data;

among other lines changed according to @cedric commit rEFL17507bab43e18b3a29fb045302de6c4f88fef594

Hello, you can check the history of that file, there is another commit following the one you linked (37d6bc03fda9a0ef3e5ffe27d2f687fa3dfa28e8) which removes exactly the lines you are referring to :)

Considering this commit the file looks right again, (I think) ?

what @bu5hm4n said - i looked at the history of the file - the commit went in - changes there then at a later point it was changed again by other commits. so in GIT it seemed all fine to me.

what @bu5hm4n said - i looked at the history of the file - the commit went in - changes there then at a later point it was changed again by other commits. so in GIT it seemed all fine to me.

please, i am not trying to make you look bad or anything.

i just downloaded enlightenment and there is no difference inside this DOWNLOADED code.

i did not use git, but gedit. gedit shows me the following: @raster @bu5hm4n

typedef struct _Efl_Io_Closer_Fd_Data
{
   int fd;

   Eina_Bool close_on_exec;
   Eina_Bool close_on_invalidate;
} Efl_Io_Closer_Fd_Data;

to be more specific...

17507bab43e18b3a29fb045302de6c4f88fef594 went in

37d6bc03fda9a0ef3e5ffe27d2f687fa3dfa28e8 undid the work int he previous patch (it called super class in constructor
instead)

33fd77e9e43b0fa29cb484b72d910bdf0ecccbc8 later made some other changes.

raster added a comment.EditedWed, Jan 16, 12:48 AM
git log src/lib/ecore/efl_io_closer_fd.c

to see full changes

git log --color -U src/lib/ecore/efl_io_closer_fd.c

and you'll see what we both mean.

ProhtMeyhet closed this task as Resolved.Wed, Jan 16, 12:56 AM
git log src/lib/ecore/efl_io_closer_fd.c

to see full changes

git log --color -U src/lib/ecore/efl_io_closer_fd.c

and you'll see what we both mean.

yes, yes.

i am sorry.

the only thing i can say, for you to forgive me, is that even @cedric didn't remember.

for the unknown revision or path not in the working tree. <- did @cedric first commit and then amend then submit? if so, you are forgiven.