Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incubation] Contributions via GitHub, how to handle squash commits
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:


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 <mistria@xxxxxxxxxx> wrote:

Hi,

On Wed, Jul 26, 2017 at 11:51 AM, Jens von Pilgrim <developer@xxxxxxxxx> 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 developer, at Red Hat Developers community
_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation

Back to the top