On Tue, Jul 28, 2015 at 11:02AM, Dmitriy Setrakyan wrote: > On Tue, Jul 28, 2015 at 10:34 AM, Pavel Tupitsyn <[email protected]> > 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 <[email protected]> > > 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 < > > > [email protected]> > > > > 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 < > > > [email protected] > > > > > > > > > > > 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 > >
