Live data from Hacker News

Build Your Own Git UI for Mac with GitUpKit

github.com

1–10 of 17 posts

Re: Build Your Own Git UI for Mac with GitUpKit

#4
post #3

> http://gitup.co/images/speed.png I hope no-one here ever has to deal with a tree like this.

That doesn't look so bad? From what I can see, it's probably just feature branches all coming from a single point (e.g. previous release) being merged one after the other. Any active project with a team upwards of a dozen people will look the same and possibly way worse.

Re: Build Your Own Git UI for Mac with GitUpKit

#6
I'll be writing a few more sample code in the coming days but you can already see how simple the API is: https://github.com/git-up/GitUp/blob/master/GitDown/AppDeleg....

GitUpKit is a multi-level API design so you can just use exactly what you need from each level depending on how much control you need (e.g. you can use a raw diff rendering view or a ready-to-use full-featured diff view).

Happy to answer questions if any or just visit http://forums.gitup.co/ where the GitUp community lives.

Re: Build Your Own Git UI for Mac with GitUpKit

#7
post #6

I'll be writing a few more sample code in the coming days but you can already see how simple the API is: https://github.com/git-up/GitUp/blob/master/GitDown/AppDeleg... . GitUpKit is a multi-level API design so you can just use exactly what you need from each level depending on how much control you need (e.g. you can use a raw diff rendering view or a ready-to-use full-featured diff view). Happy to answer questions i…

Lovely. My first question as a noob-not-even-osx-developer-yet is why not Swift? (my impression is that it is a quite recent project).

Re: Build Your Own Git UI for Mac with GitUpKit

#10
post #4
post #3

> http://gitup.co/images/speed.png I hope no-one here ever has to deal with a tree like this.

That doesn't look so bad? From what I can see, it's probably just feature branches all coming from a single point (e.g. previous release) being merged one after the other. Any active project with a team upwards of a dozen people will look the same and possibly way worse.

Yup, I would not call it bad at all. It's actually very good, dare I say beautiful, perhaps?

The first parent history (the spines going down the left side) contains primarily topic branch merges. If you look at the topic branches, they're all completely linear history.

The linear history in each topic branch is carefully constructed by Junio Hamano, Git's maintainer, as commits typically get into git.git via patches, not through direct commits + merges.

This is not the same as the normal ugliness that people are used to seeing when working with larger teams that abuse "git pull" and create ugly merges in their history.

The resulting history from this approach is more carefully curated and elegant. There are lots of topics and contributors so the resulting history naturally contains lots of merges. The viewport is only so large. If we pan and zoom over to a different area, we'd probably see some pretty trees.

If you're curious, you can read more about how the branches are managed here:

https://github.com/git/git/blob/master/Documentation/howto/m...

Post reply on HN