Build Your Own Git UI for Mac with GitUpKit(github.com) |
Build Your Own Git UI for Mac with GitUpKit(github.com) |
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.
This means that writing GitUp in Swift would be a ton of overhead for very little tangible benefit.
See examples of what well known Mac developers have to go through with Swift: http://inessential.com/swiftdiary. I'd rather spend my time on building the app rather than on dealing with Swift.
I hope no-one here ever has to deal with a tree like this.
Somehow, even a moderately simple repository which has been heavily co-authored will look like garbage; even though there _are_ two distinct mainlines that you can follow.
One of the best visualizations for revision control, IMHO, is fossil's timeline view:
https://www.fossil-scm.org/index.html/timeline?y=ci
It's clear, compact, and tries to maintain different lineages as straight lines. git tools, by contrast, just shift everything on right.
Not even github's network view is really usable, since the network simplification they perform destroys the locality of the changes.
At first I didn't like the idea of including a web interface and wiki, but the more I thought about it, the more I liked it. Having a change log for the wiki would be helpful, and I'm assuming it's zero cost if you don't use it.
Including an integrated bug tracking seems like an ingenious idea, though. Any idea how well it works out on real projects?
+1
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...
That being said, it's not any different from hg/git in terms of cooperation, and more similar to hg in the sense that history is irreversible by default.
But the UI (cli and web) is very well designed. There's nothing to dislike, really. I couldn't care too much about the wiki (IMHO, a better solution is use md documents directly in the source), but the issue tracker solves distributed bug tracking in a very elegant way. Contrast to git/hg, where you have to use third-party or centralized bug tracking with poor integration.
Fossil is used by the sqlite project (and several other hidden gems).
I still find unbelivable that fossil has such a well-designed commit graph and interface, and git (with so many eyeballs looking into it) has nothing similar (and I _do_ know "git show-branch").
