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.
* 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.
* 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.
-- 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 <sergi.vlady...@gmail.com>
> 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 <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
>
>
