Important: Git Policy Changed

[Alexey Kuznetsov-2]

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

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

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

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

On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <[hidden email]>
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 <[hidden email]
> >
> 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

[Alexey Kuznetsov-2]

So we are going to work only with patches?
No more merges from personal branches into master?

On Tue, Jul 28, 2015 at 5:33 PM, Pavel Tupitsyn <[hidden email]>
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.
>
> > 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.
>
> On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <[hidden email]
> >
> 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 <
> [hidden email]
> > >
> > 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
>

--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[Pavel Tupitsyn-3]

Alexey, we were talking about master->personal.

As for merging to master, there should be strictly one commit per feature.
This can be achieved in multiple ways (patch, merge/pull with squash). And
with squash, it does not matter how personal branch history looks.

On Tue, Jul 28, 2015 at 1:38 PM, Alexey Kuznetsov <[hidden email]>
wrote:

> So we are going to work only with patches?
> No more merges from personal branches into master?
>
> On Tue, Jul 28, 2015 at 5:33 PM, Pavel Tupitsyn <[hidden email]>
> 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.
> >
> > > 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.
> >
> > On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <
> [hidden email]
> > >
> > 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 <
> > [hidden email]
> > > >
> > > 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
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

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

[Konstantin Boudnik-2]

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

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.

I think this is the simplest workflow.

Thanks,

On Tue, Jul 28, 2015 at 8:33 PM, Konstantin Boudnik <[hidden email]> 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 <
> [hidden email]>
> > 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 <
> [hidden email]
> > > >
> > > 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

[Konstantin Boudnik-2]

You can use squash independent from merge. It is done via simple interactive
rebase and can be used at any time at one's convenience. However, it is
important to remember not to squash someone's else commits as it changes the
SHAs of the object.

I'd be happy to do a session for anyone who needs a bit of education around
these technologies, but I am fairly sure there's plenty of materials like that
on the net.

Cos

On Tue, Jul 28, 2015 at 08:34PM, Pavel Tupitsyn 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.
>
> I think this is the simplest workflow.
>
> Thanks,
>
> On Tue, Jul 28, 2015 at 8:33 PM, Konstantin Boudnik <[hidden email]> 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 <
> > [hidden email]>
> > > 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 <
> > [hidden email]
> > > > >
> > > > 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

[dsetrakyan]

On Tue, Jul 28, 2015 at 10:34 AM, Pavel Tupitsyn <[hidden email]>
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 <[hidden email]>
> 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 <
> > [hidden email]>
> > > 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 <
> > [hidden email]
> > > > >
> > > > 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
>

[Konstantin Boudnik-2]

On Tue, Jul 28, 2015 at 11:02AM, Dmitriy Setrakyan wrote:

> On Tue, Jul 28, 2015 at 10:34 AM, Pavel Tupitsyn <[hidden email]>
> 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 <[hidden email]>
> > 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 <
> > > [hidden email]>
> > > > 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 <
> > > [hidden email]
> > > > > >
> > > > > 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
> >