I'm in favor of the process being as simple as possible. The more work and thought that has to be put into dealing with pull requests, the more likely either work will get slowed down, or someone will make a mistake.
I feel like if I want to squash, etc I can just do that on branches on my own fork, and then send the cleaned up version back to you. I don't feel like you should have to deal with squashing my commits. I also don't have a problem personally with seeing the merge messages. On Fri, Nov 7, 2014 at 6:39 AM, Rainer Gerhards <rgerha...@hq.adiscon.com> wrote: > 2014-11-07 12:35 GMT+01:00 singh.janmejay <singh.janme...@gmail.com>: > > > 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" <rgerha...@hq.adiscon.com> > > 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. > _______________________________________________ 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.
