I haven't contributed to a Github-hosted Eclipse project yet, but it appears the Sign-off can be enforced on commits by the Foundation's ip-validation bot.
Forcing the user to squash and re-sign-off is a pain, and more importantly it goes against the expected Github workflow. Introducing new points of friction would seem to defeat the motivation behind moving to Github! On a squash-and-merge commit, Github normally puts in the Pull Request number. For example (https://github.com/eclipse/che/commit/d5de61bfb9e64691c68f6ea607fc443c3a71f2f9): CHE-3221: Fix git compare on submodules. (#5799) * CHE-3221: Fix git compare on submodules. That acts as a back pointer to the associated PR which has records to the original commits with the signed-off records. There are a few tools that will backup all the Github metadata associated with a project, including issues and PRs: https://help.github.com/articles/backing-up-a-repository/ Wouldn't it then be enough for the foundation to maintain periodic backups of this data? Brian. > On 26-Jul-2017, at 6:01 AM, Mickael Istria <[email protected]> wrote: > > Hi, > > On Wed, Jul 26, 2017 at 11:51 AM, Jens von Pilgrim <[email protected] > <mailto:[email protected]>> wrote: > 1) What happens if a contributor has forgotten to sign-off? Is it possible to > "sign-off" the pull-request? > > I believe you have to ask the committer to add the Sign-off, otherwise > you're simply not allowed to merge the patch. > Pull requests are not part of the commit record nor of the history, they're > staying on GitHub and aren't portable if your code has to move one day, so I > don't think putting a sign-off on the PR is useful nor enough. > > 2) We use "Squash and Merge" commits in order to reduce the size of the > commit history and to simplify the identification of problematic commits > (since a commit then usually correlates with a task and a specific fix or new > feature). In that case, the initial "commit record" of the contributor is > gone, and the commit has to be performed by a committer. > > That's one of the many issue with squash and merge ;) I suggest you or the > user squash manually, make the squashed patch work, and push the squashed > commit as a replacement of the PR (using a `git push --force > commit:target-pr-branch` is the only way I'm aware to do it). > That has many advantages: > 1. It allows to review the squashed commit - which may have issues compared > to the series of commits > 2. It allows to better deal with commit message > > 2) GitHub's "Squash and Merge" creates a new commit, but preserves the > information about the original commits in the comment. This information is > used by the IP tooling to gather information about the contributor, even > though the "squash commit" is done by a committer. > > I don't have a clue about this one. > The only thing I know is if you break the "squash and merge" operation into > "squash" and "merge", everything becomes simpler afterwards ;) > > HTH > -- > Mickael Istria > Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> developer, > at Red Hat Developers <https://developers.redhat.com/> community > _______________________________________________ > incubation mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
