Git history problem
Locked
1234
1234
Git history problem
 
|
Re: Git history problem
|
|
Re: Git history problem
|
|
I tried to follow the instructions found behind the link Mathieu
provided and see that I cannot change the project settings. Who has access to the project settings and can grant me permission to change settings? Thanks, Michael Brohl ecomify GmbH - www.ecomify.de Am 09.03.20 um 22:39 schrieb Michael Brohl: > +1 > > It is easy to prevent this by using rebase merging but committers have to care about it. If Github can be configured to prevent merge commits we should do so. > > Thanks, > Michael > >> Am 09.03.2020 um 17:58 schrieb Mathieu Lirzin <[hidden email]>: >> >> Hello, >> >> The history of OFBiz trunk with the adoption of the Pull Request based >> contribution process is getting less and less readable. Here is a >> snippet of `git log --oneline --graph` demonstrating that: >> >> --8<---------------cut here---------------start------------->8--- >> a3bcdc4cc3 * | Improved: Removes getSubContentWithPermCheck and getSubSub >> |/ >> 8ec3886d7f * Fixed: Code refactoring to support groovy syntax (OFBIZ-1023 >> 604a3bfa02 * Improved: Convert PartyInvitationService.xml from minilang t >> 5b8c89906c * Merge pull request #36 from danwatford/ofbiz-11428-checkst >> |\ >> e665f9dc68 | * Improved: Set checkstyle to use LF line endings >> e9ec4181ec * | Merge pull request #17 from PierreSmits/Label-Cleanup >> |\ \ >> 974b85f4ec | * | Improved: Cleanup HumanRes labels >> c71a7ae06d | * | Improved: UI labels >> c121ad6b9d * | | Merge pull request #15 from PierreSmits/OFBIZ-10551 >> |\ \ \ >> | |_|/ >> |/| | >> 58b0da26f5 | * | Improved: Remove unused labels from ProductUiLabels.xml >> 66aa76d7f7 * | | Merge pull request #35 from danwatford/ofbiz-11418-doc >> |\ \ \ >> 0ece441228 | * | | Fixed: Fixed line lengths in ModelFormFieldTest to adh >> cfad407c48 * | | | Merge pull request #34 from danwatford/ofbiz-11418-d >> |\ \ \ \ >> | |/ / / >> 5640de4eba | * | | Documented: Documented use of field attribute paramete >> --8<---------------cut here---------------end--------------->8--- >> >> I personnally think this is a huge issue because it makes analysing >> history and chasing previously introduced bugs unecessary hard. >> >> I would strongly recommend configuring OFBiz Github to require a linear >> commit history when merging PR [1]. >> >> Thanks. >> >> [1] https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history >> >> PS: Even if I try to be polite, I am profoundly angry regarding the way >> the PR contribution process has been adopted without any formal >> community approval or listening to people having stated important >> requirements that needed to be addressed before moving towards that new >> contribution process. >> >> -- >> Mathieu Lirzin >> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 |
smime.p7s (5K)
Re: Git history problem
|
|
Re: Git history problem
|
|
Re: Git history problem
Administrator
|
Re: Git history problem
|
Administrator
|
Re: Git history problem
|
|
In reply to this post by Jacques Le Roux
This is why I was advocating to leave the wiki page in WIP state until
the command line process is described also. We should rework the wiki page to also show the command line process to merge PR's on the local sandbox which permits ultimate control about what is going to be pushed to the official repositories. I think committers should get used to the process of handling the PRs on their local sandbox and avoid doing it directly against the official repo. I've set the wiki status to WIP again with the reference link to the RocketMQ process which is a good example for the command line processes as well. Thanks, Michael Brohl ecomify GmbH - www.ecomify.de Am 10.03.20 um 10:57 schrieb Jacques Le Roux: > Le 09/03/2020 à 17:58, Mathieu Lirzin a écrit : >> Hello, >> >> The history of OFBiz trunk with the adoption of the Pull Request based >> contribution process is getting less and less readable. Here is a >> snippet of `git log --oneline --graph` demonstrating that: >> >> --8<---------------cut here---------------start------------->8--- >> a3bcdc4cc3 * | Improved: Removes getSubContentWithPermCheck and >> getSubSub >> |/ >> 8ec3886d7f * Fixed: Code refactoring to support groovy syntax >> (OFBIZ-1023 >> 604a3bfa02 * Improved: Convert PartyInvitationService.xml from >> minilang t >> 5b8c89906c * Merge pull request #36 from >> danwatford/ofbiz-11428-checkst >> |\ >> e665f9dc68 | * Improved: Set checkstyle to use LF line endings >> e9ec4181ec * | Merge pull request #17 from PierreSmits/Label-Cleanup >> |\ \ >> 974b85f4ec | * | Improved: Cleanup HumanRes labels >> c71a7ae06d | * | Improved: UI labels >> c121ad6b9d * | | Merge pull request #15 from PierreSmits/OFBIZ-10551 >> |\ \ \ >> | |_|/ >> |/| | >> 58b0da26f5 | * | Improved: Remove unused labels from ProductUiLabels.xml >> 66aa76d7f7 * | | Merge pull request #35 from >> danwatford/ofbiz-11418-doc >> |\ \ \ >> 0ece441228 | * | | Fixed: Fixed line lengths in ModelFormFieldTest to >> adh >> cfad407c48 * | | | Merge pull request #34 from >> danwatford/ofbiz-11418-d >> |\ \ \ \ >> | |/ / / >> 5640de4eba | * | | Documented: Documented use of field attribute >> paramete >> --8<---------------cut here---------------end--------------->8--- >> >> I personnally think this is a huge issue because it makes analysing >> history and chasing previously introduced bugs unecessary hard. >> >> I would strongly recommend configuring OFBiz Github to require a linear >> commit history when merging PR [1]. >> >> Thanks. >> >> [1] >> https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history >> >> PS: Even if I try to be polite, I am profoundly angry regarding the way >> the PR contribution process has been adopted without any formal >> community approval or listening to people having stated important >> requirements that needed to be addressed before moving towards that new >> contribution process. > > Hi Mathieu, > > If my opinion is worth telling, I was initially reluctant to use the > PR process instead of the patch process. Because in general I prefer > to control things, it's even sometimes a problem for me in real life. > I must say it was more laziness which inclined me to PR. > > I noticed that sometimes strange things happen when you use a PR. > Consider this recent email for instance: > https://markmail.org/message/amq5fj2dfma7pcbb. > > There is only the files names, nothing about the changes. You have to > get there to have the information > https://github.com/apache/ofbiz-plugins/commit/4afe603/ not very > convenient :/ > > Moreover if you look at the commit comment in related Jira > (OFBIZ-10948), it says: > > <<Merge pull request #7 from priyasharma1/OFBIZ-10948 > <https://issues.apache.org/jira/browse/OFBIZ-10948> > > Improved: Convert DimensionServices.xml minilang to groovy > (OFBIZ-10948 <https://issues.apache.org/jira/browse/OFBIZ-10948>)>> > > When I supposed it would be only the title and comment at > https://github.com/apache/ofbiz-plugins/pull/7. Why is "Merge pull > request #7 from priyasharma1/OFBIZ-10948 > <https://issues.apache.org/jira/browse/OFBIZ-10948>" added, mystery! > > For a reason I ignore (must be a reason, but I'll not try to > understand) we did not get that. > > Sorry for the digression, now about your point, I agree. I find > strange that the default value of the GH (GitHub) merge button is not > merge and rebase. I guess it's history and legacy... Using the squash > value is also a good option when the merge passes and there are > several commits, it simplifies things when reading emails. > > Like Michael I had a look about the settings. The settings button is > available on my fork but not on the official mirror Github repo. > > This said you certainly saw this thread started by Pierre Smits: > https://markmail.org/message/so7ljoqxzuq7jplz and the related wiki > document > https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github > > The discussion ended with Michael's disagreement, as somehow yours, > but nothing happened. So I think we should move ahead with your > proposition and note the change in the wiki page. I have created > https://issues.apache.org/jira/browse/INFRA-19950 for that. If > somebody disagrees please speak now, even if it will always possible > to revert the change. > > We have also to maintain the related stuff which are also still WIP: > > https://cwiki.apache.org/confluence/display/OFBIZ/Migration+from+Subversion+%28SVN%29+to+Git > > https://issues.apache.org/jira/browse/OFBIZ-11268 > > Nothing happens magically, but it seems we are near the end about the > migration from Subversion to Git process. > > BTW, a question for you: do you think not having a linear commit > history would have an impact on Bisect. I don't think so, just asking > in case you have an experience with that. > > Please don't be angry, it's not good for health. Just listen few > minutes to https://www.youtube.com/watch?v=d-diB65scQU it generally > helps ;) > > Thanks for your proposition! > > Jacques > > |
Git commits email notification problem (was: Git history problem)
|
|
Re: Git history problem
|
|
Re: Git commits email notification problem
|
Administrator
|
Re: Git history problem
|
|
Re: Git history problem
|
Administrator
|
Re: Git history problem
|
Administrator
|
Adopting Github Workflow (was: Git history problem)
|
|
Re: Adopting Github Workflow (was: Git history problem)
|
|
Re: Git history problem
|
|
Re: Adopting Github Workflow
|
|
In reply to this post by Mathieu Lirzin
Hi Mathieu,
inline... Am 11.03.20 um 16:29 schrieb Mathieu Lirzin: > You are right. I should be more constructive than just acknowledging > that the requirements I expressed were not properly considered. > > Let me try joining Pierre's effort by providing a simple but radical > proposal for our contribution procedure : > > - Adopt Github Pull Request (PR) as the unique channel for code contribution -1 I don't see a reason why we should not allow patches also. It will make it easier for people to contribute who are not able (or willing) to run their own GitHub repository. We should encourage people to use PR's but not force it (at least, not immediately...). > - Require tickets only for bug reports -1 Jira tickets for improvements/new features are extremely helpful to have everything in one place (with the addition to a link to the mailing list discussion), track the efforts, watch issues etc. How would you manage the work then? > - Replace JIRA with Github issues -1 Why should we have two different issue management systems when we can have everything in one place? What advantages do you see for doing so? I also would not rely too heavily on GitHub because it is not an official ASF resource and IMO Jira is a huge knowledge base of the project. > - Use Github API to get the stats for OFBiz monthly reports Can you elaborate what you mean/ how you would do it? Thanks, Michael Brohl ecomify GmbH - www.ecomify.de |
Re: Git history problem
|
|
Re: Adopting Github Workflow
|
Administrator
|
| Free forum by Nabble | Edit this page |