21 ms·

Squash your commits

702 points by WillAbides 11y ago

spleeyah 11y ago
Unsure if April Fool's joke...
- ianleeclark 11y ago
  I'd cry.
  - moby 11y ago
    Not a joke. Squash away. :)
    - whataboutff 11y ago
      This is wonderful! How about a third option to fast forward if applicable?
- joshmanders 11y ago
  Would be the worst April Fools joke ever. Even above "drop mic" by Google.
  - trollingineeer 11y ago
    Drop mic wasn't bad. People are just stupid. And you're a sheep for just going along with the "it's the worst prank" train. Start thinking for yourself Joshie.
- mchahn 11y ago
  It would be the most boring April Fools joke of the day. As a real thing I find it quite useful.
- alanh 11y ago
  Confirmed as not a joke. (The change is subtle as you have to click the green Merge button before being presented with the ability to choose a merge type via a combo button/dropdown component.)
ianleeclark 11y ago
This is a feature I've wanted for such a long time. While it's perfectly feasible to do through the command line, I've always found myself having to force push to update the history on github's side of things. I typically did it through git rebase -i HEAD~N, so maybe someone here on HN knows of a better way to squash a commit whenever you're updating remote history. Albeit, it seems that updating remote history with a squashed commit isn't entirely attractive behavior and that's why I was forced to force push.
- klodolph 11y ago
  Two things you can do differently, if you feel this would be appropriate. Instead of git rebase -i HEAD~N, I typically use git reset --soft HEAD~N followed by git commit. Instead of git push --force, use git push --force-with-lease. This only updates the remote if the remote's current state is what you expect. For example, it will fail if someone else has pushed to the same branch in the meantime.
- azernik 11y ago
  Usually I'll do git rebase -i origin/master (or upstream/master, or wherever in branched off of on the first place). Doesn't require me to count up to N commits, and also does an actual rebase. But yeah, force push is kind of inherent to the process - you're rewriting history, no two ways about it. Usually for my own forks of projects, though, I'll go into .git/config and add a 'push' option with a + in front of the refspec - this enables force pushing always. This really only works and is safe for workflows where there's a distinction between your own personal GitHub account and the upstream that has the authoritative copy - you really don't want to rewrite history by accident on the latter.
cthulhujr 11y ago
I could see this replacing the git workflow of creating a temporary branch that's used just for merging pre-master.
gjtorikian 11y ago
I 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/1815-l-is-for-labels * https://github.com/blog/1451-branch-and-tag-labels-for-commit-pages https://github.com/blog/1451-branch-and-tag-labels-for-commi... * https://github.com/blog/626-announcing-svn-support https://github.com/blog/626-announcing-svn-support [0]: https://twitter.com/gjtorikian/status/715972348860633088 https://twitter.com/gjtorikian/status/715972348860633088
- technoweenie 11y ago
  The first time we announced svn support, it WAS a joke: https://github.com/blog/31-back-to-subversion https://github.com/blog/31-back-to-subversion
- kylehotchkiss 11y ago
  I loved this feature too, but thought it was a joke at first!
cballard 11y ago
This 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. Using fast-forward (and possibly only allowing fast-forward) is a good idea. Squashing entire pull requests that may change multiple things into a single commit is a very bad idea.
- michaelmior 11y ago
  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.
  - cballard 11y ago
    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?
    - 11y ago
MaxfordAndSons 11y ago
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.
gus_massa 11y ago
Perhaps 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.
- jakub_g 11y ago
  This is a huge issue for me both with GitHub and Atlassian Stash. On both you even cannot see when the branch was started, and you can merge fine as long as there were no merge issues. Then you run gitk and it looks like a spaghetti-horror, with trivial branches being started 200 commits ago. I don't necessarily need a "rebase&merge" button but at least info about the shared ancestor with master.
- codingWithGit 11y ago
  you can always do this in the command line locally.
Afforess 11y ago
Nice to see Github catching up to Gitlab[1] [1]: http://feedback.gitlab.com/forums/176466-deprecated-feedback-forum/suggestions/4289653-rebase-merge-requests-in-the-web-ui http://feedback.gitlab.com/forums/176466-deprecated-feedback...
- sytse 11y ago
  For sure! Good thing we have some great stuff in the pipeline https://about.gitlab.com/direction/ https://about.gitlab.com/direction/ :)
lotyrin 11y ago
Any 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.
- dlubarov 11y ago
  > master could end up with a tree that didn't have tests run against it Isn't that already the norm? I.e., most projects run CI on an unmerged PR, then merge to master, then run CI on master to see if the merged tree is actually good. Are there projects which test a PR's post-merge tree before updating master? That would be nice, but I don't know of any tools which support that workflow, and it wouldn't scale forever since it would involve a serial merge queue.
  - hkdobrev 11y ago
    Travis CI for example and I'd imagine most CI servers run tests on the `MERGE_HEAD` of the PR which like lotyrin said is the hypothetical merge commit. If a PR is opened from latest master, CI runs on `MERGE_HEAD` which is the same with the merge commit after the PR is merged. But if something was pushed to master after the feature branch was branched off then it's not the same commit. That's why it's recommended to run CI after merging again. But by default tests are not run on the PR HEAD which is the tip of the feature branch.
jecjec 11y ago
Git is actually unusable software. Fucking around with rebase WILL cause you more headaches than this is worth. The number of downvotes this has received tells me just how deluded the alleged community of software writers actually is.
- falsedan 11y ago
  Fucking around with anything will do that. Learning and understanding a new tool & using it where it's appropriate will save you time and effort!
  - ams6110 11y ago
    The problem is, are we developers or source code librarians? My git workflow is pull, commit, push. I don't rebase or branch or anything else because it completely distracts me from what I'm doing as a developer. YMMV.
    - falsedan 11y ago
      > The problem is, are we developers or source code librarians? I don't understand the connection, developers can use tools which require learning/training and are free to not use those tools?
    - mcguire 11y ago
      "* The problem is, are we developers or source code librarians?*" One might, perhaps, be forgiven for thinking a professional would be interested in both. Are there any other things you consider outside your job description?
- dsmithatx 11y ago
  Strange that everyone these days uses Git considering it's unusable.
  - overgard 11y ago
    Everyone is a bit of a stretch -- the OP might have been a bit insulting; but he has a point.. hacker news can be somewhat of an echo chamber, and I think people assume Git is (or should be) a lot more widespread than it actually is. A lot of large companies still use perforce for large repository support, a lot of people still use subversion because it's simpler and they don't need a DVCS, etc. Having been the "git guy" at a lot of places, I can definitely tell you that you can't just hand-wave away its usability problems, it definitely has a cost on peoples' time that other systems don't. (I rarely have to answer other peoples questions about P4, for instance)
MBlume 11y ago
If everyone on your team actually knows how to use git, much better to let them rebase their commits and mark out a series of clean, atomic commits which introduce the feature you're reviewing. If you have people who are incompetent at using git on your team, this feature will help protect your history from them.
- munificent 11y ago
  > incompetent at using git This unfairly places the blame for Git's utterly shitty UX on the part of the users. When you have thousands of users who struggle to use a tool correctly, it's the tool's fault, not theirs. I've been using Git for years, work professionally full time on an open source project that lives on GitHub, maintain several open source projects with a number of committers and generally live and breath Git and GitHub all day. I still fucking hate rebasing and get tripped up by it on the few times I end up having to deal with it.
  - jecjec 11y ago
    It is incredible to me to see how many people in this industry will sit here and defend an agonizingly terrible tool. Total Stockholm Syndrome.
    - Grishnakh 11y ago
      The problem is that the tool is both great and terrible. It's basically like a Formula-1 car: ultimate performance, but with huge potential for disaster in the hands of someone who doesn't know what they're doing. It doesn't help that the tool has been growing organically over time, leading to a really confusing UI. Also, it's extremely versatile, but that's both a blessing and a curse, as people can develop totally different and incompatible workflows. Maybe people need to create some command-line front-ends to git which force users into particular workflows and subsets of the commands, and which clean up the UI, much like how almost no one uses TeX, but instead they use front-ends like LaTeX.
    - icebraining 11y ago
cfontes 11y ago
Wow, loved this. I contributed a little to JUnit and they ask you to squash your commits before making a pull, it took some time to do it, it's so confusing/wierd using regular GIT.
simplify 11y ago
This is great, but I was really hoping for a fast-forward-only merge button...
- kevincox 11y ago
  I think you can fake this by enabling "Require CI" and not selecting any required CI branches.
LegNeato 11y ago
Awesome! Phabricator got me addicted to the clean history of squashing commits and the logical changes staying together in source control (as opposed to grouping in a PR).
pkamb 11y ago
I'm waiting for the code review tool that takes a massive squashed PR and cuts it up into a series of clean, atomic commits that can be reviewed individually.
- neandrake 11y ago
  I believe Phabricator supports this workflow. Create a revision for a code change - as more commits are made, update the revision with those changes. Users can see what changes were made between commits and hold discussions on them. When it's ready, landing can (optionally) squash the diffs into a single commit upstream. The main history will be linear and more-complete changes, while detail about the development of the change is retained in Phabricator revision. https://phacility.com/phabricator/differential/ https://phacility.com/phabricator/differential/
Pxtl 11y ago
This is a presentation issue masquerading as a data issue. If somebody suggested deleting data because a report was ugly, they'd be laughed out of the room. Give us tools to mark commits as unimportant or group them together as a meta-commit object for history purposes.
- codingWithGit 11y ago
  This is good insight. makes a lot more sense. I think this will take care of 99% of use cases for sqqshing/rebasing. However, I think this is something that will have to be built into git itself, not by Github.
- jgraham 11y ago
  So that's essentially what mercurial's evolve extension does. Which is pretty useful in some circumstances, e.g. if you have a review tool where you want to support rewriting history in a nice way (the typical approach to this in git tools is either a) don't meaningful support history rewriting, b) require manual ceremony for each history rewrite, or c) add unique ids to each immutable-across-rewrites commit). Whilst it's clear that retaining the pushed history can be useful in some cases, I don't understand the notion that disallowing history rewrites helps retain useful data in general. Developers can make commits for all kinds of arbitary reasons e.g. they reached the end of the day, or had to switch branches to work on a different patch. That doesn't seem like a particularly useful thing to record. To take it to an extreme, I wonder if any of the people who think that the precise commit history gives useful information about how a feature was developed have configured their editor to commit on keystroke, since that seems like the logical conclusion of that position (and indeed is effectively what tools like etherpad do). I suspect not because, actually, being selective about the information that you keep is rather helpful. During rebase we see the developer as curator, selecting the most useful representation of a set of changes for the benefit of future readers. or, to use your analogy, if someone suggested removing meaningless data from a report to focus attention on the most important points, then they would certainly not be laughed at, but praised. Of course GitHub's implementation is too blunt a tool to be really useful, but hopefully we will eventually get something better.
- tedmiston 11y ago
exratione 11y ago
Equally, https://github.com/git-land/git-land https://github.com/git-land/git-land "This is a git extension that merges a pull request or topic branch via rebasing so as to avoid a merge commit."
pkamb 11y ago
After completing a feature (or part of one) I often "squash" manually by performing a mixed reset from the tip of the in-development branch back to a good parent commit. This leaves all of the feature's changes in your working copy, which you can then stage by line/hunk and individually commit in clean, atomic pieces with the benefit of already having written the final code. This removes the in-progress commits like a Squash, but pieces of code can still be brought in as individual easy-to-review commits. And it's potentially easier to understand / perform manually than rewriting history via a git command that would do the same thing.
gonyea 11y ago
I hate squashing branches. There's a lot of value in commit messages; they're educational and are a form of documentation. It's on the developer to squash the "oops" commits, during a rebase, rewriting the commit message so it has some value when going back in time to look at changes. I'd love to see a commit linter, that points at commits with text like "oops" and "fix my derp" to suggest possible commits to squash. Git history shouldn't resemble a hot mess, but the evolution of code should be pretty granular. I'd take the hot mess over full squashing, though.
- codingWithGit 11y ago
  If I feel like the history of a branch is important, I add a git tag to the branch head before rebasing. I have a naming convention for these tags. Then I usually do a rebase -i on to the main branch.
- reledi 11y ago
  Commits to squash can start with [squash] and when you rebase they are automatically squashed.
WorldMaker 11y ago
Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that. It's real and visceral and how software is actually made and you can learn from that or find things to explore in that jungle. Projects with multiple developers that yet have straight line commit histories and super tidy commits are aberrations and full of little lies... Kudos to GitHub for providing this feature that a lot of people have asked for. I obviously don't plan to use it, but I appreciate that it's an option for those people that like their small, harmless lies. ;)
- kylnew 11y ago
  Have you ever tried following a change in a repo that came from an unsquashed PR? It's hell. What's truly meaningful IMO is a git log that reads like a product change log
  - WorldMaker 11y ago
    «Have you ever tried following a change in a repo that came from an unsquashed PR?» I have a self-congratulating black belt in source code archeology. With the right tools, most of which are on GitHub, even, such as good commit range diffing, smart uses of tags and branches, and knowing how to navigate the DAG from merge commits (more reason to -no-ff) you have a lot of power in your hands. «What's truly meaningful IMO is a git log that reads like a product change log» I appreciate that point of view, but I don't share it. A product change log, I feel, is a bit of marketing/PR that needs some time, love, and editing; I find a git log is for catching snapshots of raw progress and more often useful in seeing what your co-developers are up to, as they are working.
    - kylnew 11y ago
      I think this really comes down to team. It's kind of an all-in or nothing thing and if you go against the grain everyone will just end up angry
golergka 11y ago
This, as rebase, is a great idea for people who would rather use SVN instead, but have to use git for some reason or another. I mean, if you want your history simplified into a linear squashed series of commits, why the hell do you use VCS which models a history as acyclic directional graph in the first place?
devit 11y ago
The key principle is that the software should always correctly work at any point in the chain of commits, so you must squash commits that are "oops, fix X in previous commit". Once that is satisfied, commits should be as small as possible, so that information about the grouping of changes is preserved.
- chmaynard 11y ago
  This advice seems very sensible. Thanks for adding some valuable ideas to the discussion. I'm now reading the git documentation on re-writing history: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
eblanshey 11y ago
Usually when squashing branches locally, all the changes are set to myself as the author, effectively losing history of who did what in the feature branch. How does Github handle this? Additionally, the lack of the commit history for that branch often caused merged conflicts when merging the same branch again (if it had additional new fixes, for example). That's why I switched to using git merge --no-ff. If it were very easy to do, I would definitely do a git squash, as it keeps history very clean. I just don't want to have the problems listed above.
educar 11y ago
A bit OT but a feature I would love to see in git is to be able to see which branch a commit came from. Especially for shortlived branches which we prune periodically on the server (git branch -r --contains won't work as a result)
totally 11y ago
Wait, this isn't new.
kazinator 11y ago
Squashing is not an alternative to merge workflow. It's what you do to clean up before you integrate your work (whether by rebase or merge). You've just made seven changes, which should just be three: git rebase -i HEAD~7, squash away. Okay, now you have three. rebase them on top of new work in the upstream branch, or merge? Separate question.
hvmonk 11y ago
This is such a nice feature. Thank you for working on it. Keeping history clean is important, especially in enterprise solution where you have to keep support multiple releases. You want to select certain commits/features in one version. With merge/squash, you would get a cleaner history, and it is easy to pick commits you want.
justin_vanw 11y ago
No, don't squash your commits. This is stupid advice that comes back over and over. Squashing commits is a useless thing that has absolutely no benefit. It's dumb. It really makes no sense. It has very clear negatives. https://news.ycombinator.com/item?id=5631184 https://news.ycombinator.com/item?id=5631184
- andrewprock 11y ago
  If you are using git as a distributed version control system, squashing makes complete sense. If you are using it in a master/slave sense, and are not allowed to commit locally, then yes, squashing doesn't make any sense.
overgard 11y ago
Maybe I'm missing something, but I've never understood the point of cleaning up commit history. The only time I ever look at commit history past a few days is if I want to know when something broke (in which case I WANT every part of the history, even the messy bits), or if I'm trying to refresh my memory of what I've done for the year (for performance reviews or whatever) in which case I guess it's marginally useful, but it's pretty easy to skim over "fix build" and such.
macrael 11y ago
Do any VCSs have a notion of a commit of commits? If you could group a series of sequential commits into one commit on trunk it seems like you could have the best of both worlds: an overarching commit for your change and a series of how the sausage got made.
- tedmiston 11y ago
  Sure, a merge commit. git checkout master git merge --no-ff feature-branch
liquidise 11y ago
Oh god no. I made the mistake of moving a team to squashed commits once. The lack of individual commits poses large problems down the line. 2 nonstarters come to mind: 1: Completely ruin your ability to git bisect any bug injected in your branch. Instead of getting a 10 line commit, bisect will point you to hundreds or thousands of lines instead. 2: All code will blame to a single person. Code with 6 people on a large branch? Want to git blame the code to see who wrote the function that is weird looking so you can ask questions? Too bad. Do not squash branches on teams. One of the biggest mistakes of my professional career.
- dsymonds 11y ago
  This is for a "pull request", namely an individual logical change. Your two points don't apply. If you're dealing with whole branches with multiple developers, stick with merging, but this isn't that.
- exDM69 11y ago
  Your experience sounds horrible, but you were clearly doing something very stupid. Squashing is a tool to use with discretion. You squash two or three 5 line wip commits together. And I'd never squash changes from two authors (except perhaps whitespace or comment fixes).
- shados 11y ago
  point 1: merge smaller features more often. Multi-thousand line PRs suck no matter if they're squashed or not. point 2: As people mentioned, this is for PRs done by individual people, usually squashing their local history. If multiple people were working on the branch, they should have been PR-ing against that branch (squashing the commits), then you merge that branch to master (you may rebase it, but not do significantly destructive stuff). Even then, these are features to use with critical thinking. If your PR is really large, massage the history to be relevant and meaningful for git bisect purpose. Use full squashing when it was a local work full of "My hands are typing words" commits of no relevance. I swear, we're in an industry full of people making 6 figure salaries, who treat their job as if it was a call center script to follow. If you're an engineer, use your head and engineer solutions around the tools you have.
nullc 11y ago
Annoying: you can't turn off both. If your project has a workflow where the webui merge should not be used (e.g. using signed merges) there is still no way to achieve that.
deleted 11y ago
[deleted]
tomphoolery 11y ago
Can't wait to see this feature replicated poorly in about 6 months in Atlassian Stash (Bitbucket)!
- kannonboy 11y ago
  Actually Bitbucket Server (née Stash) already supports squashing and a variety of other pull request merge strategies. They're just configured[0] per repository, project or globally rather than an explicit option at merge time. [0]: https://confluence.atlassian.com/bitbucketserver/bitbucket-server-config-properties-776640155.html#BitbucketServerconfigproperties-Pullrequests https://confluence.atlassian.com/bitbucketserver/bitbucket-s...
hinkley 11y ago
It seems to me that the scope of this article is pretty narrow (in a good let's avoid a flame war way). And it describes one of the few scenarios where I think squashes are beneficial. But then the conclusion doesn't quite add up. if I want to remove all the merge mess from a PR don't I actually want to rebase the PR, not merely squash the history? Or dos I miss the point he was making?
looneysquash 11y ago
I'm confused. When I don't want to see the details of the topic branches, I run 'git log --first-parent'. Why not make it easier to see what I want to see, but then let me drill down and see more, instead of removing the details all together?
abalashov 11y ago
Call me naive, but wouldn't this problem be best solved by requiring that commits represent meaningful and working increments of work? I use 'git add -p' judiciously and only commit when having reached a point where something can be usefully said to be in some way "done". Sure, it's not perfect, and occasionally I end up having to do some cleanup of miscellaneous printf statements, debug values or typoes in subsequent commits, but this is something that should really be avoided if possible.
- cortesoft 11y ago
  Waiting until you have something useful has other drawbacks. For example, it might take many hours or days to get to a 'useful' and 'done' state - I don't want to go hours or days without saving my work in a manner that is easy to retrieve if something goes wrong. Besides the obvious 'hard drive failure' or 'laptop stolen' situations, there are also more frequent situations where 'oh shit, I went down a totally wrong path there - let me back up a bit and try that again.' Git commits are little save points that let me do small experimentation and go back if I need to.
  - abalashov 11y ago
    Very good points. I guess I've just been too lazy to learn advanced rebasing / commit aggregation. Maybe I should, so I can more effectively take advantage of the upside while not polluting my commit history with intermediate crap.
lerax 11y ago
An unique thing: http://i.imgur.com/ztUufvf.jpg http://i.imgur.com/ztUufvf.jpg
cyphar 11y ago
Yeah, this is dumb. Being able to effectively bisect large projects depends on having smaller commits. If your commits are all huge, your bisect will hit some 500 line patch that does 5 different things -- it'll easily quadruple the debugging time. Not to mention that having small self-contained commits is a good thing.
DMOoO9 11y ago
no reason why developers should not be reliable for their work. if you ask me there should be a process to handing out open licenses and from what I have seen apache gives any one the right to do what they want. I would love to see stricter laws when it comes to third parties and open source licensing, including the chatter back and forth.
DMOoO9 11y ago
I believe there should be more open communication and a record the public can fall back on while these developers make their improvements. Something in their face. Too many times did I track back and see unprofessional comments being made and things being done that seemed downright suspicious. if it were up to me it would be alot harder to get a developers license and you would have to meet regulatory standards and have degrees to uphold your professionalism while acting as your own developer it seems to me that alot of developers have taken things into their own hands and are trying to make a quick buck any way they can get it. don't be surprised if you tell your mother or father or sibling to look at what licenses they have agreed to on their phones and they find alot of outdated unassigned licenses to back up their privacy. it seems to be an epidemic and how are we going to stop it?
DMOoO9 11y ago
I can't believe some of the comments I have seen made back and forth. let's shoot for a professionalism to supercede all others
DMOoO9 11y ago
I can't believe some of the comments I have seen made back and forth. let's shoot for a professionalism to supercede all others
0XAFFE 11y ago
This always reminds me of stackenblochen https://youtu.be/Qo_2ReMNzhU https://youtu.be/Qo_2ReMNzhU
losvedir 11y ago
This is great news for us as we prefer this flow. However, we actually mostly merge via our custom tool which uses GitHub's API. I can't find anything in the documentation about whether these options apply to API merges or if there's any query params that can achieve that behavior from the API. Anyone know anything about this?
chmike 11y ago
This is awfull because it destroys information. A feature branch needs cleaning up before publishing. These bug and typo fixes needs to be squashed in the branch, but the history should preserve a sequence of commits corresponding to atomic changes because it tells a story. A commit should be small enough to make it easy to check if the change is correct. It should be self contained so that it can be moved arround, cherry picked, etc. This is why the local commit history should be considered as a draft of the story, and the one published should be the official one aimed to be easily readable, verifiable and manipulable.
kinofcain 11y ago
Fantastic. Regarding non-merge workflows: For me the question is: should git history reflect a literal record of keystrokes or should it reflect intent? I strongly believe in the latter.
greg0ire 11y ago
This is wrong at so many levels. Of course we don't care about "progress" or "woops I fucked up" commits, but people also do commits for things like coding style, and these commits should be keep separated from the others, and DO NOT warrant a separate PR. If it is about changing all tabs to space in a file, for instance, different PRs will be hard to work with, because of conflicts. Also, people who write WIP commits should learn how to squash them themselves, and give them a meaningful commit message.
jondubois 11y ago
I think squashing commits makes sense if you're working in a big team and/or on a complex/large project - The main advantage of it is that it speeds up the QA process because it cleans up all the back-and-forth (exploratory) changes that tend to happen during development. If you squash properly, each commit will represent a small standalone feature. It does reduce your commit count though :(
dboreham 11y ago
As this thread approaches 300 posts I'm wondering when we're going to get out of this Git Tarpit we've somehow got ourselves into? To be charitable: Git seems to be a good tool designed for Problem A, being widely used for Problems B,C,D for which it is a fairly poor choice. I _think_ we got here through some mix of "but it's really fast!"; "I can do _anything_!!"; "But Linus says its great!"; "I don't need to pay for a beefy server any more!"; "New _must_ be good, right?". In any event, how do we get out the ditch and back to work making software vs. trying to reason about the unreasonable? I personally, for the kind of projects I'm involved with (small teams, all paid by the same piper, with aligned clear goals and competent coders), had perfectly satisfactory revision control systems since around 2000 (except when required by employer to use Clearcase..). It would be nice to get back to that future.
wandernotlost 11y ago
This obsession with "clean" history seems to me nothing short of insanity. Source control has one job: to record the history of code in order to be aid in figuring out what happened when things go wrong. If everything always went well, we'd just have great merge tools and throw away the history. I can understand a desire to filter out stages of a project by different levels of review (I just ran the build and tests passed so I committed vs a bunch of people reviewed it so I merged), but that people solve that by deleting or rewriting history to be something different from what actually happened is just nuts. Is it just that git makes it easier to change history than to add metadata for filtering? Why have we not seen presentation tools to solve this problem rather than what seems like a ubiquitous readiness to alter and throw away the messy but accurate facts about what happened?
- jedberg 11y ago
  Because the lack of squashing actually makes finding bugs harder. Which checkin with the status "change i to l" or "whoops, typo" was the bug in? It's a lot easier when an entire changeset has a single checkin into master, because then when you're doing your bisection there are a far few changes to bisect.
cm3 11y ago
The option to avoid merge commits when merging pull requests misses the point, but apparently many users demanded it for some reason, so Github implemented it. Here's how merge commits, rebasing and isolated small commits work: You branch your topic off master and make many commits while working on it. This is all local. Once you're ready to publish for review/integration, you squash fixup and backup commits into a coherent patch set, where each and every revision builds and works. This is where you can rebase and squash for good reason. Now you can push to Github. If you, like Phrabricator, create a single big commit with all changes lumped together, then it's impossible to bisect and follow the thought process behind changes. Try to git-bisect linux.git vs a repo that's been managed with Phabricator and its mega commits. With small commits that each make one coherent change, you can easily include relevant explanations in the commit message, which is much harder to achieve with a single mega commit. Further, it's very simple to follow along the development process of changes with separate commits. If you have one big diff, it's hard to understand the changes of a branch, whereas reviewing small commits with an explanation in the message and the overall reduction in diff size makes it much, much easier to understand for reviewers. With separate small commits you review each step and finally arrive at the complete feature implementation at the end. For someone who has to review code they didn't write this saves a huge amount of valuable reviewer time for actual reviewing than trying to reverse engineer the steps taken in a big diff. Moreover, with multiple commits, you can easily approve of some of the commits, while requesting improvements for others. Gerrit implements this well and the process is what linux and git and other projects use when reviewing big patch sets. Set is the important word. Finally, why do you want merge commits? Unless you always make a single mega commit ala Phabricator or the new Github feature, having merge commits provides a very practical way to see that a set of commits landed via foo-branch-X. If you've ever viewed a git log graph, that's the interesting integration points, which you will lose if you omit merge commits. In a merge commit you can also include extra stuff as part of the merge commit itself, so it's not just useless metadata.
dclowd9901 11y ago
Rarely do conversations around these parts get as heated as they do when git process comes up. As I read through these comments, only one thing surfaces: everybody organizes their shit differently. If you're here trying to sell your process, why?
mikebannister 11y ago
I personally like this and it fits well with my team's workflow (though I am a bit concerned it will prevent engineers from learning to do these things with git). There are pros and cons for sure but I think if you are losing a lot of resolution by squashing then the scope of your pull requests might be too big in the first place.
mck- 11y ago
Added benefit of this would be that it is easier to git revert a merge from cli

Squash your commits

702 points by WillAbides 11y ago

spleeyah 11y ago

Unsure if April Fool's joke...

ianleeclark 11y ago
I'd cry.
- moby 11y ago
  Not a joke. Squash away. :)
  - whataboutff 11y ago
    This is wonderful! How about a third option to fast forward if applicable?
joshmanders 11y ago
Would be the worst April Fools joke ever. Even above "drop mic" by Google.
- trollingineeer 11y ago
  Drop mic wasn't bad. People are just stupid. And you're a sheep for just going along with the "it's the worst prank" train. Start thinking for yourself Joshie.
mchahn 11y ago
It would be the most boring April Fools joke of the day. As a real thing I find it quite useful.
alanh 11y ago
Confirmed as not a joke. (The change is subtle as you have to click the green Merge button before being presented with the ability to choose a merge type via a combo button/dropdown component.)

ianleeclark 11y ago

This is a feature I've wanted for such a long time. While it's perfectly feasible to do through the command line, I've always found myself having to force push to update the history on github's side of things. I typically did it through git rebase -i HEAD~N, so maybe someone here on HN knows of a better way to squash a commit whenever you're updating remote history. Albeit, it seems that updating remote history with a squashed commit isn't entirely attractive behavior and that's why I was forced to force push.

klodolph 11y ago
Two things you can do differently, if you feel this would be appropriate. Instead of git rebase -i HEAD~N, I typically use git reset --soft HEAD~N followed by git commit. Instead of git push --force, use git push --force-with-lease. This only updates the remote if the remote's current state is what you expect. For example, it will fail if someone else has pushed to the same branch in the meantime.
azernik 11y ago
Usually I'll do git rebase -i origin/master (or upstream/master, or wherever in branched off of on the first place). Doesn't require me to count up to N commits, and also does an actual rebase. But yeah, force push is kind of inherent to the process - you're rewriting history, no two ways about it. Usually for my own forks of projects, though, I'll go into .git/config and add a 'push' option with a + in front of the refspec - this enables force pushing always. This really only works and is safe for workflows where there's a distinction between your own personal GitHub account and the upstream that has the authoritative copy - you really don't want to rewrite history by accident on the latter.

cthulhujr 11y ago

I could see this replacing the git workflow of creating a temporary branch that's used just for merging pre-master.

gjtorikian 11y ago

I 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/1815-l-is-for-labels * https://github.com/blog/1451-branch-and-tag-labels-for-commit-pages https://github.com/blog/1451-branch-and-tag-labels-for-commi... * https://github.com/blog/626-announcing-svn-support https://github.com/blog/626-announcing-svn-support [0]: https://twitter.com/gjtorikian/status/715972348860633088 https://twitter.com/gjtorikian/status/715972348860633088

technoweenie 11y ago
The first time we announced svn support, it WAS a joke: https://github.com/blog/31-back-to-subversion https://github.com/blog/31-back-to-subversion
kylehotchkiss 11y ago
I loved this feature too, but thought it was a joke at first!

cballard 11y ago

This 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. Using fast-forward (and possibly only allowing fast-forward) is a good idea. Squashing entire pull requests that may change multiple things into a single commit is a very bad idea.

michaelmior 11y ago
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.
- cballard 11y ago
  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?
  - 11y ago

MaxfordAndSons 11y ago

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.

gus_massa 11y ago

Perhaps 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.

jakub_g 11y ago
This is a huge issue for me both with GitHub and Atlassian Stash. On both you even cannot see when the branch was started, and you can merge fine as long as there were no merge issues. Then you run gitk and it looks like a spaghetti-horror, with trivial branches being started 200 commits ago. I don't necessarily need a "rebase&merge" button but at least info about the shared ancestor with master.
codingWithGit 11y ago
you can always do this in the command line locally.

Afforess 11y ago

Nice to see Github catching up to Gitlab[1] [1]: http://feedback.gitlab.com/forums/176466-deprecated-feedback-forum/suggestions/4289653-rebase-merge-requests-in-the-web-ui http://feedback.gitlab.com/forums/176466-deprecated-feedback...

sytse 11y ago
For sure! Good thing we have some great stuff in the pipeline https://about.gitlab.com/direction/ https://about.gitlab.com/direction/ :)

lotyrin 11y ago

Any 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.

dlubarov 11y ago
> master could end up with a tree that didn't have tests run against it Isn't that already the norm? I.e., most projects run CI on an unmerged PR, then merge to master, then run CI on master to see if the merged tree is actually good. Are there projects which test a PR's post-merge tree before updating master? That would be nice, but I don't know of any tools which support that workflow, and it wouldn't scale forever since it would involve a serial merge queue.
- hkdobrev 11y ago
  Travis CI for example and I'd imagine most CI servers run tests on the `MERGE_HEAD` of the PR which like lotyrin said is the hypothetical merge commit. If a PR is opened from latest master, CI runs on `MERGE_HEAD` which is the same with the merge commit after the PR is merged. But if something was pushed to master after the feature branch was branched off then it's not the same commit. That's why it's recommended to run CI after merging again. But by default tests are not run on the PR HEAD which is the tip of the feature branch.

jecjec 11y ago

Git is actually unusable software. Fucking around with rebase WILL cause you more headaches than this is worth. The number of downvotes this has received tells me just how deluded the alleged community of software writers actually is.

falsedan 11y ago
Fucking around with anything will do that. Learning and understanding a new tool & using it where it's appropriate will save you time and effort!
- ams6110 11y ago
  The problem is, are we developers or source code librarians? My git workflow is pull, commit, push. I don't rebase or branch or anything else because it completely distracts me from what I'm doing as a developer. YMMV.
  - falsedan 11y ago
    > The problem is, are we developers or source code librarians? I don't understand the connection, developers can use tools which require learning/training and are free to not use those tools?
  - mcguire 11y ago
    "* The problem is, are we developers or source code librarians?*" One might, perhaps, be forgiven for thinking a professional would be interested in both. Are there any other things you consider outside your job description?
dsmithatx 11y ago
Strange that everyone these days uses Git considering it's unusable.
- overgard 11y ago
  Everyone is a bit of a stretch -- the OP might have been a bit insulting; but he has a point.. hacker news can be somewhat of an echo chamber, and I think people assume Git is (or should be) a lot more widespread than it actually is. A lot of large companies still use perforce for large repository support, a lot of people still use subversion because it's simpler and they don't need a DVCS, etc. Having been the "git guy" at a lot of places, I can definitely tell you that you can't just hand-wave away its usability problems, it definitely has a cost on peoples' time that other systems don't. (I rarely have to answer other peoples questions about P4, for instance)

MBlume 11y ago

If everyone on your team actually knows how to use git, much better to let them rebase their commits and mark out a series of clean, atomic commits which introduce the feature you're reviewing. If you have people who are incompetent at using git on your team, this feature will help protect your history from them.

munificent 11y ago
> incompetent at using git This unfairly places the blame for Git's utterly shitty UX on the part of the users. When you have thousands of users who struggle to use a tool correctly, it's the tool's fault, not theirs. I've been using Git for years, work professionally full time on an open source project that lives on GitHub, maintain several open source projects with a number of committers and generally live and breath Git and GitHub all day. I still fucking hate rebasing and get tripped up by it on the few times I end up having to deal with it.
- jecjec 11y ago
  It is incredible to me to see how many people in this industry will sit here and defend an agonizingly terrible tool. Total Stockholm Syndrome.
  - Grishnakh 11y ago
    The problem is that the tool is both great and terrible. It's basically like a Formula-1 car: ultimate performance, but with huge potential for disaster in the hands of someone who doesn't know what they're doing. It doesn't help that the tool has been growing organically over time, leading to a really confusing UI. Also, it's extremely versatile, but that's both a blessing and a curse, as people can develop totally different and incompatible workflows. Maybe people need to create some command-line front-ends to git which force users into particular workflows and subsets of the commands, and which clean up the UI, much like how almost no one uses TeX, but instead they use front-ends like LaTeX.
  - icebraining 11y ago

cfontes 11y ago

Wow, loved this. I contributed a little to JUnit and they ask you to squash your commits before making a pull, it took some time to do it, it's so confusing/wierd using regular GIT.

simplify 11y ago

This is great, but I was really hoping for a fast-forward-only merge button...

kevincox 11y ago
I think you can fake this by enabling "Require CI" and not selecting any required CI branches.

LegNeato 11y ago

Awesome! Phabricator got me addicted to the clean history of squashing commits and the logical changes staying together in source control (as opposed to grouping in a PR).

pkamb 11y ago

I'm waiting for the code review tool that takes a massive squashed PR and cuts it up into a series of clean, atomic commits that can be reviewed individually.

neandrake 11y ago
I believe Phabricator supports this workflow. Create a revision for a code change - as more commits are made, update the revision with those changes. Users can see what changes were made between commits and hold discussions on them. When it's ready, landing can (optionally) squash the diffs into a single commit upstream. The main history will be linear and more-complete changes, while detail about the development of the change is retained in Phabricator revision. https://phacility.com/phabricator/differential/ https://phacility.com/phabricator/differential/

Pxtl 11y ago

This is a presentation issue masquerading as a data issue. If somebody suggested deleting data because a report was ugly, they'd be laughed out of the room. Give us tools to mark commits as unimportant or group them together as a meta-commit object for history purposes.

codingWithGit 11y ago
This is good insight. makes a lot more sense. I think this will take care of 99% of use cases for sqqshing/rebasing. However, I think this is something that will have to be built into git itself, not by Github.
jgraham 11y ago
So that's essentially what mercurial's evolve extension does. Which is pretty useful in some circumstances, e.g. if you have a review tool where you want to support rewriting history in a nice way (the typical approach to this in git tools is either a) don't meaningful support history rewriting, b) require manual ceremony for each history rewrite, or c) add unique ids to each immutable-across-rewrites commit). Whilst it's clear that retaining the pushed history can be useful in some cases, I don't understand the notion that disallowing history rewrites helps retain useful data in general. Developers can make commits for all kinds of arbitary reasons e.g. they reached the end of the day, or had to switch branches to work on a different patch. That doesn't seem like a particularly useful thing to record. To take it to an extreme, I wonder if any of the people who think that the precise commit history gives useful information about how a feature was developed have configured their editor to commit on keystroke, since that seems like the logical conclusion of that position (and indeed is effectively what tools like etherpad do). I suspect not because, actually, being selective about the information that you keep is rather helpful. During rebase we see the developer as curator, selecting the most useful representation of a set of changes for the benefit of future readers. or, to use your analogy, if someone suggested removing meaningless data from a report to focus attention on the most important points, then they would certainly not be laughed at, but praised. Of course GitHub's implementation is too blunt a tool to be really useful, but hopefully we will eventually get something better.
tedmiston 11y ago

exratione 11y ago

Equally, https://github.com/git-land/git-land https://github.com/git-land/git-land "This is a git extension that merges a pull request or topic branch via rebasing so as to avoid a merge commit."

pkamb 11y ago

After completing a feature (or part of one) I often "squash" manually by performing a mixed reset from the tip of the in-development branch back to a good parent commit. This leaves all of the feature's changes in your working copy, which you can then stage by line/hunk and individually commit in clean, atomic pieces with the benefit of already having written the final code. This removes the in-progress commits like a Squash, but pieces of code can still be brought in as individual easy-to-review commits. And it's potentially easier to understand / perform manually than rewriting history via a git command that would do the same thing.

gonyea 11y ago

I hate squashing branches. There's a lot of value in commit messages; they're educational and are a form of documentation. It's on the developer to squash the "oops" commits, during a rebase, rewriting the commit message so it has some value when going back in time to look at changes. I'd love to see a commit linter, that points at commits with text like "oops" and "fix my derp" to suggest possible commits to squash. Git history shouldn't resemble a hot mess, but the evolution of code should be pretty granular. I'd take the hot mess over full squashing, though.

codingWithGit 11y ago
If I feel like the history of a branch is important, I add a git tag to the branch head before rebasing. I have a naming convention for these tags. Then I usually do a rebase -i on to the main branch.
reledi 11y ago
Commits to squash can start with [squash] and when you rebase they are automatically squashed.

WorldMaker 11y ago

Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that. It's real and visceral and how software is actually made and you can learn from that or find things to explore in that jungle. Projects with multiple developers that yet have straight line commit histories and super tidy commits are aberrations and full of little lies... Kudos to GitHub for providing this feature that a lot of people have asked for. I obviously don't plan to use it, but I appreciate that it's an option for those people that like their small, harmless lies. ;)

kylnew 11y ago
Have you ever tried following a change in a repo that came from an unsquashed PR? It's hell. What's truly meaningful IMO is a git log that reads like a product change log
- WorldMaker 11y ago
  «Have you ever tried following a change in a repo that came from an unsquashed PR?» I have a self-congratulating black belt in source code archeology. With the right tools, most of which are on GitHub, even, such as good commit range diffing, smart uses of tags and branches, and knowing how to navigate the DAG from merge commits (more reason to -no-ff) you have a lot of power in your hands. «What's truly meaningful IMO is a git log that reads like a product change log» I appreciate that point of view, but I don't share it. A product change log, I feel, is a bit of marketing/PR that needs some time, love, and editing; I find a git log is for catching snapshots of raw progress and more often useful in seeing what your co-developers are up to, as they are working.
  - kylnew 11y ago
    I think this really comes down to team. It's kind of an all-in or nothing thing and if you go against the grain everyone will just end up angry

golergka 11y ago

This, as rebase, is a great idea for people who would rather use SVN instead, but have to use git for some reason or another. I mean, if you want your history simplified into a linear squashed series of commits, why the hell do you use VCS which models a history as acyclic directional graph in the first place?

devit 11y ago

The key principle is that the software should always correctly work at any point in the chain of commits, so you must squash commits that are "oops, fix X in previous commit". Once that is satisfied, commits should be as small as possible, so that information about the grouping of changes is preserved.

chmaynard 11y ago
This advice seems very sensible. Thanks for adding some valuable ideas to the discussion. I'm now reading the git documentation on re-writing history: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

eblanshey 11y ago

Usually when squashing branches locally, all the changes are set to myself as the author, effectively losing history of who did what in the feature branch. How does Github handle this? Additionally, the lack of the commit history for that branch often caused merged conflicts when merging the same branch again (if it had additional new fixes, for example). That's why I switched to using git merge --no-ff. If it were very easy to do, I would definitely do a git squash, as it keeps history very clean. I just don't want to have the problems listed above.

educar 11y ago

A bit OT but a feature I would love to see in git is to be able to see which branch a commit came from. Especially for shortlived branches which we prune periodically on the server (git branch -r --contains won't work as a result)

totally 11y ago

Wait, this isn't new.

kazinator 11y ago

Squashing is not an alternative to merge workflow. It's what you do to clean up before you integrate your work (whether by rebase or merge). You've just made seven changes, which should just be three: git rebase -i HEAD~7, squash away. Okay, now you have three. rebase them on top of new work in the upstream branch, or merge? Separate question.

hvmonk 11y ago

This is such a nice feature. Thank you for working on it. Keeping history clean is important, especially in enterprise solution where you have to keep support multiple releases. You want to select certain commits/features in one version. With merge/squash, you would get a cleaner history, and it is easy to pick commits you want.

justin_vanw 11y ago

No, don't squash your commits. This is stupid advice that comes back over and over. Squashing commits is a useless thing that has absolutely no benefit. It's dumb. It really makes no sense. It has very clear negatives. https://news.ycombinator.com/item?id=5631184 https://news.ycombinator.com/item?id=5631184

andrewprock 11y ago
If you are using git as a distributed version control system, squashing makes complete sense. If you are using it in a master/slave sense, and are not allowed to commit locally, then yes, squashing doesn't make any sense.

overgard 11y ago

Maybe I'm missing something, but I've never understood the point of cleaning up commit history. The only time I ever look at commit history past a few days is if I want to know when something broke (in which case I WANT every part of the history, even the messy bits), or if I'm trying to refresh my memory of what I've done for the year (for performance reviews or whatever) in which case I guess it's marginally useful, but it's pretty easy to skim over "fix build" and such.

macrael 11y ago

Do any VCSs have a notion of a commit of commits? If you could group a series of sequential commits into one commit on trunk it seems like you could have the best of both worlds: an overarching commit for your change and a series of how the sausage got made.

tedmiston 11y ago
Sure, a merge commit. git checkout master git merge --no-ff feature-branch

liquidise 11y ago

Oh god no. I made the mistake of moving a team to squashed commits once. The lack of individual commits poses large problems down the line. 2 nonstarters come to mind: 1: Completely ruin your ability to git bisect any bug injected in your branch. Instead of getting a 10 line commit, bisect will point you to hundreds or thousands of lines instead. 2: All code will blame to a single person. Code with 6 people on a large branch? Want to git blame the code to see who wrote the function that is weird looking so you can ask questions? Too bad. Do not squash branches on teams. One of the biggest mistakes of my professional career.

dsymonds 11y ago
This is for a "pull request", namely an individual logical change. Your two points don't apply. If you're dealing with whole branches with multiple developers, stick with merging, but this isn't that.
exDM69 11y ago
Your experience sounds horrible, but you were clearly doing something very stupid. Squashing is a tool to use with discretion. You squash two or three 5 line wip commits together. And I'd never squash changes from two authors (except perhaps whitespace or comment fixes).
shados 11y ago
point 1: merge smaller features more often. Multi-thousand line PRs suck no matter if they're squashed or not. point 2: As people mentioned, this is for PRs done by individual people, usually squashing their local history. If multiple people were working on the branch, they should have been PR-ing against that branch (squashing the commits), then you merge that branch to master (you may rebase it, but not do significantly destructive stuff). Even then, these are features to use with critical thinking. If your PR is really large, massage the history to be relevant and meaningful for git bisect purpose. Use full squashing when it was a local work full of "My hands are typing words" commits of no relevance. I swear, we're in an industry full of people making 6 figure salaries, who treat their job as if it was a call center script to follow. If you're an engineer, use your head and engineer solutions around the tools you have.

nullc 11y ago

Annoying: you can't turn off both. If your project has a workflow where the webui merge should not be used (e.g. using signed merges) there is still no way to achieve that.

deleted 11y ago

[deleted]

tomphoolery 11y ago

Can't wait to see this feature replicated poorly in about 6 months in Atlassian Stash (Bitbucket)!

kannonboy 11y ago
Actually Bitbucket Server (née Stash) already supports squashing and a variety of other pull request merge strategies. They're just configured[0] per repository, project or globally rather than an explicit option at merge time. [0]: https://confluence.atlassian.com/bitbucketserver/bitbucket-server-config-properties-776640155.html#BitbucketServerconfigproperties-Pullrequests https://confluence.atlassian.com/bitbucketserver/bitbucket-s...

hinkley 11y ago

It seems to me that the scope of this article is pretty narrow (in a good let's avoid a flame war way). And it describes one of the few scenarios where I think squashes are beneficial. But then the conclusion doesn't quite add up. if I want to remove all the merge mess from a PR don't I actually want to rebase the PR, not merely squash the history? Or dos I miss the point he was making?

looneysquash 11y ago

I'm confused. When I don't want to see the details of the topic branches, I run 'git log --first-parent'. Why not make it easier to see what I want to see, but then let me drill down and see more, instead of removing the details all together?

abalashov 11y ago

Call me naive, but wouldn't this problem be best solved by requiring that commits represent meaningful and working increments of work? I use 'git add -p' judiciously and only commit when having reached a point where something can be usefully said to be in some way "done". Sure, it's not perfect, and occasionally I end up having to do some cleanup of miscellaneous printf statements, debug values or typoes in subsequent commits, but this is something that should really be avoided if possible.

cortesoft 11y ago
Waiting until you have something useful has other drawbacks. For example, it might take many hours or days to get to a 'useful' and 'done' state - I don't want to go hours or days without saving my work in a manner that is easy to retrieve if something goes wrong. Besides the obvious 'hard drive failure' or 'laptop stolen' situations, there are also more frequent situations where 'oh shit, I went down a totally wrong path there - let me back up a bit and try that again.' Git commits are little save points that let me do small experimentation and go back if I need to.
- abalashov 11y ago
  Very good points. I guess I've just been too lazy to learn advanced rebasing / commit aggregation. Maybe I should, so I can more effectively take advantage of the upside while not polluting my commit history with intermediate crap.

lerax 11y ago

An unique thing: http://i.imgur.com/ztUufvf.jpg http://i.imgur.com/ztUufvf.jpg

cyphar 11y ago

Yeah, this is dumb. Being able to effectively bisect large projects depends on having smaller commits. If your commits are all huge, your bisect will hit some 500 line patch that does 5 different things -- it'll easily quadruple the debugging time. Not to mention that having small self-contained commits is a good thing.

DMOoO9 11y ago

no reason why developers should not be reliable for their work. if you ask me there should be a process to handing out open licenses and from what I have seen apache gives any one the right to do what they want. I would love to see stricter laws when it comes to third parties and open source licensing, including the chatter back and forth.

DMOoO9 11y ago

I believe there should be more open communication and a record the public can fall back on while these developers make their improvements. Something in their face. Too many times did I track back and see unprofessional comments being made and things being done that seemed downright suspicious. if it were up to me it would be alot harder to get a developers license and you would have to meet regulatory standards and have degrees to uphold your professionalism while acting as your own developer it seems to me that alot of developers have taken things into their own hands and are trying to make a quick buck any way they can get it. don't be surprised if you tell your mother or father or sibling to look at what licenses they have agreed to on their phones and they find alot of outdated unassigned licenses to back up their privacy. it seems to be an epidemic and how are we going to stop it?

DMOoO9 11y ago

I can't believe some of the comments I have seen made back and forth. let's shoot for a professionalism to supercede all others

DMOoO9 11y ago

I can't believe some of the comments I have seen made back and forth. let's shoot for a professionalism to supercede all others

0XAFFE 11y ago

This always reminds me of stackenblochen https://youtu.be/Qo_2ReMNzhU https://youtu.be/Qo_2ReMNzhU

losvedir 11y ago

This is great news for us as we prefer this flow. However, we actually mostly merge via our custom tool which uses GitHub's API. I can't find anything in the documentation about whether these options apply to API merges or if there's any query params that can achieve that behavior from the API. Anyone know anything about this?

chmike 11y ago

This is awfull because it destroys information. A feature branch needs cleaning up before publishing. These bug and typo fixes needs to be squashed in the branch, but the history should preserve a sequence of commits corresponding to atomic changes because it tells a story. A commit should be small enough to make it easy to check if the change is correct. It should be self contained so that it can be moved arround, cherry picked, etc. This is why the local commit history should be considered as a draft of the story, and the one published should be the official one aimed to be easily readable, verifiable and manipulable.

kinofcain 11y ago

Fantastic. Regarding non-merge workflows: For me the question is: should git history reflect a literal record of keystrokes or should it reflect intent? I strongly believe in the latter.

greg0ire 11y ago

This is wrong at so many levels. Of course we don't care about "progress" or "woops I fucked up" commits, but people also do commits for things like coding style, and these commits should be keep separated from the others, and DO NOT warrant a separate PR. If it is about changing all tabs to space in a file, for instance, different PRs will be hard to work with, because of conflicts. Also, people who write WIP commits should learn how to squash them themselves, and give them a meaningful commit message.

jondubois 11y ago

I think squashing commits makes sense if you're working in a big team and/or on a complex/large project - The main advantage of it is that it speeds up the QA process because it cleans up all the back-and-forth (exploratory) changes that tend to happen during development. If you squash properly, each commit will represent a small standalone feature. It does reduce your commit count though :(

dboreham 11y ago

As this thread approaches 300 posts I'm wondering when we're going to get out of this Git Tarpit we've somehow got ourselves into? To be charitable: Git seems to be a good tool designed for Problem A, being widely used for Problems B,C,D for which it is a fairly poor choice. I _think_ we got here through some mix of "but it's really fast!"; "I can do _anything_!!"; "But Linus says its great!"; "I don't need to pay for a beefy server any more!"; "New _must_ be good, right?". In any event, how do we get out the ditch and back to work making software vs. trying to reason about the unreasonable? I personally, for the kind of projects I'm involved with (small teams, all paid by the same piper, with aligned clear goals and competent coders), had perfectly satisfactory revision control systems since around 2000 (except when required by employer to use Clearcase..). It would be nice to get back to that future.

wandernotlost 11y ago

This obsession with "clean" history seems to me nothing short of insanity. Source control has one job: to record the history of code in order to be aid in figuring out what happened when things go wrong. If everything always went well, we'd just have great merge tools and throw away the history. I can understand a desire to filter out stages of a project by different levels of review (I just ran the build and tests passed so I committed vs a bunch of people reviewed it so I merged), but that people solve that by deleting or rewriting history to be something different from what actually happened is just nuts. Is it just that git makes it easier to change history than to add metadata for filtering? Why have we not seen presentation tools to solve this problem rather than what seems like a ubiquitous readiness to alter and throw away the messy but accurate facts about what happened?

jedberg 11y ago
Because the lack of squashing actually makes finding bugs harder. Which checkin with the status "change i to l" or "whoops, typo" was the bug in? It's a lot easier when an entire changeset has a single checkin into master, because then when you're doing your bisection there are a far few changes to bisect.

cm3 11y ago

The option to avoid merge commits when merging pull requests misses the point, but apparently many users demanded it for some reason, so Github implemented it. Here's how merge commits, rebasing and isolated small commits work: You branch your topic off master and make many commits while working on it. This is all local. Once you're ready to publish for review/integration, you squash fixup and backup commits into a coherent patch set, where each and every revision builds and works. This is where you can rebase and squash for good reason. Now you can push to Github. If you, like Phrabricator, create a single big commit with all changes lumped together, then it's impossible to bisect and follow the thought process behind changes. Try to git-bisect linux.git vs a repo that's been managed with Phabricator and its mega commits. With small commits that each make one coherent change, you can easily include relevant explanations in the commit message, which is much harder to achieve with a single mega commit. Further, it's very simple to follow along the development process of changes with separate commits. If you have one big diff, it's hard to understand the changes of a branch, whereas reviewing small commits with an explanation in the message and the overall reduction in diff size makes it much, much easier to understand for reviewers. With separate small commits you review each step and finally arrive at the complete feature implementation at the end. For someone who has to review code they didn't write this saves a huge amount of valuable reviewer time for actual reviewing than trying to reverse engineer the steps taken in a big diff. Moreover, with multiple commits, you can easily approve of some of the commits, while requesting improvements for others. Gerrit implements this well and the process is what linux and git and other projects use when reviewing big patch sets. Set is the important word. Finally, why do you want merge commits? Unless you always make a single mega commit ala Phabricator or the new Github feature, having merge commits provides a very practical way to see that a set of commits landed via foo-branch-X. If you've ever viewed a git log graph, that's the interesting integration points, which you will lose if you omit merge commits. In a merge commit you can also include extra stuff as part of the merge commit itself, so it's not just useless metadata.

dclowd9901 11y ago

Rarely do conversations around these parts get as heated as they do when git process comes up. As I read through these comments, only one thing surfaces: everybody organizes their shit differently. If you're here trying to sell your process, why?

mikebannister 11y ago

I personally like this and it fits well with my team's workflow (though I am a bit concerned it will prevent engineers from learning to do these things with git). There are pros and cons for sure but I think if you are losing a lot of resolution by squashing then the scope of your pull requests might be too big in the first place.

mck- 11y ago

Added benefit of this would be that it is easier to git revert a merge from cli