VERAULT
Veteran Member
Well thankyou to everyone who gave answers, insight, and posted thier take and experiences. I do feel I have learned something from all of this.
I’m adding JED files to my GitHub repo!I think most of us have. I know I did too.
I feel the same way about the revision I did to the Brain Board (By Mike Willegal); it's highly unlikely I would have documented it properly and published it properly to Github like I did if I were not selling a few of them or offering kits. GPL also brings obligations of course, and I'm more than happy to keep things in the open under GPL, but for me that is something to abide by more than the primary reason for publishing. The primary reasons for publishing a project like this are that I've sent some out into the world, and that I want anyone to be able to easily make one without any physical supplies from me.If I wasn't selling the boards, I don't think I would have invested the time to fully document them.
Often in github, even deleted files are in the history of branches, it depends. When you make a 'commit' (even deleting files), you're supposed to enter text / a message explaining the change.I have a question for folks using Github. If you have content, and you delete that content. There is an annotation that says something (lets say a folder and its contents) were deleted and when. IS there a log area where reasons why changes were made? Shouldn't there be? I am on one repository for a board. I had a couple test boards printed. The directories were up a couple months. I figured thats a bit of time to see if bugs need to be ironed out. I sent away for a couple boards. I go back on github. And the folder with that boards gerbers and files are removed, stating deleted but no reason given.
How does one keep track of long term projects if they are incapable of keeping records of changes?
So sure we can all speculate. There was a problem with the circuit. Something was wrong. Again, this is just speculation. Why wouldnt there be notation explaining WHY IT WAS REMOVED!
Im chocking it up to how society is becoming daily more incapable of communication because of smartphones and Antisocial media. Everything is indirect. Nothing is documented.
I have the files. I downloaded the repository before making a purchase. But now I am concerned for this build; why was it pulled? I am just wondering if there is a change log or something I am unfamiliar with.Often in github, even deleted files are in the history of branches, it depends. When you make a 'commit' (even deleting files), you're supposed to enter text / a message explaining the change.
I usually make sure to do a 'git pull' of the project to a local directory whenever I start working with it, and can choose to sync or not sync new changes by the project owner from there out.
Yes; it's the log message for the commit that deleted the files. You can find it via the git log command or, probably much more easily, through one of the various GUI programs that lets you browse the log.I have a question for folks using Github. If you have content, and you delete that content. There is an annotation that says something (lets say a folder and its contents) were deleted and when. IS there a log area where reasons why changes were made?
What is a good tool for preparing the .MD files?Cut them some slack. They're probably using vi. That's why so few of them are masochistic enough to use it to write complete and detailed documentation!
Including stuff at this level in documentation for a particular repository would be kind of like including tutorials on ordering PCBs and soldering in every hardware repository. It's not trivial knowledge, no, but it's also just not practical to go from first principles of design and build for a particular work domain in every single project in that domain. Not least because such a verbose flood of documentation would hide the important information that reasonably experienced developers need.Again I tried this on windows.. Got nowhere. I loaded up a p4 laptop with lubuntu and tried it.
They say linux already has all the tools you need to do it.. Well thats a lie.. your distro MAY have the libraries but most likely you will have to add them. I had to add GIT. ...
So I Cloned the repository.. Ok whats the exact command
If your project has dependencies beyond stdlib and you don't state outright what they are and which versions in a human-readable form, you're a bad person and you should feel bad. Simple as that.
Well, I strongly disagree with commodorejohn's comment here, and the general idea that things shouldn't go up on GitHub (or similar places) without good documentation, instructions and so on.Edit. And I cant believe I need to say this but of course I am grateful to the whole open source community and people who put projects up for everyone to share in. My problem is not with them but the seemingly systemic lack of documention, instructions, and communication. Thats what I am getting at.
Your favourite editor.What is a good tool for preparing the .MD files?
7400-Series Overview
====================
Parts
-----
#### Notes
- See also Wikipedia, [List of 7400-series integrated circuits][wp-7400list].
- Part number is given without `74` prefix and logic family.
- Pin counts are for DIP parts.
- Inputs `A,B,C,…`, Outputs `Y0,Y1,…`, Enable `G1,G̅2̅,/G2…` or `CS1,C̅S̅2̅,/CS2`
#### Boolean
Inverter/buffer:
* __'04__ (14): Hex inverter gate [SN74LS04]
- Pins: `1A 1Y 2A 2Y 3A 3Y GND 4Y 4A 5Y 5A 6Y 6A Vcc`
- Open collector: __'05__; __'06__ 30V/40mA; __'16__ 15V/40mA.
- Non-inverting: '06 → __'07__; '16 → __'17__.
- Schmitt-trigger: __'14__ [SN74LS14], __'19__ [SN74LS19]
NAND:
* __'00__ (14): Quad 2-input NAND gate [SN74LS00]
- Pins: `1A 1B 1Y 2A 2B 2Y GND ‥ 3Y 3B 3A 4Y 4B 4A Vcc`
- Open collector verssions: __'03__ Iol=16 mA; __'38__ Iol=48 mA
* __'01, '39__ (14) Quad 2-input NAND gate, open collector
- Pins: `1Y 1A 1B 2Y 2A 2B GND ‥ 3A 3B 3Y 4A 4B 4Y Vcc`
- Iol: '01=22 mA, '39=60-80 mA
.... (stuff removed) ....
#### Multivibrators
_Astable_ continually switches between two states,
_monostable_ settles in one state when not triggered,
_bistable_ settles in either state.
* __'122__ (16): Retriggerable monostable multivibrator [SN74LS122]
- Like '123 with internal resistor available, no separate clear/timing inputs.
- Pins: `A1 A2 B1 B2 C̅L̅R̅ Q̅ GND ‥ Q Rint NC Cext NC Rext/Cext Vcc`
- Trigger input A is active-low, B active-high and avoids jitter.
- Retrigger after 0.22 Cext (pF) extends pulse. Clear terminates pulse.
- Timing cap between Cext and Rext/Cext (positive).
- Connect Rint to Vcc to use internal timing resistor.
* __'123, '130__ (16): Dual retriggerable monostable multivibrator [SN74LS122]
.... (stuff removed) ....
ASCII Pinout Diagrams
---------------------
Blu
┌──∪──┐ '244
Blu → 1G̅ │1 20│ Vcc Red
Gre -> 1A1 │2 19│ 2G̅ → Blu
Yel <- 2Y4 │3 18│ 1Y1 -> Yel
Gre -> 1A2 │4 17│ 2A4 <- Gre
Yel <- 2Y3 │5 16│ 1Y2 -> Yel
Gre -> 1A3 │6 15│ 2A3 <- Gre
Yel <- 2Y2 │7 14│ 1Y3 -> Yel
Gre -> 1A4 │8 13│ 2A2 <- Gre
Yel <- 2Y1 │9 12│ 1Y4 -> Yel
Blk Gnd │10 11│ 2A1 <- Gre
└─────┘
Blk Gnd
Red +5
Blu enable
Gre input
Yel output
<!-------------------------------------------------------------------->
[ALUs]: gate.md#alus
[open collector]: https://en.wikipedia.org/wiki/Open_collector
[wp-7400list]: https://en.wikipedia.org/wiki/List_of_7400-series_integrated_circuits
[SN74LS00]: http://www.ti.com/lit/gpn/sn74ls00
[SN74LS02]: http://www.ti.com/lit/gpn/sn74ls02
[SN74LS04]: http://www.ti.com/lit/gpn/sn74ls04
[SN74LS08]: http://www.ti.com/lit/gpn/sn74ls08
[SN74LS14]: http://www.ti.com/lit/gpn/sn74ls14
.... (stuff removed) ....
Sorry, but I thought that in this post I covered exactly your question about changes and change logs, and I did not see any answers to your questions/comments, "IS there a log area where reasons why changes were made?", "I am just wondering if there is a change log or something I am unfamiliar with," and "How does one keep track of long term projects if they are incapable of keeping records of changes?" I got the impression that you weren't clear on what exactly Git commits are and how the commit logs work, since to an experienced Git user the place to go look to answer these questions is fairly obvious.I appreciate the Input @cjs , but we covered all of that last year. Not trying to rehash old arguments but pose a brand new question. I really was only wondering about changes and change-logs in particular.
Well, it's certainly up to you whether you want to do the work that "incorporates it meaningfully" or not; there's no reason you should be expected to do a bunch of extra work that you don't feel up to doing.I wrote a completely revised (70% changes) firmware for a github project. I can't figure out how to incorporate it meaningfully. So I haven't.