Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 356418 - Allow non-committers e-mail addresses in git commits
Summary: Allow non-committers e-mail addresses in git commits
Status: CLOSED WONTFIX
Alias: None
Product: Community
Classification: Eclipse Foundation
Component: Git (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Eclipse Webmaster CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-31 18:38 EDT by Doug Schaefer CLA
Modified: 2011-09-07 10:25 EDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Doug Schaefer CLA 2011-08-31 18:38:52 EDT
A standard git workflow is to fetch commits from remotes, merge them into master branches, and push them to the golden repo.

Of course, the current restriction at Eclipse is that the committer e-mail address must be of a valid Eclipse committer. However when a contributor is working on github, for example, it'll be their e-mail address registered in the commit record.

This is creating extra work for us to figure out how to do this important workflow. For CDT we have three projects on the go from contributors that we want to bring into CDT once they're ready.

One simple idea is to keep a database of approved commit ids. So if the e-mail check fails, check the commit ids against this database.
Comment 1 Doug Schaefer CLA 2011-08-31 18:40:44 EDT
The IPzilla would list the commit ids (URLs to github, for example). Once approved, they'd be entered into the database.
Comment 2 Wayne Beaton CLA 2011-09-06 12:47:24 EDT
Can we assume that the contributor in this scenario is always an existing Eclipse committer?

We need to keep in mind that we currently do not import history with a contribution. If I understand your scenario, work developed at GitHub will--at some point--be brought to Eclipse. At this point, the code needs to be checked by the IP Team. They are not able to check history, so--at this point--we'd require that a code base be taken through the IP process and that snapshot would have to be committed.
Comment 3 Doug Schaefer CLA 2011-09-06 13:54:49 EDT
(In reply to comment #2)
> Can we assume that the contributor in this scenario is always an existing
> Eclipse committer?

No, the point is the contributor is not a committer.

> We need to keep in mind that we currently do not import history with a
> contribution. If I understand your scenario, work developed at GitHub will--at
> some point--be brought to Eclipse. At this point, the code needs to be checked
> by the IP Team. They are not able to check history, so--at this point--we'd
> require that a code base be taken through the IP process and that snapshot
> would have to be committed.

Yes, that may be the best solution. We can use command-line git to create a patch, using git-diff, for the contribution. Once approved we can then apply the patch.

I was hoping we could keep the history throughout the off-site development. There may be other approaches to managing that.

And even more ideally, we can move to Gerrit and do the development there. :p
Comment 4 Wayne Beaton CLA 2011-09-06 16:40:29 EDT
Moving the history of a contribution is currently not permitted. To change that would require a board resolution; this is something to explore with the committer reps if there is will (FWIW, keeping history would--under current rules--require that the history be scanned by the IP team thereby stretching already-thin resources).

Another work around: you can do the exploratory work in an incubator.

I'm not sure what else we can do to resolve this bug. Is it time to close it?
Comment 5 Doug Schaefer CLA 2011-09-07 10:25:11 EDT
Yeah, sure. It is what it is, I guess.