Hi, On 2014-11-05 17:23, Rainer Gerhards wrote: > doesn't that mean I am loosing the ability to do a git bisect later > on? (for whatever reason)
Mh, not if you do what I am thinking of. What's my problem: Reading a commit log like - Merge branch 'v8-stable' - Merge branch 'v8-stable' - Merge branch 'v7-stable' into v8-stable - Merge branch 'v8-stable' - Merge branch 'v8-stable' - Merge branch 'v8-stable' - Merge branch 'master' of https://github.com/rsyslog/rsyslog - Merge branch 'v8-stable' - Merge branch 'v8-stable' - Merge branch 'v7-stable' - Merge branch 'v8-stable' is not very helpful. Nobody understands what's going on. You can (technically) do a bisect, but if bisect says https://github.com/rsyslog/rsyslog/commit/1be4d911e9f837b75741918a4c712504b15964ca was the problem, it is very hard to understand the commit. No history, you maybe don't know what this is doing... Better: - Merge branch 'v8-stable-backgrounding' into v8-stable ...at least if you know the feature branch "backgrounding". But it could be better. Even better: - Merge pull request #138 from PaulSD/master Well, the merge looks like a normal merge you do and I criticized, the important difference is the "#138" reference. It would be perfect if we would just see - bugfix imkmsg: infinite loop on OpenVZ VMs You get an idea? So if it is possible, please keep the original commit message. Most times if you rebase (so you can ff because the changes are on top), that will be the case. The commits from janmejay are a good example, where you did something like that. To be clear: You should never ever rewrite the history of master. But rebasing your feature branch, even if it is public, should be OK if you make a policy like "Be warned, this is a moving branch. I maybe rewrite everything.." Regarding squashing: See the stable-backgrounding feature branch, https://github.com/rsyslog/rsyslog/commits/v8-stable-backgrounding Someone maybe argue it is nice to see exactly where you came from. I.e. someone want to see - first shot at auto-backgrounding by using a pipe instead of signals which was corrected by - fix problems with last commit, add timeout capability and that you missed the changelog file :) But in master, I don't care. So currently, it is hard to just backport this feature. Well, you can grab the merge commit... but if you would squash this feature branch into suitable clean commits and finally merge it into master with keeping your nice commit messages... that would be better. Again, you get my idea? > Almost correct, except that real feature branches never go into the > old versions, because new features always go into -devel. What you > see is bugfixes. And, yes, it safes a lot of time applying them to > the oldest branch and merging them up. That way, I was able to > maintain old -strictly considered unsupported- branches together with > the current one with no real effort. Now that you promoted master to be always working and the best choice, you maybe want to merge *down*. I.e. if there is a problem, always fix master first... -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.
