Re: why not use git rebase instead of git merge in dlang repos?
On Wednesday, 7 March 2018 at 22:28:26 UTC, ketmar wrote: H. S. Teoh wrote: I've pestered Brad about it before, but the real trouble is the Mailman software. If you feel motivated enough, pestering the upstream Mailman authors about it might actually get us closer to fixing this problem, as it really isn't a problem on Brad's end either. It's not unfixable, it just requires a change to the Mailman software to process headers correctly. yeah, that is what i meant when i wrote "current arch". ;-) can we move this side-discussion to https://github.com/CyberShadow/DFeed/issues/99 (root cause of split threads?) => see my last post in particular which mentions 'Changing the setting of anonymous_list to no has resulted in the correct Message-Id'
Re: why not use git rebase instead of git merge in dlang repos?
H. S. Teoh wrote: I've pestered Brad about it before, but the real trouble is the Mailman software. If you feel motivated enough, pestering the upstream Mailman authors about it might actually get us closer to fixing this problem, as it really isn't a problem on Brad's end either. It's not unfixable, it just requires a change to the Mailman software to process headers correctly. yeah, that is what i meant when i wrote "current arch". ;-)
Re: why not use git rebase instead of git merge in dlang repos?
On Thu, Mar 08, 2018 at 12:10:28AM +0200, ketmar via Digitalmars-d wrote: > Seb wrote: > > > OT: I don't know what you are doing, but you seem to be the only one > > who always creates new threads when replying. I assume you use nntp? > > Maybe something wrong with your client? > > it was already discussed several times: this is the issue with mailing > list processor: it cannot properly link replies. it is unfixable with > the current nntp/mlist arch, though. Yeah, the trouble is that I'm using the mailing list interface, and Mailman, the software behind that, is munging my outgoing mail headers. Nothing much I can do from my end, unfortunately. I've pestered Brad about it before, but the real trouble is the Mailman software. If you feel motivated enough, pestering the upstream Mailman authors about it might actually get us closer to fixing this problem, as it really isn't a problem on Brad's end either. It's not unfixable, it just requires a change to the Mailman software to process headers correctly. T -- People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
Re: why not use git rebase instead of git merge in dlang repos?
Seb wrote: OT: I don't know what you are doing, but you seem to be the only one who always creates new threads when replying. I assume you use nntp? Maybe something wrong with your client? it was already discussed several times: this is the issue with mailing list processor: it cannot properly link replies. it is unfixable with the current nntp/mlist arch, though.
Re: why not use git rebase instead of git merge in dlang repos?
On Wednesday, 7 March 2018 at 21:03:52 UTC, H. S. Teoh wrote: On Wed, Mar 07, 2018 at 12:42:52PM -0800, Timothee Cour via Digitalmars-d wrote: [...] On the contrary, I find using merge is easier to understand, because it shows clearly individual commits within a single PR, and also a linear series of merged PRs if you traverse down master. In fact, in my own projects I sometimes purposely use `git merge --no-ff` to force a merge commit, because it shows distinct lines of development more clearly. But I suppose this is one of the things reasonable people will disagree on. T OT: I don't know what you are doing, but you seem to be the only one who always creates new threads when replying. I assume you use nntp? Maybe something wrong with your client?
Re: why not use git rebase instead of git merge in dlang repos?
On Wed, Mar 07, 2018 at 12:42:52PM -0800, Timothee Cour via Digitalmars-d wrote: > There are lots of articles on this topic, eg: > https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/ > (note that squashing down to 1 commit shouldn't be necessary but at > least rebasing should be done) > > github UI also allows to rebase (instead of merge) > > would really simplify things like visualization / understanding > history, git bisect. It shouldn't matter at what commit was a feature > started, only thing that matter should be when it was incorporated > into master. On the contrary, I find using merge is easier to understand, because it shows clearly individual commits within a single PR, and also a linear series of merged PRs if you traverse down master. In fact, in my own projects I sometimes purposely use `git merge --no-ff` to force a merge commit, because it shows distinct lines of development more clearly. But I suppose this is one of the things reasonable people will disagree on. T -- Customer support: the art of getting your clients to pay for your own incompetence.
why not use git rebase instead of git merge in dlang repos?
There are lots of articles on this topic, eg: https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/ (note that squashing down to 1 commit shouldn't be necessary but at least rebasing should be done) github UI also allows to rebase (instead of merge) would really simplify things like visualization / understanding history, git bisect. It shouldn't matter at what commit was a feature started, only thing that matter should be when it was incorporated into master.
