The flying Octocat is pretty slick.

I like the idea of collecting news for individual Github repos. At least it's something I don't see on other Hacker News readers.

Thank you. If you have any suggestions, feel free to open an issue at https://github.com/porter-io/feedback

Or maybe Apple.

Yeah. I'm aware that Apple has made some great contributions in Open Source. However, that doesn't change the fact that they live on proprietary technologies and investing in OSS is just a strategic business action.

This article here explains this: http://sealedabstract.com/rants/beyond-open-source/

great article, thanks for sharing!

The question was whether they'll make the whole OS open source, not just some bits of it. (Microsoft produces some open source, too.)

Is this the post you are looking for?

https://news.ycombinator.com/item?id=7838772

Or are you looking for the Strip api doc?

https://stripe.com/docs/api

Or just some goodlooking docs?

https://github.com/PharkMillups/beautiful-docs

Stripe api doc is what I was looking for. beautiful-docs is the cherry on top. Thank you very much.

Look for slate from tripit as well

As a novice git user, I can't really tell how Gitless is really different from Git in daily use cases. Any explanations?

Merges and simplifies a lot of common cases. For example, creating a new blank repo in gitless is:

    gl init

And getting a local copy of a remote repo in gitless is:

    gl init <url>

Whereas in git, it's:

    git init

and:

    git clone

Similarly, the operations to switch to (and create) a new branch, switch to an existing branch, and list branches, in git, is:

    git checkout -b newbranch
    git checkout oldbranch
    git branch

In gitless, its:

    gl branch newbranch
    gl branch oldbranch
    gl branch

Similarly, git has a somewhat complex situation where files can be staged, changed, tracked, and/or ignored; confusingly files can be odd mixtures of all four, and it can be quite hard to understand how to change the state of a file in some cases.

Gitless simplifies this a bit by removing the "stage", so files are either tracked, untracked, or ignored, with no ability to mix states. And instead of selectively staging changed files and then committing them in two separate steps (as you do in git), you stage and commit in one go.

Gitless is built on git; someone familiar with git can easily tranlate the gitless commands into the underlying git commands. It's not doing anything magic, but for day-to-day use the commands are probably a little more consistent and sensible.

Personally, my biggest pain point with git comes from managing complex branching situations; trying to figure when/how to merge, rebase, and cherry pick can be frustrating. Sadly, gitless doesn't (yet) help with this area.

(Short form: Gitless tries to make git's syntax simpler and more consistent.)

So is gitless against working with hunks of files because the docs say that having files with parts in multiple states is a problem? But this actually gives more flexibility. Yes it's more complex but that's the trade-off.

I'm not sure I'd say gitless is "against" it so much as it's focused on making the tasks people do every day easier. I use git every day, but I think I ended up staging individual hunks of files maybe...twice in the past year?

(And you can still drop back to git if you do need that functionality. As the docs note, gitless and git are entirely compatible.)

true...i guess for me it's another potential option for working with git like the prezto git module and git plugins for vim

Thank you so much. I think they should definitely put something like your explanation in their documentation to show the difference in a more expressive way.

As an experienced git user, as far as I can tell s/git/gl ;-) I couldn't really see any differences at all from the documentation. Perhaps I missed something. An overview of the differences would be very nice.

The one thing that concerns me is the inclusion of rebase. If a wrapper is supposed to change difficult underlying concepts in git, why keep the most difficult concept: rebase. I like rebase, but for many common workflows you really don't want to use it.

I got the exact feeling as yours at first. :)

My understanding of your concern of rebase is that if they are gonna change that (or get rid of that), it will be a change of the workflow instead of just a simplification of it.

I used to rely on merge other than rebase when my local tree is diverted. That usually ended up with two commits (one for my local changes, one for the merge). But later I learned to use rebase. It would only result in one commit, which I feel is kinda nice coz you have a cleaner and more correct(time-wise) commit history. I don't know if this is the fundamental purpose of rebase. Advice welcome.

This was a long time ago, so maybe you won't see this reply :-) Rebase is awesome as long as you never publish the branch before you rebase. If anyone uses your branch, then the history will not match up and they will not be able to merge their changes because Git will not be able to determine the order of the commits. I have gone through this more than once and it is not fun at all.

Rebase works extremely well for what is was designed for: You have a lot of people working completely independently and you want to submit your changes to a central maintainer. You rebase your branch so that the changes appear to be applied directly onto their branch. It makes it much, much easier to review. If the change is accepted then it is merged and everybody uses the merged version. If not, the branch is destroyed (of course you still have your changes in your repository). As long as nobody makes any changes to (or branches off of) a branch that will be rebased, then there will be no problem.

Because the vast majority of people use git as kind of a "better SVN", with a centralized repository and published branches (using Github or the like), most people should never, ever use rebase. Especially if you are trying to design a simple workflow for neophytes, then you should almost certainly not make rebase easy to reach.

Like I said, I like rebase, but it is not something that fits well in a collaborative office environment. It works much better in a hugely distributed open source project, or a personal project (if you are being very careful).

At first I assumed they have a large collection of templates for shops just like web templates with different styles. But I was wrong. All their shops look alike, with a minimal style. It's a total mystery why they have so many lines of css for such a simple design.

I seriously wonder if it could achieve the rendering quality/usefulness as it advertised. The combination of portability/3d performance/battery life/comfortability usually doesn't produce good results. Google didn't solve this. What should I expect from Microsoft?