ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Important: Git Policy Changed
Date Tue, 28 Jul 2015 18:02:57 GMT
On Tue, Jul 28, 2015 at 10:34 AM, Pavel Tupitsyn <ptupitsyn@gridgain.com>
wrote:

> As said above, squash should be used when merging to master (git merge
> branchName --squash "Message"; there are checkboxes in Idea, too).
> This way there is a single commit with a meaningful message in master,
> and it does not matter what happened in the personal branch.
>

Pavel, I am not a GIT expert, so bare with me :)

Will the commits that got merged from master be squashed too? In other
words, will the master commits be piled together with all the user-commits
in one uber-commit from that user?


>
> I think this is the simplest workflow.
>
> Thanks,
>
> On Tue, Jul 28, 2015 at 8:33 PM, Konstantin Boudnik <cos@apache.org>
> wrote:
>
> > On Tue, Jul 28, 2015 at 01:33PM, Pavel Tupitsyn wrote:
> > > > I hope so, it'd be horrible to do that on master!
> > >
> > > Exactly!
> > > But I do not see much sense in enforcing any kind of policy in personal
> > > branches. Sometimes rebase may be better, sometimes I may want to use
> > merge
> > > so I see when and which changes came from master branch, etc.
> > > Only the implementer cares about the look of history in his branch, so
> it
> > > is up to him.
> >
> > You can do with your personal branch whatever you pleased with, of
> course.
> > However, if you make 112 intermediate commits while working on something,
> > there's no need to unleash it on everyone; also it is of little interest
> to
> > anyone to see how many times you merged from the master to your local
> > branch.
> >
> > In this respect, hygiene of the personal branches are of little concern
> to
> > anyone, until one starts contaminating the shared history. Does it make
> > sense?
> >
> > > > Also what will happen if someone will do merge but other rebase?
> > >
> > > Nothing will happen, we are talking about personal branches, they end
> up
> > > being removed. And resulting work is squashed into a patch.
> >
> > Actually, I didn't say anything on how the content of the change is
> > delivered
> > to the master. If you want to do it with patches - sure; but I think it'd
> > be
> > better to do keep using git facilities for that and simply merge dev ->
> > master
> > when you're ready.
> >
> > Cos
> >
> > > On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <
> > akuznetsov@gridgain.com>
> > > wrote:
> > >
> > > > One more. Could I use rebase in my branch if I already use merge on
> > this
> > > > branch before?
> > > >
> > > > On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <
> > akuznetsov@gridgain.com
> > > > >
> > > > wrote:
> > > >
> > > > > I can start user rebase at any moment? Or I should wait for day X
?
> > > > > Or we will start vote?
> > > > >
> > > > > Also what will happen if someone will do merge but other rebase?
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > > GridGain Systems
> > > > > www.gridgain.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Pavel Tupitsyn
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>

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