ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Important: Git Policy Changed
Date Tue, 28 Jul 2015 18:16:06 GMT
On Tue, Jul 28, 2015 at 11:02AM, Dmitriy Setrakyan wrote:
> 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?

Absolutely no. You never touch objects that are already in the remote.

Cos

> > 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
View raw message