On Thu, Oct 1, 2015 at 7:31 PM, Branko Čibej <[email protected]> wrote:
> Stop. Right. There. > > If you're going to start pointing fingers at people you can just shut > down the project because you're going down the road of petty bickering. > That's a great way to dissolve the community into chaos. > > > On the topic of git usage: > > * Raul is absolutely right about commit messages. When you write a > commit message, think about how useful it would be to *you* if > someone else were writing it. > Agree. > > * I find it really ludicrous that committers on this project are going > through the GitHub pull request rigmarole instead of pushing > directly to the ASF repository. Surely you're not serious? You're > forcing others to RTC instead of doing the right thing in the first > place. > In my view, CTR is not a religion, but rather a tool to speed up development on a project. I think we can all agree that it does not always "speed up" the process. I personally believe that if a commit is moderately complex, it should be reviewed by a peer. This has nothing to do with trust, just good engineering practice. > > * Last but not least: learn to use your tools. The best way to do this > is for someone who really gets git to write up usage guidelines. The > "Git Process" page in cwiki is missing quite a few important bits: > especially actual examples, naming conventions (for tags etc.) and > so on. Git semantics are fsck'd up enough as it is, it makes no > sense for every developer to try to figure out the right way by > herself. > Very good point. The documentation right now has lots of omissions, we should fix it. > > > -- Brane > > > > On 01.10.2015 19:01, Pavel Tupitsyn wrote: > > Sergi, your point is valid, but you are shifting the point of the > > discussion. > > > > Current master branch history, indeed, looks unacceptable. Mostly due to > > insufficient commit descriptions from Anton and Semyon. > > > > On Thu, Oct 1, 2015 at 7:34 PM, Sergi Vladykin <[email protected] > > > > wrote: > > > >> Raul, > >> > >> First of all I think it is not an excuse that you did bad thing because > >> others did as well. > >> Lets try to be perfect ourselves before blaming others. > >> > >> Do you know how I lately solve these issues with comments, squashing and > >> other stuff? > >> I do not do any merges of *my* changes to master at all. Almost never. > >> I just provide pull request on GitHub and ask a reviewer to merge it or > >> return with comments. > >> And when someone asks me to do the same I just do it using provided > script > >> *scripts/apply-pull-request.sh* > >> There is no chance to do something wrong here. > >> > >> I encourage you to do the same and all of your questions will disappear > in > >> a second. > >> > >> Sergi > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> 2015-10-01 1:52 GMT+03:00 Konstantin Boudnik <[email protected]>: > >> > >>> On Wed, Sep 30, 2015 at 09:32PM, Raul Kripalani wrote: > >>>> Igniters, > >>>> > >>>> 1. Git history is polluted by lots of commits like: "Merge > >>> remote-tracking > >>>> branch 'origin/ignite-1.4' into ignite-1.4". Is there a logical reason > >>> for > >>>> this? Why doesn't the team use git pull --rebase? > >>>> > >>>> 2. Let's please define a policy for Git commit messages. The current > >> Git > >>>> history is an *utter mess*. This is totally unacceptable on master: > >>>> https://imgur.com/I95TPMd. > >>>> > >>>> a. Commit messages must carry a context. You should not oblige your > >>>> fellows to dig into the diff to understand what you've done. > >>>> > >>>> b. Even if you are referencing a JIRA ticket, please include some > >>>> context. Nobody remembers ticket numbers by heart and it's a waste of > >>> time > >>>> to open a browser tab for every commit. > >>>> > >>>> c. Pasting the full JIRA URL is wasteful and uses precious real > >>> estate. > >>>> Everybody knows that if you refer to IGNITE-nnnn, you're referring to > >> an > >>>> ASF JIRA ticket. > >>>> > >>>> I agree with many of the tips on this post about Git commit message > >> best > >>>> practices [1]. I suggest you read if you haven't yet. > >>>> > >>>> 3. Let's clarify the merging policy. Yakov complained because I merged > >> a > >>>> branch without squashing. But I see people are doing this. He also > >>>> referenced a Wiki page that explained the procedure for Github pull > >>>> requests. Are we allowed to merge internal branches without squashing? > >>> We shouldn't be. We had this lengthy discussion about proper git > >> practices > >>> where it has been established that squashing of intermediate commits > is > >> a > >>> blessing because > >>> a) no one is interested in "Oh, heck - I forgot the letter" commits > >>> b) rebase-then-merge allows to avoid meaningless "Merge commits", > which > >>> might > >>> only be valuable for bring in some big feature branches, etc. > >>> > >>> Good points on the rest of it as well - let's have some discipline > around > >>> this. > >>> > >>> Cos > >>>> [1] http://chris.beams.io/posts/git-commit/ > >>>> > >>>> Regards, > >>>> > >>>> *Raúl Kripalani* > >>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data > >> and > >>>> Messaging Engineer > >>>> http://about.me/raulkripalani | > >> http://www.linkedin.com/in/raulkripalani > >>>> http://blog.raulkr.net | twitter: @raulvk > > > > > >
