Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <560D6DE5.8060103@apache.org>
References: 
 <CAKoNANubw51CJG28fHH9yMMiEGkFwbBNMr_pvMDfJg=SZxbuhg@mail.gmail.com>
 <20150930225208.GT13213@boudnik.org>
 <CA+eZwrFZ+CiB5MBEWx6Dh5Yo=fDc9bnfvesXNUcGCieiJEW2Jw@mail.gmail.com>
 <CAK2_iMO41Hoz21fScTQF=OfxKSmQC7rvyYMSCdD3_iM+YsioMQ@mail.gmail.com>
 <560D6DE5.8060103@apache.org>
From: Sergi Vladykin <sergi.vladykin@gmail.com>
Date: Thu, 1 Oct 2015 23:38:10 +0300
Message-ID: 
 <CA+eZwrETPZnurRw0fP3D6MpRGQMBGfTgp_2kYC3=Mi3xCCHbjQ@mail.gmail.com>
Subject: Re: Let's please fix the mess in Git
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=047d7bd6c4e4d87d130521110881

--047d7bd6c4e4d87d130521110881
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Brane,

2015-10-01 20:31 GMT+03:00 Branko =C4=8Cibej <brane@apache.org>:

> 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 t=
o
> > insufficient commit descriptions from Anton and Semyon.
> >
> > On Thu, Oct 1, 2015 at 7:34 PM, Sergi Vladykin <sergi.vladykin@gmail.co=
m
> >
> > wrote:
> >
> >> Raul,
> >>
> >> First of all I think it is not an excuse that you did bad thing becaus=
e
> >> 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 a=
nd
> >> 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 o=
r
> >> 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 disappea=
r
> in
> >> a second.
> >>
> >> Sergi
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2015-10-01 1:52 GMT+03:00 Konstantin Boudnik <cos@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 reas=
on
> >>> 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 yo=
ur
> >>>> 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 o=
f
> >>> 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 t=
o
> >> 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 merg=
ed
> >> 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 squashin=
g?
> >>> 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=C3=BAl Kripalani*
> >>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Dat=
a
> >> and
> >>>> Messaging Engineer
> >>>> http://about.me/raulkripalani |
> >> http://www.linkedin.com/in/raulkripalani
> >>>> http://blog.raulkr.net | twitter: @raulvk
> >
> >
>
>

--047d7bd6c4e4d87d130521110881--