Using git revision to program on the pyboard

[cloudformdesign]

So I just got my new pyboard, and the very first thing I wanted to do (after verifying that everything worked of course) was to do revision control on it through git.

Now obviously this has challenges -- the pyboard has very limited memory constraints, so you don't want the ".git" folder to actually exist on it.

I came up with what I think is the best way to develop code on the pyboard, using git revisions, without affecting the memory usage **at all**

I have described the full process below, note that this only works on Linux:

https://github.com/cloudformdesign/note ... upython.md

Basically I mount the library that I am developing to a folder in the git repository. That way it can be revision controlled!

This should be added to the documentation somewhere. I notice that the github wiki is very unorganized and not very helpful, and it seems like the best place to put stuff like this. I think I will organize it and add this to it. Would that be helpful?

[Turbinenreiter]

This should be added to the documentation somewhere. I notice that the github wiki is very unorganized and not very helpful, and it seems like the best place to put stuff like this. I think I will organize it and add this to it. Would that be helpful?

Absolutely yes please!

[dhylands]

The only caution I have is that sometimes the pyboard will decide to erase it's flash memory (I've had this happen - typically when I'm messing around with interrupts and such).

If that happens, then you'll lose all of the your changes since the last commit.

I use git repositories as well, but I tend to run a script which copies the files from my local hard drive to the pyboard (that way, the worst that happens is that I lose the files on the pyboard and not any edits I've made since my last comit.

[Turbinenreiter]

I use git repositories as well, but I tend to run a script which copies the files from my local hard drive to the pyboard

I do that with a Makefile.

[cloudformdesign]

I think we should get all these solutions together and put them in the developer documentation. They are all legit.

[pfalcon]

I notice that the github wiki is very unorganized and not very helpful, and it seems like the best place to put stuff like this. I think I will organize it and add this to it. Would that be helpful?

You know how wiki got into unorganized state? By people wanting to add to it (almost everything) and reorganize it (and then losing interest half-way). So, if you're really sure that it's both related to uPy per se, and really useful, please add it. But regarding reorganization, I suggest being more conservative. For example, revisit this idea in half-year - if you still will be interested in reorganizing it, then it probably really worth doing it. Then, please announce your attentions and plan beforehand, like this: https://github.com/micropython/micropython/issues/1189

Otherwise, just posting the info here on the forum, in your blog, in a separate repository like you do is pretty good way - MicroPython can be used in unlimited number of ways, and if we try to collect them in one place, it invariably will be a mess. Having instead many different places - a vibrant, distributed community - is better choice and how Python lives for example.

[pfalcon]

Now some comments about the solution itself - you may also want to do "man git" and read about GIT_DIR environment variable.

[cloudformdesign]

The number one thing that would help with the wiki would be to create a custom sidebar:

https://help.github.com/articles/creating-a-sidebar/

Then it would be pretty easy to organize everything into categories. Each category could create their own "index" page.

It doesn't look like there is a way to currently access this for me. Can you make this accessible?

setting GITDIR is a way better solution than what I was doing! Great advice!

[pfalcon]

As mentioned above, please open a github ticket if you think that something requires an action. But please keep in mind that we have ~100 open bugs and ~10 open pull requests, so it may take time when it comes to a particular issue (depending on priority) - but that of course only means that is something *needs* to be done, it should be reported as ticket, because otherwise it will be simply lost/forgotten.

Glad that GIT_DIR thing is helpful here!

[dhylands]

You can also use --separate-git-dir when you initialize a git repository. If you accidentally have GIT_DIR set then all git repositories which are initialized will wind up pointing to the directory set using GIT_DIR, so I recommend using the -separate-git-dir option when calling git init.

If you were to use GIT_DIR like this:

Code: Select all

GIT_DIR=/home/somedir git init ...remaining options...

then that would be fine, but I wouldn't store GIT_DIR in your environment.