> From: tomgra...@gmail.com
> 
> Wow!!! Its going to take me a seriously long time to get over the sheer 
> brilliance (not to mention speed) of that diagnosis - really impressive! I 
> have to say I am so glad you helped me with this - I can safely say I would 
> never in a million years have reached that conclusion without your 
> assistance.

One thing I was trying to make clear is that my analysis was largely
*mechanical*, using known tools to extract the information that would
direct me to the correct part of the code.  It's a collection of
well-known tricks, and since I described them clearly, you can learn
them immediately.

> A bit disappointing to learn that git's internals are not well documented - 
> surprising for an open source project - and I thought everyone was moving 
> over to it on account of it being well put together.

Given that who wrote this code is publicly visible, I would have
expected the authors to have written code they could be proud of.  I
wouldn't want a potential employer to see that I'd written reams of
undocumented code for an important project.

> So if this is a bug, should it be reported?

I've reported it to the main Git mailing list on vger.

> Also, I guess manually changing 
> the source code and inserting the '=' is probably not the correct way to 
> proceed. Would the best thing then be to 'trick' the system into thinking 
> fd 0 was open/not available so we can be sure open returns a value >0 ? Any 
> thoughts how best to achieve this?

If you can arrange for "</dev/null" to be inserted into the command
line that is executed, then fd 0 will be open, and the problem should
be avoided.

Dale

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to