[beports] Re: [RFC] Git 1.6.0-rc2 branch

Hi,

Thanks for your rapid comments.

Am 08.08.2008 um 17:06 schrieb Ingo Weinhold:
On 2008-08-08 at 16:15:16 [+0200], Andreas Färber <andreas.faerber@xxxxxx > 
wrote:


After a number of 1.5.x Git releases have passed without progress and
with the 1.6.0 release approaching, I have set up a Git branch we can
share for getting Haiku support in. It is a new branch based on the
kernel.org master (1.6.0-rc2), and I have applied only the changes
that are still necessary:

* stat::st_blocks (Andreas)


Rather use:

+                               (*loose_size) += (st.st_size + 511) / 512;


Good catch!


If this mean FS blocks, 512 is wrong for BFS in any case.
st_blocks is supposed to be in units of 512 bytes, not the actual block size, according to some Internet source I found at the time. There may be details in the original Port Log: 
http://ports.haiku-files.org/wiki/dev-util/git/1.5.5/1


I haven't look at
the context in which this is used at all. I suppose it's only for
statistics and not really important.


I believe so, too. It says loose_size fwiw.

I can pull, commit and push with it. :)
git-svn I haven't been successful with, it needed SVN Perl modules that it couldn't locate. Will revisit that when I have Subversion 1.5.x. 




* -lnetwork, -lbsd (Andreas)


It's "Haiku" only, not "Haiku OS".


Fixed. Blame the website! ;-)




* ls -1 (Andreas, Niels)
Apparently Haiku's "read" is broken. This should be fixed in Haiku, not in 
an upstream patch.
Okay, I've spawned a branch haiku-upstream and reverted the commit there. 
We still need this workaround for the haiku branch though.




* ln -s (Niels)
In one occurrence missing support for hard links is already considered: 

-               ln -f "$$bindir/git$X" "$$execdir/git$X" || \
+               $(LN) -f "$$bindir/git$X" "$$execdir/git$X" || \
                cp "$$bindir/git$X" "$$execdir/git$X"; \
I.e. it simply uses "cp" when "ln" fails. I would rather change the other 
two occurrences in the same way.
I see what you mean. If we ever get, say, ZFS, ln -s would not be needed anyway.
The "problem" with this fallback approach is the console full of errors when doing it on BFS, since stderr is not suppressed for ln. Not sure if 2>/dev/null could go upstream. I've applied it to the haiku branch only for now. 

I've pushed the fixes, an updated upstream patch is attached.

Signed-off-by: Andreas Faerber <andreas.faerber@xxxxxx>

Andreas

Other related posts: