skiplang / skip

A programming language to skip the things you have already computed
http://skiplang.com
MIT License
1.97k stars 66 forks source link

Proposal: Set 'rebase and merge' as the standard method for commits #25

Open jasone opened 5 years ago

jasone commented 5 years ago

The git history is already looking a bit hairy due to merge commits. I propose that we change the github settings for this repository to default to 'rebase and merge'.

vjeux commented 5 years ago

@JoelMarcey could you set it if you don't mind? Thanks!

pikatchu commented 5 years ago

Are you cool with "squash and merge"?

This seems to be the default right now and I actually like it. Otherwise I usually end up squashing my "mini diffs" by hand on my branch and then push -f to the pull request before merging.

So that option already does that for me :-)

If you feel strongly about it I am happy to change it.

jasone commented 5 years ago

I don't have a strong opinion on squashing, though I tend to think it's something that we should at least be able to opt out of, so that on occasions a pull request can cleanly be broken into multiple stacked diffs, we preserve that. The thing that's bugging me is the messiness caused by merge commits. Here's part of what tig currently shows. image We just need a slightly faster commit rate to make the commit graph inscrutable. Oh, and git bisect gets a bit weirder to work with when merge commits are common. I can live with merge commits, but I view them as an obfuscating force.

JoelMarcey commented 5 years ago

@jasone @vjeux @pikatchu I personally also like squash and merge, but I definitely understand the merits of rebase and merge. Just let me know which way to go here.

I can remove the option of Merge Pull Request if we just want to start there too.

jasone commented 5 years ago

Interesting, it sounds like there's not clear agreement on this, so let's leave things as they are for now. However, I am curious to understand what benefit you see in the merge commits. Do they provide a more detailed commit history that you find useful for some purposes?

josephsavona commented 5 years ago

I can remove the option of Merge Pull Request if we just want to start there too.

@JoelMarcey Do you mean we can remove the option that creates a merge commit? Having just squash-merge and rebase-merge at least means we always keep the commit history clean. Most commits (especially from the community) are small and squashing makes sense, larger commits will likely be from maintainers and they (we) can choose rebase-merge when it makes sense.

JoelMarcey commented 5 years ago

@josephsavona Yep, we can choose any combo.

screenshot 2018-10-01 08 58 22

josephsavona commented 5 years ago

Cool, let's just disable "allow merge commits" and keep squash-merging as the default?

@jasone does that sound reasonable for now?

JoelMarcey commented 5 years ago

Done.