News for hackers. Stuff that matters.

cjantz

Re:Apple's 2014: By the (ridiculously large) numbers on Tuesday October 21, 2014 @10:23AM (#8487466)
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?
Re:iPhone Home Button – Hidden Gestures? on Tuesday October 21, 2014 @10:19AM (#8487444)
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.
Re:Y U NO commit?? on Tuesday October 21, 2014 @06:37AM (#8486731)
Exactly!

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.

Re:Y U NO commit?? on Tuesday October 21, 2014 @06:33AM (#8486721)
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.

Re:Y U NO commit?? on Tuesday October 21, 2014 @06:29AM (#8486712)
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.

Re:Stripe – Apple Pay on Tuesday October 21, 2014 @06:22AM (#8486701)
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.

Re:Y U NO commit?? on Monday October 20, 2014 @08:36AM (#8481767)
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.