FWIW, there are a few software packages out there that can help with git and are free to use with open source projects, such as, Gitkraken and Smartgit.
I am not affiliated with any of them, but I have used them both. They are pretty much similar for the most common use cases and both provide a (hopefully) clearer view into the tree /Martijn P.S. This is not to start a flamewar. I apologise for the noise to the git-masters around. > On 3 May 2018, at 07:31, Carsten Schoenert <c.schoen...@t-online.de> wrote: > > Hello Rene, > > Am 02.05.2018 um 14:57 schrieb Rene Pöschl: >> Most of our contributors have no previous experience with git. So we >> really can not expect them to understand anything beyond the github >> workflow. (They are experts in electronics. Not IT) I also don't believe >> we should burden the contributors with too much with this. > > that's unfortunately true for most of contributors or contributions no > matter what kind of software or project and that's a social challenge we > all need to deal with. > >> This is even true for the maintainers. They are selected because they >> understand how to make good symbols and footprints. (Understanding of >> industry standards, limitations of manufacturing processes and the >> limitations of kicad) > > Reading this thread and following from time to time some library issue > on GitHub (only by reading) I see this point in another light. It's up > to the maintainers to get fulfilled the requirements of the project if > he is accepting a pull request. > > I see long lists of pull request on GitHub for the libraries which, and > this list seems even to increase more over the last months which is a > good sign I think, which waiting a review from one of the people which > are allowed to do merge requests. OTOH I see also commit messages as > Reece has pointed out. So for me it looks like there are two problems > which interacting together. > > 1. The maintainers (you mean above I assume), which are needed to make > QS on new or modified parts based on the library standards, are also > "only" volunteering by there free time and this brings long waiting > queues even for simply contributions. This shows a lack of available > human resources with a deep understanding what the given standards are > mean on technical work. > > 2. There are also some library maintaining people needed which know how > to do the technical git work right. And this means mostly you sometimes > have to leave the world of platforms like GitHub, GitLab etc if needed. > If you know what a git merge really is and how a GitHub PR is > technically working under the hood you are able to solve quickly > contributions which otherwise need to wait until someone with a better > technical understanding will provide something useful in the issue > tracker on GitHub. Over the time this can become a serious problem for a > project as people can get quickly frustrated and wont contributing in > future times. > >> For a lot of our casual contributors the current way of contributing is >> already too complex. I have seen a lot of them simply give up as soon as >> git did something they did not expect. This is especially common on the >> symbol lib side as it is likely that the contributor needs to do a >> manual merge because somebody else touched the same lib. > > Also this problem isn't new and is related to git can't handle big > rather complex text files well if two persons have changed such a file. > git was developed for source code not for handling large text based > files. In the end you will come to the conclusion that git isn't the > best tool here but it's also the best we have. > For me than the workflow heavily based direct on plain git isn't the > correct one. > > Thinking in long term where more KiCad users will hopefully come the > current model of library modifications will not work well enough and > better forms of possibilities for contributions need to prepared. The > GitHub platform is only one part to get all things together. > >> These casual contributions can in most cases be summarized as a single >> "added symbol for component x" message. The enduser might not be >> concerned on the detailed mistakes made by the contributor. (And if they >> are, the pull request is always linked to the contribution anyways.) >> As we don't want users to hide their history from us maintainers (we >> want to see what they changed after feedback from us) we really do not >> want them to squash their commits (by using amend). > > This information is quite useless in the end and confusing due blowing > of commits and meta information by this. You need this information only > to decide if further changes are needed before merging or committing. > For me later all these changes are pointless. So please no merge commits > in pull requests and no further modification commits. > > For classical pull requests on mailing list this information is handled > in the patch itself as this text block which will not result in the > final git history. Looks like this > >> -- >> Changes >> v1 -> v2 >> - With drop of patch to remove cflags use of relro flags, needed >> to rework variable assignments for use of spec files (Matt W.) >> --- > > http://patchwork.ozlabs.org/patch/907093/ > > On GitHub you have tracked such information already within the issue > itself. And if you add a "Closes: #1234" into your commit message the > WebUI on GitHub will point you to the associated issue. > > So no, this is all not needed and only time consuming on both sides. > >> So the best solution might be to use the github squash merge feature >> instead of a normal merge and require the maintainer to write a good >> message about what changed. (Of course only if the contributor did not >> already make good commit messages.) > Yes, at least the maintainers need to do more like this or locally on > their machine before doing ping pong with pull or merge request. Don't > get me wrong, it's awesome what the libraries have been evolved over the > last year. It's just a never ending task as you will find always new > advantages to get things improved. > > -- > Regards > Carsten Schoenert > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp