>> one need not be forced to use github/gitlab workflows of pull/merge >> requests. One can instead work with named branches. > > Well, for FriCAS traditional branches are of limited use. My > main developement flow is interactive, compiling only edited > files and loading them, while if possible reusing test data > stored in the executing image. In fact, for new code I prefer > interpreter where I can work out expressions on command line, > then wrap them in a function, gradualy function by function > growing the code. Neither git nor svn help with this.
Sorry to say, but you are wrong at least if you use git. Forget about the idea that "a commit is something that lives forever in the repository". You should rather consider git to be a database that you can freely modify. The "master" branch is usually used for "linear" development as you know it from svn trunk. When you do development locally, you say git checkout -b NEW-BRANCH-NAME and all commit you ever do on this branch is never seen by anyone else unless you push it somewhere. So you can commit after each function you add to the code. That are, let's say 20 commits. When everything works for you, you can now decide what to do with all thoses commits. 1) Merge your commit into the master branch. git checkout master git merge NEW-BRANCH-NAME 2) Rebase your changes on top of the new master branch in case the master branch has meanwhile progressed by commits from other people. git rebase master # now "fast-forward" the master branch git checkout master git merge --ff-only NEW-BRANCH-NAME 3) You don't want other people to see you intermediate commits, i.e., you want to put just one commit on top of master. So you squash all your 20 commits into just one. git rebase -i HEAD~21 This brings you into an interaction with git where you can say what to do with the commits. Except for the first, you mark them as "fix". After that you do (1) or (2) from above. Later you say git branch -D NEW-BRANCH-NAME and your development branch is gone as if it has never existed. https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging Why do you think that doesn't help? Because you do not want to use git locally for your own safety? It might happen that you develop two features at the same time. Working on different branches allows you to keep the feature commits separated without the need to open differnt working directories. >> The projects that stick to cvs or svn suffer, as cvs and svn are legacy >> tools, and forcing it on contributors is counterproductive. > > Well, I used cvs and svn was a definite progress compared to cvs. > Not so with git, at least for projects like FriCAS. I understand > that there is familiarity factor, different tool feels clumsy > because it is different, regardless of objective features. OTOH > which version control software is in use should not matter much > for contributors, main work is elsewere. Don't you think that some contributors feel like "oh they are still using git... uff that's not modern. Let's look somewhere else...". Of course, main work is somewhere else, but if the first hurdle is unnecessarily high, that's not good. I'm sure you are clever enough to learn git than it is for the younger generation to go back and learn svn. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/9e07d6ba-3e32-2fcd-49d5-e9da0db5bbab%40hemmecke.org.
