Re: Proposal: make squash-merging the default behavior for gitlab MRs

So to close the loop on this discussion, it seems like folks are not generally in favor of my proposal, for various sensible and well-considered reasons. I will beef up our GitLab documentation to add more information about how to use a curated commit history approach and will drop the idea to

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Wednesday, October 7, 2020 5:26:05 PM CEST Thomas Friedrichsmeier wrote: > Probably not something we can easily configure/adjust downstream, > though? What we can easily can change on our level, is to provide a default MR description in every project. (Like the default bug description in

Re: Proposal: make squash-merging the default behavior for gitlab MRs

Am Mi., 7. Okt. 2020 um 11:27 Uhr schrieb Thomas Friedrichsmeier : > > Am Tue, 6 Oct 2020 08:26:02 -0600 > schrieb Nate Graham : > > GitLab already *kind of* offers this, in the form of the "Squash > > commits" checkbox next to the merge button. Apparently it's not > > obvious enough though,

Re: Proposal: make squash-merging the default behavior for gitlab MRs

Am Tue, 6 Oct 2020 08:26:02 -0600 schrieb Nate Graham : > GitLab already *kind of* offers this, in the form of the "Squash > commits" checkbox next to the merge button. Apparently it's not > obvious enough though, because I can think of a bunch of cases of > multi-commit MRs with mostly garbage

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Wed, Oct 7, 2020 at 9:33 PM David Hurka wrote: > On Wednesday, October 7, 2020 9:52:41 AM CEST Ben Cooksley wrote: > > > Isn’t it true that “Allow contributions” must be checked before the > > > “Squash > > > commits” checkbox is available? (I already wrote that, but I feel > people > > >

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Wednesday, October 7, 2020 9:52:41 AM CEST Ben Cooksley wrote: > > Isn’t it true that “Allow contributions” must be checked before the > > “Squash > > commits” checkbox is available? (I already wrote that, but I feel people > > don’t > > care, so I make it a question now.) > > The allow

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Wed, Oct 7, 2020 at 8:08 AM David Hurka wrote: > On Tuesday, October 6, 2020 4:26:02 PM CEST Nate Graham wrote: > > Taking stock of the responses so far, it doesn't seem like there's much > > enthusiasm for the original proposal. That's fine, and I can understand > > the desire to push people

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Tuesday, October 6, 2020 4:26:02 PM CEST Nate Graham wrote: > Taking stock of the responses so far, it doesn't seem like there's much > enthusiasm for the original proposal. That's fine, and I can understand > the desire to push people to improve their git skills. Yes, I interpret this thread

Re: Proposal: make squash-merging the default behavior for gitlab MRs

Taking stock of the responses so far, it doesn't seem like there's much enthusiasm for the original proposal. That's fine, and I can understand the desire to push people to improve their git skills. It seems like there is some agreement on an alternative, which various people have proposed:

Re: Proposal: make squash-merging the default behavior for gitlab MRs

my suggestion is not making squash default but implement a way that will pops up a question if there are more then 1 commits in mr so user can select on that time. On Mon, Oct 5, 2020, 19:15 David Hurka wrote: > > Even better might be to force an explicit decision by not having a > default > >

Re: Proposal: make squash-merging the default behavior for gitlab MRs

> Even better might be to force an explicit decision by not having a default > for this at all, e.g. by offering "Rebase" and "Squash + Rebase" actions > next to each other. The squash checkbox is available directly next to the Rebase/Merge button; provided the “Allow Contributions” checkbox was

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Freitag, 2. Oktober 2020 23:38:20 CEST Albert Astals Cid wrote: > El divendres, 2 d’octubre de 2020, a les 21:19:02 CEST, Konstantin Kharlamov va escriure: > > On Fri, 2020-10-02 at 11:39 -0600, Nate Graham wrote: > > > Accordingly, I think squash-merging makes sense as the default value to >

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On 02/10/20 19:39, Nate Graham wrote: > Hello folks, Hi > I've been told that our Sysadmins have developed some tooling capable of > checking the "Squash when merging" checkbox by default for new Merge > Requests. This would be a downstream solution to >

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Sat, Oct 3, 2020 at 12:19 PM David Hurka wrote: > > Why should colleagues navigate through any commits, when the MR is intended to > be squashed? Wouldn’t squash merge make it easier to review an MR? > No because squashing happens only when merging, i.e. *after* reviewing. So if you review

Re: Proposal: make squash-merging the default behavior for gitlab MRs

> > your_merge_request_commit_history > > . > > However, it remains a fairly advanced workflow which is challenging for > newcomers, drive-by-developers, and people not as familiar with git. For > these

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Sat, Oct 3, 2020 at 10:15 AM Boudewijn Rempt wrote: > > On Friday, 2 October 2020 19:39:37 CEST Nate Graham wrote: > > > Thoughts? > > Like others have said, please, no. Squashed commits are the worst things to > have in a git history. They make it hard to use git blame, they make it hard >

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Sat, Oct 3, 2020 at 12:26 AM David Hurka wrote: > > > > However, it remains a fairly advanced workflow which is challenging for > > > newcomers, drive-by-developers, and people not as familiar with git. For > > > these people, squash-merging makes much more sense, [...] > > This workflow is

Re: Proposal: make squash-merging the default behavior for gitlab MRs

> That doesn't prevent me from having a clean history when I finally git-push > to an opened MR, so my colleagues could easily review my code. I know that > if I'd push some "dirty" commits to my "merge request", my colleagues would > unnecessarily spend time navigating these commits, and

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Friday, 2 October 2020 19:39:37 CEST Nate Graham wrote: > Thoughts? Like others have said, please, no. Squashed commits are the worst things to have in a git history. They make it hard to use git blame, they make it hard to read the history... And the whole argument about making life easier

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Sat, 2020-10-03 at 00:26 +0200, David Hurka wrote: > > > However, it remains a fairly advanced workflow which is challenging for > > > newcomers, drive-by-developers, and people not as familiar with git. For > > > these people, squash-merging makes much more sense, [...] > > This workflow is

Re: Proposal: make squash-merging the default behavior for gitlab MRs

> > However, it remains a fairly advanced workflow which is challenging for > > newcomers, drive-by-developers, and people not as familiar with git. For > > these people, squash-merging makes much more sense, [...] This workflow is too advanced for me. My commits are usually garbage like “fix

Re: Proposal: make squash-merging the default behavior for gitlab MRs

El divendres, 2 d’octubre de 2020, a les 21:19:02 CEST, Konstantin Kharlamov va escriure: > On Fri, 2020-10-02 at 11:39 -0600, Nate Graham wrote: > > Accordingly, I think squash-merging makes sense as the default value to > > avoid this. People who are comfortable with the "curated MR commit > >

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Fri, 2020-10-02 at 11:39 -0600, Nate Graham wrote: > Hello folks, > I've been told that our Sysadmins have developed some tooling capable of > checking the "Squash when merging" checkbox by default for new Merge > Requests. This would be a downstream solution to >

Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Friday, 2 October 2020 18:39:37 BST Nate Graham wrote: > Hello folks, > I've been told that our Sysadmins have developed some tooling capable of > checking the "Squash when merging" checkbox by default for new Merge > Requests. This would be a downstream solution to >

Re: Proposal: make squash-merging the default behavior for gitlab MRs

> [...] > I've been told that our Sysadmins have developed some tooling capable of > checking the "Squash when merging" checkbox by default for new Merge > Requests. [...] > > I'd like to propose [squash-merge] as a sane default for new Merge > Requests. > > [...] > Thoughts? Yes, I would like