2014-11-07 12:35 GMT+01:00 singh.janmejay <[email protected]>:
> Rainer, > > Do we really need to squash? Why not just keep it simple and merge changes > as they come? Its so much better for looking at exactly how/why things are > the way they are. > > No rebase, no rewrites of history etc, just the simple commit and merge. > > well, I don't need all of that overhead. But from the other thread it looked like folks wanted it and nobody said anything else... Rainer > -- > Regards, > Janmejay > > PS: Please blame the typos in this mail on my phone's uncivilized soft > keyboard sporting it's not-so-smart-assist technology. > > On Nov 7, 2014 4:57 PM, "Rainer Gerhards" <[email protected]> > wrote: > > > Hi all, > > > > based on recent discussion ([1] is a good entry point), it looks like > there > > is consensus that feature-branch commits shall be squashed before merging > > them into master. This is a bit bad for me because in almost all cases I > > like the ability to see the interim steps that lead to a feature in > > question (for bisect, but also to better understand what was going on). I > > have also discussed this with my peers in Adiscon and they also prefer > the > > way it currently is. > > > > To satisfy both requirements, we have now setup an internal git for > Adiscon > > use. Our plan is to have a parallel adiscon-master branch inside that > repo, > > which will contain every detail. Its master branch will mirror the public > > git and contain squashed commits. > > > > We now have contributions from Adiscon (including me) and others. Those > > from Adiscon will be done in feature branches, with detail commits and be > > merged into the adiscon-master branch (so that it contains all details). > > Then, I will squash the feature branch into a single commit and merge > that > > into master. So far, so good. > > > > But now we also have non-Adiscon contributions. A current example is [2]. > > One question is if they must be squashed as well? Let's assume this is > not > > the case for whatever reason. So I merge them directly into master. Then, > > to keep my actual working tree up to date, I need to cherry-pick them > into > > adiscon-master. This is where I am a bit hesitant, because of the manual > > action. I fear that the master and adiscon-master branches may begin to > > diverge, and be it through a simple mistake. > > > > So maybe it is better to merge pull requests into new feature branches, > and > > then work "as usual": merge feature branch into adiscon-master, squash > > feature branch, then merge it as single commit into master. > > > > To sum up: I would like to have two branches, the private one with all > > detail information, the public one minus those commits that are > considered > > distracting. What is the best way to achieve this goal? > > > > Feedback appreciated, > > Rainer > > > > [1] http://lists.adiscon.net/pipermail/rsyslog/2014-November/038883.html > > [2] https://github.com/rsyslog/rsyslog/pull/147 > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com/professional-services/ > > What's up with rsyslog? Follow https://twitter.com/rgerhards > > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > > DON'T LIKE THAT. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > DON'T LIKE THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
