On Tue, Jul 28, 2015 at 10:34 AM, Pavel Tupitsyn <ptupit...@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 <c...@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 < > > akuznet...@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 < > > akuznet...@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 >
