On Friday, 24 March 2017 at 05:10:54 UTC, Vladimir Panteleev wrote:
> I think that if you do not think that discussing this subject any further is worth your time, then you shouldn't allocate any of your time time towards it. As previously mentioned, I don't think the arguments presented here warrant changing the status quo, so it is all theorizing.

FWIW (as mentioned before) the status quo is different to what's intended as auto-merge-squash has been disabled by Martin:

https://github.com/dlang-bots/dlang-bot/issues/64

On Friday, 24 March 2017 at 05:56:57 UTC, Seb wrote:
> On Friday, 24 March 2017 at 05:10:54 UTC, Vladimir Panteleev wrote:
>> I think that if you do not think that discussing this subject any further is worth your time, then you shouldn't allocate any of your time time towards it. As previously mentioned, I don't think the arguments presented here warrant changing the status quo, so it is all theorizing.
>
> FWIW (as mentioned before) the status quo is different to what's intended as auto-merge-squash has been disabled by Martin:
>
> https://github.com/dlang-bots/dlang-bot/issues/64

Yep, because of the misuse-worst-case arguments. Simple solutions that guard against such mistakes are welcome. E.g. we could allow squashing if all commits' commit messages except the first one's start with "[SQUASH] " or "fixup! ".

On Friday, 24 March 2017 at 09:27:54 UTC, Vladimir Panteleev wrote:
> Yep, because of the misuse-worst-case arguments. Simple solutions that guard against such mistakes are welcome. E.g. we could allow squashing if all commits' commit messages except the first one's start with "[SQUASH] " or "fixup! ".

Because it is meant to be the default, doing only when some specific message exist is not going to fly. Using !donotsquash or alike in the commit message is, however, a good way to proceed.

On Tuesday, 21 March 2017 at 12:49:22 UTC, Vladimir Panteleev wrote:
> On Tuesday, 21 March 2017 at 11:59:42 UTC, deadalnix wrote:
>> Then it should have been 2 PR or more to begin with. Splitting PR in smaller ones is a good practice in general,
>
> This is probably true for many cases, but I don't think it's a general truth.

Let's please not conflate a small technical discussion about how to preserve information in git (e.g. squash vs. merge vs. rebase) with a workflow debate about proper PR size.

On Tuesday, 21 March 2017 at 20:16:00 UTC, Atila Neves wrote:
> git rebase master my_branch
> git checkout master
> git merge --no-ff my_branch

Yes, that's about what we aim for, rebase w/ --autosquash though, so that people can `git commit --fixup` new fixup commits to open PRs w/o leaving noise behind.

https://github.com/dlang-bots/dlang-bot/issues/64

Requires a local checkout of the repo which the bot doesn't have atm.

On Friday, 24 March 2017 at 16:34:46 UTC, Martin Nowak wrote:
> On Tuesday, 21 March 2017 at 20:16:00 UTC, Atila Neves wrote:
>> git rebase master my_branch
>> git checkout master
>> git merge --no-ff my_branch
>
> Yes, that's about what we aim for, rebase w/ --autosquash though, so that people can `git commit --fixup` new fixup commits to open PRs w/o leaving noise behind.
>
> https://github.com/dlang-bots/dlang-bot/issues/64
>
> Requires a local checkout of the repo which the bot doesn't have atm.

Did we come to any consensus on this? I ran into a dilemma with https://github.com/dlang/phobos/pull/5577 where I added a couple fixup commits, and now I don't want to merge until somebody rebases it because the history will be polluted with those extra commits. Also, looking at the PRs linked in this thread, I see that they're still open so AFAICT there is no clear solution.

On Sunday, 19 November 2017 at 04:44:24 UTC, Meta wrote:
> On Friday, 24 March 2017 at 16:34:46 UTC, Martin Nowak wrote:
>> On Tuesday, 21 March 2017 at 20:16:00 UTC, Atila Neves wrote:
>>> git rebase master my_branch
>>> git checkout master
>>> git merge --no-ff my_branch
>>
>> Yes, that's about what we aim for, rebase w/ --autosquash though, so that people can `git commit --fixup` new fixup commits to open PRs w/o leaving noise behind.
>>
>> https://github.com/dlang-bots/dlang-bot/issues/64
>>
>> Requires a local checkout of the repo which the bot doesn't have atm.
>
> Did we come to any consensus on this? I ran into a dilemma with https://github.com/dlang/phobos/pull/5577 where I added a couple fixup commits, and now I don't want to merge until somebody rebases it because the history will be polluted with those extra commits. Also, looking at the PRs linked in this thread, I see that they're still open so AFAICT there is no clear solution.

This is an important issue; rebase workflows are standard practice;
http://kensheedlo.com/essays/why-you-should-use-a-rebase-workflow/
https://help.github.com/articles/configuring-commit-rebasing-for-pull-requests/