Hello, Ingo Schwarze <schwa...@usta.de> wrote: |Bernd Warken wrote on Mon, Sep 15, 2014 at 09:24:59PM +0200: |> This is about MIT licenses for `ideal' files. | |These files almost certainly do not belong to the MIT.
|In conclusion, i see no indication that you might be entitled |to redistribute these files. If you have put any of them into |the groff git repo, that may already be a violation of Copyright |and hard to undo (it would be relatively easy to undo with CVS, |but it's quite problematic with git). At the risk of being a pa eh stressful.. It is very easy to undo just about anything in git(1), even be selective and remove individual files (in all the repository, meaning all changesets from the very start, see e.g. the git-filter-branch manual; for real git(1) knowledge i would finally point from myself away to the free progit manual [1]), but doing so modifies the entire history of the repository, of course. [1] <https://www.gitbook.io/download/pdf/book/gitbookio/progit?lang=en> Why does groff not take advantage of git(1) and introduce a second regular work branch? I think that has been mentioned several times on this list already? Like this work will progress in there (say [next]), and faulty commits can be adjusted / illegal content removed (and simply via rebasing [next], or alternatively by not cherry-picking individual changesets onto [master], whatever route there will be taken) before they ever reach the immutable [master]. Once the maintainer merges / cherry-picks [next] data into [master], the [next] can be reset, and a new cycle starts. Another advantage of doing so, instead of having, e.g., branches for each contributor or for individual topics (like autoconf), is that the groff community works with a single HEAD that contains all the current changes, and which thus gets compiled and used / tested by quite a lot of people on multiple machines, while still being able to be select what ends in the immutable [master]. --steffen
