On 05/25/2018 11:11 AM, Daniel Stone wrote:
Hi,
If we want to weigh the chances when there is a right to be forgotten court case against a Git deployment, we should make an argumentation chart about the possibility to change past commits and its consequences. That chart should include technical arguments, workflow arguments and arguments about traceability and integrity of the code.
Giving it a start, please improve/add/amend, I am probably saying things here that are bluntly incorrect!
Git is changeable because: - it is technically possible to rebase branches - with the right tools (which?), rebasing is feasible to do, like large projects like the Linux kernel show. - the workflow needed for rebasing needs a decision by each maintainer of a local copy. This can be a bit of a hassle, but is doable like large projects like the linux kernel show. - because each participant has to review the rebasing decision code integrity is maintained
Git is unchangeable because: - changing the history is against the design of Git, all technical routes to do so are emergency scenarios with heavy side effects, but it is possible to add notes, new commits or to map e-mail addresses. - for options like rebasing a quite disruptive additional workflow is needed. That workflow demands the cooperation of all developers - Code integrity can only be guaranteed when all commits are traceable activities like rebasing result in untraceable code changes and endanger the security model behind open source software.
Winfried
ps. Beside the changeable / unchangeable discussion there is also the element of expectation that is relevant for the legal discussion.
On Fri, 25 May 2018, 10:04 am Christoph Berg, <myon@debian.org mailto:myon@debian.org> wrote:
Re: Daniel Stone 2018-05-25 <CAPj87rOE9hkVkMknZoMNkp_zpKcKgXd868vULPV5vLV-MwT2wg@mail.gmail.com <mailto:CAPj87rOE9hkVkMknZoMNkp_zpKcKgXd868vULPV5vLV-MwT2wg@mail.gmail.com>> > > Being only a basic Git user, I need your experience here: how practical > > is rebasing to remove a commit message or an e-mail address from a > > commit two years ago? > > > > Technically it's completely trivial and possible to automate. > > Everyone pulling the repository will have to deal with the result: they > will need to manually reconcile the new and old state via a rebase or > merge. This is something that's part of the workflow of some large > repositories. > > The result is somewhat more painful to work with, but that's a workflow and > policy issue rather than a technical one ... This is totally impractical. Suggesting that rebasing larger git repositories is feasible in practise is nonsense.
It causes a workflow issue. It's not technically impossible or an insurmountable limitation of the tool.
Kernel development involves quite a deal of rebasing. There are good tools to handle it. I do it constantly, and am happy to advise you if you're stuck or confused about how rebase works, or how to handle it on the client side.
It is possible to make an argument based on the assurance given by the commit history etc etc, that a linear history is necessary for proper operation and rewriting it is not an option. But this is absolutely not a certainty that legal authorities will agree with your incredibly blunt opinion.