@Hans

I absolutely agree! So you're seeing delays if you're simply adding single files at a time in the root directory? E.g. If you do

sgit add foo_0.c
sgit add foo_1.c
sgit add foo_2.c
................
sgit add foo_n.c

on an empty repo are all of them slow or does the delay increase, the more files you add? Just working out what I need to replicate to see it.

As for a debugger, I absolutely agree again! I need to take another look at db101, but anything like gdb would be a huge boon for development

cheers

billy

@billyfish

Just tested with a much smaller project, and it's proportional to the repository size. No idea what it's doing.

NOTE: I'm using a A1222/Tabor system, with system components that aren't optimized for the P1022 CPU**. So reading from disk is currently on the slow side. Hence I notice it more.

Nevertheless, adding a single file shouldn't require reading megabytes of data from disk...

Hans

** This is the CPU with the non-standard FPU.

@billyfish


I don't know the inner workings of sgit, so i may be completely off tzhe track here, but would it be possible to make sgit take use of ExtMem?

Especially
sgit fetch
eats away lots of memory which could(?) be moved to ExtMem.

Again, maybe sgit doesn't do anything and the memory is handled by the OS, i don't know, just something i stubled over today (updating a big project after some month in hiatus).

@billyfish

The error I get is an assertation failed. Here it is, showing context:

[Work:]> t:

[RAM Disk:T]> makedir test

[RAM Disk:T]> cd test

[RAM Disk:T/test]> sgit init
Initialized empty Git repository in /RAM Disk/T/test/.git/

[RAM Disk:T/test]> touch foo

[RAM Disk:T/test]> sgit add foo

[RAM Disk:T/test]> sgit status
# On an unnamed branch
assertion "ref" failed: file "/var/lib/jenkins/workspace/sgit.amiga/libgit2/src/refs.c", line 367

[RAM Disk:T/test]> sgit version
sgit version 0.639
using libgit2 0.26.3 and OpenSSL 1.0.1u 22 Sep 2016

@billyfish

I used sgit for the first time today. I'm a frequent user of git so I'm very interested in any updates you can achieve.

alias git=sgit

;)

Ah, I got it all working now - seems like the assertation error was only thrown on an empty repo with no commits. I've now got it all hooked up and working with GitHub nicely and have blogged about it (including a link to this thread!) http://www.markround.com/blog/2019/08 ... -development-environment/

I aim to try and get a cross-compiling environment going so I can help contribute to your efforts, but in the meantime please do let me know if/when you have a binary available for testing. Many thanks again for all your work on this, it's very much appreciated.

@mdr

Awesome, I managed to confirm your issue yesterday as I'm finally getting some time back on sgit again, hurrah! I'll keeo you posted chaps, my aim is to have a version with the move and commit updates finished in the next week or two. I'll make this available and then start on the issues and updates that you guys have mentioned, keep them coming

@billyfish

Did someone mention "bisect" yet?

...uh, yes, "someone" did

@billyfish

It would also be nice if sgit tag accepted the -a and -m parameters.

Hans

I would like to add a +1 to Hans last comment. The tag manipulation is necessary.

@billyfish
Keep up the good work. Looking forward to testing one of your builds.

@billyfish

I've been using sgit on my X1000 now, and I can confirm that the slowdowns with "add" and "status" are a problem even on fast machines. The bigger the repository, the longer you have to wait.

I have a project with over 300 MB of data,** including the build directory which sgit should ignore, and sgit add . can take over a minute.

Does sgit do a full diff of everything all the time, including files that haven't been modified?

Hans


** NOTE: The size of the actual source is much smaller.

@billyfish
Any progress? Sgit add is now unbearably slow for me. I'm considering using my FTP server to either transfer source files back to the PC to commit, or to start cross-compiling binaries (in which case I need to build a GCC 8 cross-compiler first).

I'd prefer to use native tools, but sgit's issues are costing a lot of time (reported another one last night).

Hans

There is some strange issue with sgit diff: on some projects, sgit status shows a file in modified states but sgit diff doesn't show anything. I don't know what exactly triggers it, but it has happened with more than one project now. Removing .gitignore doesn't help.

@capehill
This might happen in case the file creation or update date changes, or permissions. sgit diff shows only changes in the code.

@walkero

Unless "sgit status" works differently from "git status" on other OSes it shouldn't show a file as modified if only its date stamp has changed.

@walkero

It was a content change in code file. I still cannot make sgit diff show any changes on the original repo for that file, but if I reclone my project and modify the file, it works.

It's actually possible to reproduce my issue by going back the commit before problematic one:

Quote:

sgit diff does nothing here.

@Capehill

"git diff" will only show file changes that haven't been staged using "git add". This is how regular git works on other platforms.

To unstage the file profiler.c you need to do:
git reset HEAD profiler.c

@salass00

Yes, you are correct and in fact with "reset --mixed" my example works OK but I'm actually convinced sgit has occasionally this problem with diff. It happened today again with other file that was modified but not added for commit.

My workflow is always sgit diff before sgit add.

Strange.

Any progress with improving sgit?

Last week I encountered the "broken pipe" failure again when pushing a commit to the remote server. I was able to work around it by checking out the code again, reapplying the changes and then doing a push. However, having to do that really slows you down.

Hans

@Hans

Sorry for the loooooong delay about this. My plan to update sgit hit a couple of major snags. Apart from my spare time getting squeezed by my research work taking up way more time than I anticipated, I got my head around the way that simplegit was working and then realised the major issue.

So simplegit is a wrapper that calls libgit2 (https://libgit2.org/) for its actual git functionality. Now simplegit uses a fork of libgit2 (https://github.com/sba1/libgit2/tree/a ... e14a6487a3de17174ef9ac831) so to get the latest git functionality requires this being brought up to data as it is currently 1729 commits behond the main libgit repo. So consequently that is a lot of upstream changes to pull in and I was bracing myself as to how to go about this. If it can be brought up to date, then I would definitely make a pull request to get the amiga-specfic changes into the main tree so we don't have to go through this again.

If you want the latest snapshot of how far I'd progressed with sgit, its available at

https://drive.google.com/open?id=1wogEmqm4cyytWmjU6eNPenTyQiyQ-i1f

It's quite a while so my memory is a bit hazy, from what I remember the commit behaviour has been update to be like the standard git behaviour so that

sgit commit -a -m "..."

where the -a flag automatically stages files that have been modified and deleted, but new files you have not told Git about are not affected.

I will try and take another look at this to see what further updates I can do. However the big win will be to get the libgit2 part back up to date.

cheers

billy