Repository navigation
New GitHub Merging #6002
Description
Activity
First Microsoft does Bash and now this?! What is this future alternate
universe I'm living in?!
On Apr 1, 2016 12:41 PM, "Jeremiah Senkpiel" notifications@github.com
wrote:GitHub has a new merge button feature, allowing it do a "squash-merge".
See: https://github.com/blog/2141-squash-your-commitsI've done a little test [1]
TestOrgPleaseIgnore/-TEST-#2, [2]
https://github.com/TestOrgPleaseIgnore/-TEST-/commits/master, and it
appears to do what we want. No merge commit.[image: 🎉] [image: 🎉] [image: 🎉] [image: 🎉] [image:
🎉] [image: 🎉] [image: 🎉] [image: 🎉]I have disabled the old-style merge button use on the core repo here
already. We should double check and make sure this meets our merge
standards before using though.@nodejs/collaborators https://github.com/orgs/nodejs/teams/collaborators
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub
#6002Reacted by Robert Jefe Lindstädt, Yusuf Ali, Rui Marinho, Florian Wendelborn, Anna Henningsen, Sakthipriyan Vairamani, Christian Vaagland Tellnes, Alexander Makarenko, Yuval Brik and gbarthos@Fishrock123 when you do these merges do the commits end up rebased and at the top of the tree
@thealphanerd Hmm, let's find out.
https://github.com/Fishrock123/node/commits/test-new-github-merge- added a commit that references this issue
on Apr 1, 2016 @thealphanerd Yes, yes it does.
omg
It's definitely an improvement. I can imagine that if we enable this we'll have to keep a close eye on making sure that the commit metadata is still being added correctly to the commits. It also appears that this does not present the option of selecting which commits get squashed (we regularly end up with a few PRs whose commits should NOT be squashed on landing). This is certainly a step in the right direction but I'm not certain it's exactly what we need.
I will say, however, that turning off the merge commit option gets a huge hooray! from me.
That's sucky... they finally do what we want, almost then mess it up? It actually squashes, so your nice PR that carefully introduces a set of changes as incremental commits gets squashed into one.... and some devs crappy PR that is full of little commits with useless names also gets squashed into one with a bullet list of all the crappy commit messages? Just a tick box for "no merge commit for PRs" would have been handy, as a project wide setting. That it does an implicit rebase is pretty cool, though. But again, I wish I could make all PRs on my projects do the implicit rebase, AND leave the merge commit (not for node, of course).
It will work for at least some portion of our commits by the looks of it.
Notable exceptions being: PRs with more than one commit, and those we need to amend nits on.
It'd be awesome of we could get a markdown template for the message box, but this is great incremental step.
It doesn't allow amending the commit metadata,
Reviewed-By: ..., so it only works if you pre-prepare the branch to have a commit with that info. And if you are at the CLI because you just did that... why not just do an additionalgit merge; git push, @Fishrock123 ?As @Fishrock123 says, it is at least a step in the right direction, just not sure how often we'd be able to use it.
Maybe its a step on a good path, possibly there will be no more steps after this. Though it is a sign that some devs are getting what they ask for, and that is good.
@sam-github huh? what you fill into the merge box goes in the commit description and message, no?
2 remaining items
@cjihrig I'd say go for it.
Hmmm, it has no way of checking that, does it?
GitHub's desktop GUI checks the message length and auto-wraps the description.
Happy that it worked but definitely concerned that this will make it easier to overlook those kinds of errors. We'd have to make sure that all collaborators landing commits were disciplined in double checking the log.
Wouldn't squashing lead to loss of data?
@drgroot ... that depends on what gets squashed. We already as a common practice squash minor commits when landing PRs in order to keep the commit history fairly sane. However, quite often we will logically separate multiple commits in a single PR. It really depends on the individual PR. In this case, using the green button to squash ALL commits all the time is going to be problematic because it does not give us enough control.
Hmmm, it has no way of checking that, does it?
@Fishrock123 that was my own stupidity. It was originally wrapped like I had it in my local editor. When it available for me to edit, it had extra lines between all of the lines. When I was removing the extra lines, I unwrapped that line.
@thealphanerd That hasn't happened to me?
I'll run a couple tests, I might have done something wrong. But it is a possible edge case to be aware of
So, where is this issue supposed to lead? Are we updating documentation to reflect that we would be ok with github-squashed commits?
Hmm, I'm not sure. We unfortunately still need to prefer the old merging for many issues.
@nodejs/ctc should we update the documentation to say this using the github button is ok under simple circumstances?
I'd say don't document it. If someone can use the button without anyone noticing, then more power to them. Otherwise, just stick to the directions.
Yeah, I agree for now. Closing, can reopen if necessary.
GitHub has a new merge button feature, allowing it do a "squash-merge". See: https://github.com/blog/2141-squash-your-commits
I've done a little test [1], [2], and it appears to do what we want. No merge commit.
🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉
I have disabled the old-style merge button use on the core repo here already. We should double check and make sure this meets our merge standards before using the new option though.
@nodejs/collaborators