This is great! But what about fixups? I often prefer a fixup to a squash when the commit in question was a WIP or something, and I don't have any desire to preserve the message in the final commit.
Squash your commits
11–20 of 350 posts
Re: Squash your commits
#12Perhaps I'm greedy, but I'd like also an additional option to rebase without squashing ...
Also, it's not clear if it is possible to disable the merge button completely. I prefer to use the command line to rebase and fix the details in the commits, but the big green "merge" button is always too tempting and it's easy to press it by mistake.
Re: Squash your commits
#13I mentioned this in a tweet[0] but we have a quasi-tradition of shipping on April 1st: * https://github.com/blog/1815-l-is-for-labels * https://github.com/blog/1451-branch-and-tag-labels-for-commi... * https://github.com/blog/626-announcing-svn-support [0]: https://twitter.com/gjtorikian/status/715972348860633088
The first time we announced svn support, it WAS a joke: https://github.com/blog/31-back-to-subversion
Re: Squash your commits
#14Re: Squash your commits
#15Nice to see Github catching up to Gitlab[1]
[1]: http://feedback.gitlab.com/forums/176466-deprecated-feedback...
Re: Squash your commits
#16Any plans to allow for squashing but with a merge instead of a fast-forward or fast-forwards without squashing?
CI will still run against the hypothetical merge commit, no? I wonder if there are edge cases where merge vs squash+fast-forward would result in different conflict resolutions and different trees, so master could end up with a tree that didn't have tests run against it.
Re: Squash your commits
#17This is a bad idea masquerading as a good idea. Before making a pull request (or doing any sort of merge), you should rebase against upstream master (or whatever you're going to push to). However, keeping distinct atomic commits that change one and only one small thing, when possible, is much preferable if bisect or blame is used. If you have broken or poorly written commits, use fixup, reword, squash, etc. in rebase…
I used to feel the same way (and still do to some degree). However I think the issue is more nuanced. I agree that rebasing beforehand is a good idea. But I can see the value in keeping commits on the master branch corresponding to specific features or bug fixes (which presumably map to PRs).
I think the argument can be made that if you don't feel comfortable performing a squashed merge of a PR, then that PR contains too much work and should be split up. However, I don't think there's an easy rule to decide in either case.
Re: Squash your commits
#18This is a bad idea masquerading as a good idea. Before making a pull request (or doing any sort of merge), you should rebase against upstream master (or whatever you're going to push to). However, keeping distinct atomic commits that change one and only one small thing, when possible, is much preferable if bisect or blame is used. If you have broken or poorly written commits, use fixup, reword, squash, etc. in rebase…
I used to feel the same way (and still do to some degree). However I think the issue is more nuanced. I agree that rebasing beforehand is a good idea. But I can see the value in keeping commits on the master branch corresponding to specific features or bug fixes (which presumably map to PRs). I think the argument can be made that if you don't feel comfortable performing a squashed merge of a PR, then that PR contains…
Small PRs are an issue because PRs are dependent on other users and can't be dependent on a prior PR.
Let's say we're adding an interface/typeclass/protocol and a concrete implementation. I'd say these should be two separate commits, as they're adding two different things. An interface doesn't require a provided implementation to work. But, if we were to create those as two separate pull requests, it would be more work for the project maintainers, and the initiator wouldn't be able to create the PR for the concrete implementation until the interface PR was merged - the concrete PR can't be added as a dependent PR of the interface one, or something to that effect.
Since you can "compare" almost anything on Github, small commits aren't really an issue, just view a larger-scope comparison to get an idea of the whole PR.
Another way to put this might be that commits are for individual code changes that build up to a pull request, which is a conceptual change?
Re: Squash your commits
#19Nice to see Github catching up to Gitlab[1] [1]: http://feedback.gitlab.com/forums/176466-deprecated-feedback...
For sure! Good thing we have some great stuff in the pipeline https://about.gitlab.com/direction/ :)
Re: Squash your commits
#20Earlier quoted context omitted.
I used to feel the same way (and still do to some degree). However I think the issue is more nuanced. I agree that rebasing beforehand is a good idea. But I can see the value in keeping commits on the master branch corresponding to specific features or bug fixes (which presumably map to PRs). I think the argument can be made that if you don't feel comfortable performing a squashed merge of a PR, then that PR contains…
Small PRs are an issue because PRs are dependent on other users and can't be dependent on a prior PR. Let's say we're adding an interface/typeclass/protocol and a concrete implementation. I'd say these should be two separate commits, as they're adding two different things. An interface doesn't require a provided implementation to work. But, if we were to create those as two separate pull requests, it would be more wo…
How does not squashing your commits help the protocol/implementation scenario you described?