ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Let's please fix the mess in Git
Date Thu, 01 Oct 2015 22:38:38 GMT
On Thu, Oct 1, 2015 at 7:31 PM, Branko Čibej <brane@apache.org> 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 <sergi.vladykin@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 <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 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
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message