Let's please fix the mess in Git

[Raul Kripalani]

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?

[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

[Konstantin Boudnik-2]

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

[Sergi]

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 <[hidden email]>:

> 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
>

[Pavel Tupitsyn-3]

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 <[hidden email]>
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 <[hidden email]>:
>
> > 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
> >
>

--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

[Branko Čibej]

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 <[hidden email]>
> 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 <[hidden email]>:
>>
>>> 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
>
>

[Sergi]

Brane,

2015-10-01 20:31 GMT+03:00 Branko Čibej <[hidden email]>:

> 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.
>
>
Of course we must be polite to each other if we want to work together.
I'd suggest Pavel to write personal emails instead of discussing teammates
on the dev list.


>
> 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, moreover I think it is a good idea to use the same description as in
Jira issue and pull request name.


>
>   * 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.
>

For me the right thing is to use convenient and reliable tools with
straightforward
automated work flow to avoid human errors as much as possible. In this
respect git by itself is a wrong tool just because it allows to do a single
thing
multiple ways and now we have to argue which way is "right" or "wrong".

GitHub + apply-pull-request.sh is a right choice for me because it does not
allow
random shit to happen and you always share the responsibility with the
reviewer.

And you are right, I actually prefer to enforce RTC for everyone, because
as far
as I remember CTR was encouraged only for minor changes like javadoc fix
and it was strongly recommended to do a review for more complex
changes, but this strong recommendation is simply ignored right now.
See https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process


>
>   * 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.
>

Agree that we need to describe naming conventions but everything that
can be automated here must be automated. And we already have done that:
look inside of `scripts` folder.

Sergi

>
> -- 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 <[hidden email]
> >
> > 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 <[hidden email]>:
> >>
> >>> 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
> >
> >
>
>

[dsetrakyan]

On Thu, Oct 1, 2015 at 7:31 PM, Branko Čibej <[hidden email]> 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 <[hidden email]
> >
> > 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 <[hidden email]>:
> >>
> >>> 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
> >
> >
>
>

[Konstantin Boudnik-2]

Being looking into something today on the master and this sight has caught my
attention
    http://imgur.com/MmxgbnU

It's _eight_ levels of merges, which makes the history impossible to
investigate in case something needs to be figured out. I think I need to find
time and write the documentation on how to use git properly, after all ;)

Cos

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?
>
> [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

[dsetrakyan]

On Thu, Oct 15, 2015 at 2:11 PM, Konstantin Boudnik <[hidden email]> wrote:

> Being looking into something today on the master and this sight has caught
> my
> attention
>     http://imgur.com/MmxgbnU
>
> It's _eight_ levels of merges, which makes the history impossible to
> investigate in case something needs to be figured out. I think I need to
> find
> time and write the documentation on how to use git properly, after all ;)
>

Or you can look at the latest Git process and propose changes to it:

https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-GitProcess

>
> Cos
>
> 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?
> >
> > [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
>

[Konstantin Boudnik-2]

On Thu, Oct 15, 2015 at 03:10PM, Dmitriy Setrakyan wrote:

> On Thu, Oct 15, 2015 at 2:11 PM, Konstantin Boudnik <[hidden email]> wrote:
>
> > Being looking into something today on the master and this sight has caught
> > my
> > attention
> >     http://imgur.com/MmxgbnU
> >
> > It's _eight_ levels of merges, which makes the history impossible to
> > investigate in case something needs to be figured out. I think I need to
> > find
> > time and write the documentation on how to use git properly, after all ;)
> >
>
> Or you can look at the latest Git process and propose changes to it:
>
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-GitProcess

Yeah, that's what I really meant, of course. Thanks!

> > 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?
> > >
> > > [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
> >