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 <c...@apache.org>: > 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 >
