2014-11-06 14:02 GMT+01:00 Thomas D. <whi...@whissi.de>: > 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? > > yup. but look at the other commits. They have the information. The
Merge branch 'v8-stable' is just that - I merged up v8-stable into master. I don't know how to make git stop from logging that. An alternative is that I would apply and re-apply the fix that went into an older version for each and every new version. Quite honestly, that takes to much time. But the solution probably is simply to stop maintaining old versions. Especially with the new release philosophy that's probably even a good thing (and saves me quite a bit of time). 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. > Quite simple: they were additions, and so the did not went into any old branch. > > 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? > Yes, but then I use the granularity I'd like to see with the commits. Maybe it's just me, but they *are* actually helpful to me. I'll see if I can keep the full history in a private repository and do these large block commits (back in the v7->v8 transition it were probably between 100 and 200 commits) only in the public git. > > > > 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, > Just to be clear: I never promoted anything or changed anything. This was always the case (except for unintentional bugs, of course). > you maybe want to merge *down*. I.e. if there is a problem, always fix > master first... > Too much effort. On the way down, I need to manually adjust what git otherwise does automatically for me. But again I'll simply stop maintaining the old branches. Maybe that even helps make folks move away from them. 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.
