Repository navigation
Project status? #259
Description
I've got a couple of 3 month old pull requests. Moreover, there seems to be a lot of work about in issues. Could this project maybe could use a few more hands?
@rowanj: are you doing all this alone? If so, would it be time to build a team? GitX has a frustrating history of the baton that keeps getting picked up, then dropped again. I'd like to see GitX-dev remain the one true GitX, but that probably means the single-dev model needs to die at some point.
Apologies if I'm not keeping up with the group...
Activity
barnabyc commentedon Oct 21, 2013
+1
Also if I recall, was there talk of a rename to avoid some active/inactive fork confusion?
tiennou commentedon Oct 21, 2013
+1. I've been trying to join the boat too, but given the "state of the code", I've finally settled on working at a lower-level (a.k.a I'm hacking away at
libgit2to provide what's needed for GitX to move forward in tearing away the IMHO horrific NSTask interface.claybridges commentedon Oct 21, 2013
The github issue discussing renaming is here, and that directs to a more extensive google groups thread.
Having read all that, here's my take on the state of play. We could either:
Re: option 1, there are still brotherbard and GitX-L forks to noise up the space. That will probably die down over time.
Regardless, I think GitX/Git* needs to decouple from any individual, and become a project, e.g. GitX/GitX, so that the baton can easily passed while maintaining continuity, and there is no single choke point for issues & pull requests.
tiennou commentedon Oct 21, 2013
+1 on the GitX organization thing. -1 on the rename, let's make this one the blessed fork with our bare hands ;-).
tiennou commentedon Oct 21, 2013
Also, what would be nice is a style guide. I'd be happy to give a hand in reviewing PRs, if the current style wasn't so... disparate ;-).
pipelineoptika commentedon Oct 21, 2013
@rowanj is currently very busy with his day-job, so GitX by necessity needs to take a back seat. I've been testing one build for him which has a number of improvements, but I don't think it's ready for release.
Offers of assistance are always appreciated!
claybridges commentedon Oct 22, 2013
@pipelineoptika: what needs to be done? Testing? Do you have a .dmg link? Any particular methodology?
@tiennou: do you have a extant style guide in mind? e.g. Google's?
tiennou commentedon Oct 22, 2013
I'm more familiar with GitHub's (since I work on Objective-Git). The few things I have against it are the TomDoc comments — though they are readable, I don't think there's an
appledocextractor — and the dot-syntaxify-everything stance. And the fact that it enforces Tabs can sound crazy to some people ;-).I'll review the Google one tonight, because it accounts for Objective-C++ and some parts of GitX are using that.
5sw commentedon Oct 30, 2013
I'd like to help too. Right now I'm too busy with work, but I can do reviews of pull requests and stuff like that. Also 👍 from me for the GitX organization thing. I believe work will progress much faster if multiple people have access to the "master" repository.
muhqu commentedon Oct 31, 2013
👍 for GitX-dev organization thing!
rowanj commentedon Dec 16, 2013
👍 for GitHub's Objective-C conventions; at least, for the vast majority of code style issues. Some of the points I can take or leave; but beyond brace and indent I don't really mind.
If there are going to be documentation comments, I'm pro- "whatever the project build environment uses" (Appledoc), but unless somebody is going to step up to:
... I'll put the work into cleaning and refactoring the interfaces over documenting the existing code.
I'm on GitX for the long haul.
For renames, I don't really mind. I'd like to avoid ambiguity with other forks, which to me means either establishing rowanj/gitx as mainline, then adopting "GitX"... or taking a wholly new name.
Yes, I'm looking to expand the team.
rowanj commentedon Dec 18, 2013
I was a bit unsure when I wrote that, but no... I'm not making it up.
Merge pull request rowanj#259 from gitx/ObjectiveGit-arm64-preparation