Re: [rsyslog] can someone lend me a hand on git procedure
2014-11-11 3:03 GMT+01:00 David Lang da...@lang.hm: On Mon, 10 Nov 2014, Thomas D. wrote: Hi, On 2014-11-08 00:19, David Lang wrote: Then when the feature is believed to be complete, it gets merged into a 'pending' tree. This tree exists for the sole purpose of having the testbench run against it daily. This tree is not stable, it's recreated for each day's test run by copying the master and then merging in all the pending features that are beleived to be ready to be tested. Mh... that's sounds like you don't always want to do QA. Then I disagree with you. QA should always be there. You shouldn't think about QA at all, because if we have CI, everything will happen automatically in the background. You don't need to care but if there is a QA problem, you will be notified. As a note on CI testing, no large entitiy does a full test run against each commit individually, this just doesn't scale. At some point the tests just take too long to run. So they fall back to doing the tests at a larer granularity, possibly with unit tests being run on each change (if you can define unit tests in a way that lets you decide easily what tests are relevant to the code that was changed) Unit tests should *always* run. Some functional tests maybe skipped and only run when you are preparing a release. But the discussion is very theoretical at the moment. Github's Travis is very powerful. Let's wait until we really know how much time rsyslog's test suite would actual take. it all depends on how long the tests take to run. If it takes a couple hours to run the tests, you aren't going to want to do them for every commit. Doing them frequently is important, but it's not so important that you need to throttle development to the speed that the tests can run. As for the history being dominated by merges, this is the result of maintaining so many different versions. As John noted when he did the documenation tree, merging changes into the oldest supported version and then merging that into the newer versions lets git do a LOT of work for you in how it remembers what changes have been made and integrating the new changes into it. Merging down instead of merging up would also help: I don't think so. Git already knows about the changes in the one direction, so layering some additional changes on isn't that hard, but moving the other way requires that git figure out where the change came from in order to 'do the right thing', and that's a much harder thing to do. ... especially as (to the best of my knowledge) git does not do that. So on the way down, you need to manually do the merging. Rainer ___ 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.
Re: [rsyslog] can someone lend me a hand on git procedure
Hi, On 2014-11-07 12:27, Rainer Gerhards wrote: 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? Sounds like http://nvie.com/posts/a-successful-git-branching-model/ Regarding my rebase suggestion you maybe want to read http://randyfay.com/content/rebase-workflow-git for a better understanding. -Thomas ___ 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.
Re: [rsyslog] can someone lend me a hand on git procedure
On 2014-11-07 23:29, David Lang wrote: I think that the patch creator (in the feature branch) should do whatever squashing, rebaseing, etc is desired before the patch is sent upstream. If it's a small change, it may make sense to go ahead and alter the history before it's merged, but this shouldn't be a matter of make it one branch, but rather with 20-20 hindsight, this is the ideal series of patches to implement this feature where you trim out false starts, bugs that you later fix, etc. Especially if there is a large change, it's valuable to see the steps in the change individually rather than just having everything combined into one massive patch. +1 ___ 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.
Re: [rsyslog] can someone lend me a hand on git procedure
Hi, On 2014-11-08 00:19, David Lang wrote: Then when the feature is believed to be complete, it gets merged into a 'pending' tree. This tree exists for the sole purpose of having the testbench run against it daily. This tree is not stable, it's recreated for each day's test run by copying the master and then merging in all the pending features that are beleived to be ready to be tested. Mh... that's sounds like you don't always want to do QA. Then I disagree with you. QA should always be there. You shouldn't think about QA at all, because if we have CI, everything will happen automatically in the background. You don't need to care but if there is a QA problem, you will be notified. As a note on CI testing, no large entitiy does a full test run against each commit individually, this just doesn't scale. At some point the tests just take too long to run. So they fall back to doing the tests at a larer granularity, possibly with unit tests being run on each change (if you can define unit tests in a way that lets you decide easily what tests are relevant to the code that was changed) Unit tests should *always* run. Some functional tests maybe skipped and only run when you are preparing a release. But the discussion is very theoretical at the moment. Github's Travis is very powerful. Let's wait until we really know how much time rsyslog's test suite would actual take. As for the history being dominated by merges, this is the result of maintaining so many different versions. As John noted when he did the documenation tree, merging changes into the oldest supported version and then merging that into the newer versions lets git do a LOT of work for you in how it remembers what changes have been made and integrating the new changes into it. Merging down instead of merging up would also help: If someone experiences a problem and we would tell him/her he/she should try to reproduce the problem with master, a patch would land in master first. In future we have a clean history, which would help doing a bisect for example. -Thomas ___ 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.
Re: [rsyslog] can someone lend me a hand on git procedure
On Mon, 10 Nov 2014, Thomas D. wrote: Hi, On 2014-11-08 00:19, David Lang wrote: Then when the feature is believed to be complete, it gets merged into a 'pending' tree. This tree exists for the sole purpose of having the testbench run against it daily. This tree is not stable, it's recreated for each day's test run by copying the master and then merging in all the pending features that are beleived to be ready to be tested. Mh... that's sounds like you don't always want to do QA. Then I disagree with you. QA should always be there. You shouldn't think about QA at all, because if we have CI, everything will happen automatically in the background. You don't need to care but if there is a QA problem, you will be notified. As a note on CI testing, no large entitiy does a full test run against each commit individually, this just doesn't scale. At some point the tests just take too long to run. So they fall back to doing the tests at a larer granularity, possibly with unit tests being run on each change (if you can define unit tests in a way that lets you decide easily what tests are relevant to the code that was changed) Unit tests should *always* run. Some functional tests maybe skipped and only run when you are preparing a release. But the discussion is very theoretical at the moment. Github's Travis is very powerful. Let's wait until we really know how much time rsyslog's test suite would actual take. it all depends on how long the tests take to run. If it takes a couple hours to run the tests, you aren't going to want to do them for every commit. Doing them frequently is important, but it's not so important that you need to throttle development to the speed that the tests can run. As for the history being dominated by merges, this is the result of maintaining so many different versions. As John noted when he did the documenation tree, merging changes into the oldest supported version and then merging that into the newer versions lets git do a LOT of work for you in how it remembers what changes have been made and integrating the new changes into it. Merging down instead of merging up would also help: I don't think so. Git already knows about the changes in the one direction, so layering some additional changes on isn't that hard, but moving the other way requires that git figure out where the change came from in order to 'do the right thing', and that's a much harder thing to do. David Lang If someone experiences a problem and we would tell him/her he/she should try to reproduce the problem with master, a patch would land in master first. In future we have a clean history, which would help doing a bisect for example. ___ 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] can someone lend me a hand on git procedure
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.
Re: [rsyslog] can someone lend me a hand on git procedure
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. -- 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.
Re: [rsyslog] can someone lend me a hand on git procedure
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.
Re: [rsyslog] can someone lend me a hand on git procedure
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
Re: [rsyslog] can someone lend me a hand on git procedure
On 2014-11-07 12:21, Brian Knox wrote: I'm in favor of the process being as simple as possible. indeed 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. +1 to 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.
Re: [rsyslog] can someone lend me a hand on git procedure
On 11/07/14 12:27, Rainer Gerhards wrote: Hi all, Hello Rainer, 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. Before implementing such a change, please give it some more time for people to comment and think it through. This is a big change and shouldn't be rushed. 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. I think it's better to have changes split up into smaller cohesive chunks (that also don't break compilation, functionality, are well documented in the commit message and are generally tidied up). Having the history more granular helps understanding why what happened where - I personally do that _a lot_. Squashing makes for tidier history but also obfuscates it. Having smaller commits makes reverting changes easier. That said, I also do a lot of git-blame-ing and getting through the thick graph of merges isn't fun either. 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. Please don't. :] Having multiple branches with the same content but different histories would bring confusion; directly or indirectly. 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? As Brian similarly noted in a previous email, I don't think it's a good idea to squash on the receiving side. I edit and rebase commits all the time before submitting them for inclusion. If I've dissected the change into couple of patches, It's because I think there's a reason for it. If we'll decide to make it a policy to squash everything before inclusion, I'll send a single patch - no need for upstream to do that. I have this luxury of rewriting my changes because I work in a private branch. Since you push your changes early and often, rebasing (editing, squashing) might be problematic - unless it is made a policy that there are no guaranties about what happens in a feature branch. Tomas ___ 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.
Re: [rsyslog] can someone lend me a hand on git procedure
2014-11-07 15:55 GMT+01:00 Tomas Heinrich thein...@redhat.com: On 11/07/14 12:27, Rainer Gerhards wrote: Hi all, Hello Rainer, 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. Before implementing such a change, please give it some more time for people to comment and think it through. This is a big change and shouldn't be rushed. Thanks. I had the (obviously wrong) idea that no voices meant people were happy with it -- especially as that other thread received a lot of comments initially. But probably most folks got bored when it got longer and longer (understandable now that I think about it), so this probably didn't mean many are fine with the direction. My bad not to think about this. I'll post another pending policy change from that thread (not yet finalized), but I'll do that with a fresh posting so that it doesn't get buried in this thread ;) 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. I think it's better to have changes split up into smaller cohesive chunks (that also don't break compilation, functionality, are well documented in the commit message and are generally tidied up). Having the history more granular helps understanding why what happened where - I personally do that _a lot_. Squashing makes for tidier history but also obfuscates it. That's my prime concern. Having smaller commits makes reverting changes easier. That said, I also do a lot of git-blame-ing and getting through the thick graph of merges isn't fun either. more on that in the upcoming thread (not necessarily today, have some appointments soon). 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. Please don't. :] Having multiple branches with the same content but different histories would bring confusion; directly or indirectly. 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? As Brian similarly noted in a previous email, I don't think it's a good idea to squash on the receiving side. I edit and rebase commits all the time before submitting them for inclusion. If I've dissected the change into couple of patches, It's because I think there's a reason for it. If we'll decide to make it a policy to squash everything before inclusion, I'll send a single patch - no need for upstream to do that. Yeah, that was along the lines that we used successfully for many years. I appreciate that extra information as it helps me understand what's going on (thus at least I don't wanted to loose it). From that other thread, I got the strong impression that features requiring more than one commit are no longer preferred. I have this luxury of rewriting my changes because I work in a private branch. Since you push your changes early and often, rebasing (editing, squashing) might be problematic - unless it is made a policy that there are no guaranties about what happens in a feature branch. Well, I now also have the Adiscon private repository and e.g. the testbench changes are now only in there (it was my testbed to see which problems come up with that approach). But I've already seen how this affects my workflow, as I am no longer able to point people to the code as it develops (there was a concrete case yesterday with a broken testbench test). So far, I tried to do everything in public and not be ashamed of the sometimes dumb errors I made and that manifest in git history. I admit that I make trivial changes directly to master and every now and then (seldom, but happend), I screwed up and got master to fail building. Not sure, though, if that would have been any better if I create a new branch, apply change, merge new branch, delete it - all within 5 minutes. This sounds a little bit overboard to me. From what I got in this thread it looks like more people are in favor of granular commits than the fat ones. I am still listening to voices, but giving the current state, I won't change the way I do commits. Rainer ___ rsyslog mailing list
Re: [rsyslog] can someone lend me a hand on git procedure
I feel the same way, feature branches should not be squashed. David Lang On Fri, 7 Nov 2014, singh.janmejay wrote: 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. -- 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.
Re: [rsyslog] can someone lend me a hand on git procedure
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. I think that the patch creator (in the feature branch) should do whatever squashing, rebaseing, etc is desired before the patch is sent upstream. If it's a small change, it may make sense to go ahead and alter the history before it's merged, but this shouldn't be a matter of make it one branch, but rather with 20-20 hindsight, this is the ideal series of patches to implement this feature where you trim out false starts, bugs that you later fix, etc. Especially if there is a large change, it's valuable to see the steps in the change individually rather than just having everything combined into one massive patch. David Lang 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
