On Thursday, January 24, 2013 11:19:29 AM UTC+11, josharian wrote: > Thanks for chiming in, Pieter! > > > > I've looked before into 'blessing' an alternate repository by > > redirecting to it; however, in the past I haven't found a fork that > > has been active enough for a long enough time to do this. I wanted to > > make sure that when I hand over control, it will continue living for a > > while instead of dying after a few weeks / months without me being > > able to do anything about it. > > > > That might not be logical -- I guess any progress is better than the > > complete absence of me for the past few years. The repo from rowanj > > looks like it's active, so it might be best to just redirect to there. > > A rational fear, but I think your coda also makes some sense. :) > > Might be time for rowanj to chime in as to whether he's prepared to commit > to gitx... > > -josh > > Greetings, all!
As a little history, I started my fork a couple of years ago now because I'd recently started developing for Mac and iPhone; and needed to work around a couple of issues our small team had when working with the tools that were available. For what it's worth, I believe that we'd mostly been using mainline, but I really can't be sure at this point. One of the driving factors for my initial work was the addition of non-developer (i.e. artist, modeller and graphic designer) team mates; who could readily lose work to tool quirks if they weren't suitably protected by the UI. On that note, my fork of GitX does have brotherbard's ref dragging; and the disabling of moving HEAD. I'm quite picky about my tools; so I've really found it very rewarding to keep up the maintenance work where I have the time. To put it directly, I've been committed to at least maintaining GitX for a long while; because my co-workers and I needed it. For a great part of that, and increasingly recently; I've also been enjoying it. I don't see either the need or enjoyment diminishing any time soon, and am thrilled to have my work nominated for the suggested role. --- Okay; sorry for brevity here, just trying to respond to the other points in this thread so far, before I run out of brain for the day. Just hit 1 AM here. I agree that it's more than a matter of versioning/search ranking to reduce the user confusion about which fork to choose. GitX isn't in the Mac App Store because: - It's GPL; and that's incompatible with the App Store licence - The project Copyright is Pieter's, and it's entirely unclear to me if there was ever a copyright assignment policy, so changing the license means getting permission from every nominal contributor - (I at least) have done no testing whatsoever with sandboxing - I suspect GitX wouldn't play well; it's at least not a problem I'd like to ignore Personally, I'd love to get it into the App Store for ease of getting it onto workstations alone. All my GitX packages come from a Jenkins-CI server, and are deployed automatically through Sparkle. The latest build is (as of a couple of days ago) linked from the README on the project homepage, but may lag by up to 24 hours because of a CDN issue I can't easily fix. My priorities for UI development is discoverability and day-to-day tasks like committing, reviewing, and merging. I'm getting close to satisfied with this, but not quite there - for example, I've never seen somebody drag a branch that hasn't been told that they could; and it could just be a matter of grab 'dashes' and/or cursor upon hover over the branch name. On the back-end side, my long-term (i.e. 1.0) plan has been "stop using git command line" pretty much since I started. libgit2/objective-git is getting close there, but is still missing some big stuff like the ssh transport for remotes. It's an external dependency that's difficult to explain, and the different versions in the wild are a common source of bugs that are a pain to reproduce. Realistically, I'd be happy to call it 1.0 if I could just get a version of git bundled into the app and use that instead of any environmental one. And yes, interactive rebase would be a killer feature. Also, a working directory 'breadcrumb' (history of what you've had "checked out" i.e. the contents of .git/logs/HEAD) would be glorious. I think that would be a fine solution to the tricky issue of dragging the checked-out branch around, too - as my concerns with that are based on the ability to easily lose stuff in the UI that you can't get back without going to the command line. Good night, all. Rowan James, maintainer of https://github.com/rowanj/gitx
