I wonder how the new iMac 5k Retina is going to influence sales for their iMac line numbers. They increased but I don't think it's just because of this release?
It's the soft double tap gesture apple introduced because of the huge screen. This way you can use navigation panel elements without moving your hand that much and it's less likely that you drop your phone.
I think Apple needs to check on this very careful just because of some services like Uber offer services through the app and don't sell a physical good.
The opposite of this is, that you can't use Apples tier-pricing for services like that just because of it's usage-dependant and is reflected through actions in the real world.
I wonder how much effort Apple is going to put into checking on this actually. Especially because of services like Uber sell the ride. But what if the direct contract partner would be the driver and any service provider like that would just process transactions for comfort - so acting like a payment gateway for drivers.
A valid point, but I guess Apple will change the terms of service or will define services like Uber as physical good, since the service affects the real world and can not be realised through in-app purchases.
I think that is what it is all about. They do not want Devs to opt out of in-app purchases and adopt ApplePay instead.
I'm pretty sure a cab ride is a real-world, physical thing. Besides, Apple's Guidelines are really just that, and they can enforce at their discretion.
How and when to comment should be a decision made by the contributors working on the feature, but squashing is something I always disallow for any team I work with just to keep the history and be able to follow the programmer when chasing down a bug.
My biggest concern here is, that you have to force push because of you rewrite the git history. That way you are most likely going to loose data.
If you need WIP commits to switch branches use the stash instead. You won't overload your history that way in a cleaner way.
If I don't publish my intermediate commits, how are you going to tell whether I made lots of small commits and squashed or just didn't bother committing until I was finished? The objects generated are identical.
Also, the git reflog keeps references to the pre-squash commits for a time, so the information is still there if you realise you squashed too much.
My recommendation is that commits should be atomic, minimal changes that take the source into a working state. This makes working with git bisect so much easier, but it does sometimes mean reordering and squashing commits.
A safety check in the case where you've got everything working but your history needs some tweaking is to note the hash of your tree in its working state, and verify that the tree you created after squashing has the same hash. You can do that by either inspecting the commit or diffing against the old reference.
> My biggest concern here is, that you have to force push because of you rewrite the git history. That way you are most likely going to loose data.
Not entirely true. If you only squash when you merge the branch in, there's no need for the force-push.
Rebasing into the already pushed history should be flat out banned without question within teams, and force-push be disabled within configs. It's only in exceptional circumstances where you would actually need to do these.
But why do you need to squash while merging? The concept of merge tells that a branch is merged into the history by adding a merge commit. This commit reflects all differences. It's done automatically if possible - you need to resolve conflicts if it's not.
Correct me if I'm wrong but in my understanding a merge does nothing else than create a commit which is like a squashed representation.
Your team can do whatever they like on their own machines, before they push to the remote, unless you really are not fun to work with ;) so there's no reason to prefer the stash, temp commits and temp branches provide a more structured and better documented stash. Stash should just be for little things, and ideally things which are not very branch-specific (because there's only one stash, for all branches).
If you take it like that you can also say ignore the squash and keep the merge commit clean.
That way you don't push all your development commits to the remote and ensure a clean streamlined history.
A problem some teams I worked with have is that there is not one person working on a feature. Especially if you have feature-driven development teams at least 2-3 people actually work on it and a review process is included. That's why teams need to push their feature branches to the remote. Once they are merged: Feel free to delete them. But in my opinion it's hard to work on one feature with several people without distributing the feature branch.
You shouldn't push dysfunctional branches anyways to keep the application working and always testable.
We have a CI server testing every branch for every push - I'd regard it as rather bad to have failing builds 20 times a day.
Worst case could be that it goes live because of some processes related to continuous deployment (misconfiguration happens, in companies of every size) send this to live environments and there is a chance to ruin experience for your users.
