Forking, and plans for the future of GitX

[claybridges]

As it's looking like a fork of GitX-dev is inevitable, I thought it would be a good idea to create a thread here to kindle discussions on next steps. Perhaps for substantial other topics -- architecture, coding standards, etc. -- separate "issues" can be created here at gitx.github.io, addressing them. When and if the fork is a reality, the discussion can be migrated over there.

One issue of primacy is from whence to create a fork. I have suggested rowanj/GitX as a jumping off point, but if you feel differently, it's a good time to make your case.

[hugocf]

Ok, let me just start by saying that GitX must have something really great at that very core level to be so resilient over the years, that there is always someone willing to revive it. 😄

Sincere congratulations to @pieter for getting the fundamentals so right!

Once again, recently, I found myself setting up a new laptop and scavenging the internet for a maintained repo of GitX. 😞

I found ssp/gitx’s fork which fixed the most pressing annoyances (e.g. bad initial window size) and he was kind enough to point me to these discussions.

Considering that it’s been 3 years now since the initial prompt by @schwa to address the issue of unmaintained forks (rowanj/gitx#123, rowanj/gitx#259, rowanj/gitx#283, rowanj/gitx#451), I think it is safe to conclude that it’s not going to happen anytime soon!

[hugocf]

I would like to propose we resurface this idea of the organization, not as a blessed repo or with any request for others to discontinue their forks, but rather as a collaborative place where:

• People collect and merge patches/fixes waiting in the sidelines of the other repos
• Any major changes in direction can be discussed and agreed as a group
• Bottlenecks on a single person’s schedule can be removed since others can easily take over

Consider it an aggregator, if you will. A place where @ssp could have had an active participation without feeling he is carving yet another corner in the already crowded GitX history.

For example, we would point right at the beginning of the README page to all the relevant existing repos (@pieter’s, @rowanj’s, @laullon’s, etc.) where fixes are drawn from. Direct pull requests would have many who could act on them, reducing the time to get a release out there. Etc…

You can see Homebrew as a great example of this model working successfully, where several people can act on incorporating the pull requests into the main repo and making the releases.

Time would tell if this becomes a repo of reference on it’s own or not, but if it is maintained throughout the several iterations of OS X updates, over time I believe it would be so.

[hugocf]

[ssp]

Thanks for bringing this topic up again @hugocf !

I hope we’ll come up with a plan to make things work in a reasonable way.

One question that seems to be coming up over and over again is people wanting ready-built binaries of GitX. Personally I don’t think I have the tools/resources to provide those in terms of automatically building Mac software in the cloud (and I wouldn’t want to do it manually).

Conceptually it’s not clear to me how things like code signing and possibly Sparkle updates should be handled with such a build to ensure people don’t end up in a dead end.

Sven

P.S. @tiennou may want to chime in here als well?

[voxpelli]

@ssp I think Travis CI has all that you need for automatic builds. See eg. this article on code signing there: https://medium.com/juan-cruz-viotti/how-to-code-sign-os-x-electron-apps-in-travis-ci-6b6a0756c04a

[nanoant]

I have a working Mac server at university, that is already doing some builds (Nim project), so its preaty easy to set it up for GitX.
But technicals are not the problem here, a will to unite is a problem.

[tiennou]

Right now, I am only aware of my fork and @ssp being active, and we try to merge changes from time to time (or discuss things I don't like 😉). Which is fine by me, not having a release is only a concern for outsiders, right ?

I share the view of @ssp on handling release and setting up a new Sparkle feed somewhere. I've tried to setup Travis to do our bidding, asked for Amazon Web Services for their free-one-year-trial (which IIRC is the only thing supported out-of-the-box by Travis for stashing build artifacts I overlooked the Github Release), and stopped due to various reasons, like "I don't know what I'm doing", "what's the point we have no shared repo". And it was six months ago.

I'll see about setting that automated thingy then...

[hugocf]

Would you guys consider a shared repo under the @gitx github org?

I’m not much of an iOS dev but I would like to help with anything I can. I’m one of those outsiders which every now and then needs to go through lots of hoops to get a building release of updated GitX :)

Sparkle updates would be great but could come at a later stage. Just a manual download to start with would be a good starting point to get the collaboration going?

[masongup]

Anybody have any idea what's going on with this project? Are you in charge of this org, @nanoant? It currently has no public members.

A proposal: Add anybody who's shown interest/effort in contributing to the unified GitX project to this gitx org with full privileges. Then we either fork or transfer @tiennou or @ssp's fork to this project and merge the latest stable code from both into it. That would at least give us a central point to organize work around that hopefully has enough people with permissions that the project won't go dead for months because one or two people had to give priority to other things in life.

It would be awesome if we can get that done, and start looking at setting up something resembling official builds and releases here.

[tiennou]

I'm OK with that. Be aware that my master branch currently point to a heavily edited version of @ssp's, because there were one thing I didn't like (shallow repo handling, which I'm waiting for upstream support), and a change that breaks one of my WIP branch (using libgit2 for the commit and change-tracking). If I get the privileges to push to gitx, I can fix that up.

The thing is that it seems one of the "original" GitX alternatives is getting E-O-L by Sierra, so now might be a good time to advertise ourselves ;-).

[rjmunro]

CircleCI offer a free plan to OS X open source projects, which we could use for making builds. See the question "What if I am building open-source?" on https://circleci.com/pricing/#faq-section-linux. If nobody objects, I can email them and ask about it.

[claybridges]

@tiennou Would you then recommend starting with @ssp's fork? Let's decide and do it. Even without a binary build, having a central repo would be a big advance, IMO.

[tiennou]

@claybridges You have access to the @gitx organization right ? If you don't mind giving me access to that, I can push the last version @ssp and I were "agreeing" on (namely tiennou/gitx@c1d8f15) as master there. Then we'll start from here. Alternatively, you can do that yourself too 😉 . What I'm unsure of is, how to keep repository "parentage" visible... Maybe fork @rowanj's repo under the gitx org, then push that commit on top as master ?

@ssp Is this acceptable to you ?

[grantbdev]

I agree with @claybridges that a central organization repo would be a good first step and things like binaries can be worked out later. Whoever has the access (@nanoant?) should help @tiennou and @ssp set up the new repo/fork. Please git it done!

[nanoant]

@claybridges @ssp I have sent you invitation to GitX organization. @ssp I think the best would be if you just move your fork there, instead forking another fork of fork ("Inception"!?)
If you need any assistance let me know, and sorry for a delay, I have relocated to different country and being kinda busy with my new job.

[ssp]

Thanks for adding @nanoant ! Hope you’re enjoying the new location & job.

Before pushing my current master, we should take into account @tiennou ’s last remarks about some of my commits breaking his.

@tiennou : I like your general idea of forking from @rowanj’s repo to keep the lineage clear.

How should we proceed from here? As there are more than a handful of patches since the commit from June you point to, it would be helpful if you pointed to the ones you »disapprove« of (possible along with an explanation whether you see a technical or a design issuse or have something better along the same line prepared already).

Perhaps we can then reassemble a new master branch that is the current ssp/master without the problematic commits.

Regarding the handling of shallow repositories: of course I would prefer if libgit2 could to that … this is just meant as a stopgap behavior to let GitX help users until libgit2 is sufficiently compatible. To me it looks like this has not happened yet.

[tiennou]

My last "approved" point is ssp/gitx@cc714ae.

After that point, I'm cautious about the stuff that touches shallow repositories in ssp/gitx@97f2e2c.

My rationale is that I'm not fond of blanket-fetching the repository, because it is shallow for a reason. I mean, if I were to have a shallow clone of linux around (hint), and that I was forced to unshallow it to use GitX, it would lock up the document for a lonnnng time.

On top of that, there's the issue that we currently assert when enumerating shallow repos because we can't tell a missing shallow parent from an ODB failure (fixed in libgit2/objective-git#590).

And to top the top of it all, I would have preferred a nicer GUI than a plain error on open: my idea was to add a "see more" at the bottom of the commit list, that would perform a fetch for a reasonable number of commits (and maybe provide a "fetch all" menu item that would do the whole shebang).

libgit2 is mostly-compatible with shallow repositories (eg. it doesn't assert 😉). It just doesn't provide some of the information we need to make sense of what's actually happening, like the OIDs of the shallow commits, (which are in .git/shallow), but we can grab that ourselves anyway (that's not the hard part), or wait for libgit2/libgit2#3853, which has the basic stuff we need.

On the specific point of my broken commits, it's about the churn introduced by ae7370c2fa4877e23c90297f6f0e2e67453dc0ab and removed by 439f5598a291cbc5cc0c15afcccc3e0e3da083be, so if you would just amend the first, that would be nice. I can obviously rebase my work (which is switching GTIndex to use libgit2 directly).

In conclusion, I don't feel too strongly about the above: the "shallow" problem can be improved step by step, and I could rebase my branch on top of yours and be done with it (it's just a hassle, because it's churn).

[ssp]

Hi @tiennou,

my takeaway message is that you don’t really mind the shallow repo handling and that we may be close to being able to remove the currently message completely as support for this is on its way in libgit2. So I’d just leave it in until that code has landed.

I squashed the two commits ssp/gitx@ae7370c2 and ssp/gitx@439f55 as you suggested, to avoid problems with the intermediate commits. and pushed the result as ssp/gitx/gitx-master.

If that works for you, I can set up this as a starting point.

The next commits I’d like to integrate after enjoying those changes locally for a while are nanotech/f/restyle for a look that is slightly flatter and more in line with current OS X. nanotech/f/objgit-history looks interesting to me as well although you may want to chime in on the technical merit of that.

[tiennou]

Nice, thanks for doing that. Next step would be to push that ssp/gitx/gitx-master as our new master branch, then @nanoant can issue PRs for those directly to the org, and we'll review normally ?

[ssp]

All right @tiennou & co … I created a fresh fork gitx/gitx and pushed the branch as discussed.

[tiennou]

So, I've done a few maintenance tasks (as you might have noticed), and since this issue has become our de-facto communication channel, I'll use that.

• I've taken the liberty to cleanup some old branches that came from @rowanj's fork. I've only kept those that weren't already merged and plan to investigate what can be salvaged from them later.
• Travis releases should be working on my fork. If that's the case (and the application actually looks correct), I'll set that up on the main repository.
• I enabled issues on the repo. Arguably you only need to look at the GitX-dev repo to find some things to tackle 😉.
• I'll try to focus on updating the project various documentation channels in the next few weeks.

[tiennou]

Also, 👍 to everyone for keeping it alive !

[dbackeus]

Glad to see activity around keeping gitx alive. Sorry if I missed something obvious but which fork should I go to for your collaborative effort? Any pre-built package available for easy installation?

[voxpelli]

@dbackeus https://github.com/gitx/gitx

[claybridges]

@dbackeus At present, we're building our own versions, instructions here, Xcode required. A build and distribution system is on the wish list.

[claybridges]

This issue got the ball rolling -- good work all -- but I believe it's time to close it, and move forward.

[elia]

@claybridges 🙋‍♂️ maybe it's worth considering adding more people as organization members so that PR review and approval can move a little faster and go forward. Probably among the frequent PR submitters there's someone with enough experience (I'm not experienced enough to propose anyone directly).

Just my 2¢ of course 🙂

[beporter]

I've been doing my best to try to follow all of the separate forks and threads that are out there but I have to admit defeat:

Where can I go here in 2017 to either:

1. Download a pre-compiled GitX binary that is stable on Sierra?
2. Clone a repo and have the build instructions work?

😞

[tiennou]

@beporter Sadly, we still don't have pre-compiled GitX from gitx/gitx, but it should build and work on Sierra. You might have more success doing the build "the standard way", instead of listening to the wiki (IOW, open the workspace, "Build" using the Release configuration (or Debug, but ASan is enabled there and it's slightly slower), and copy the built product in your Applications folder.

[beporter]

I don't want this to turn into a troubleshooting thread, but since it might make good Google fodder:

On the command line, the error looks like this:

$ python --version
Python 3.6.1

$ Scripts/build.py build release
mvers: 0.15.2310 dev
vers:  0.15.2310
Setting CFBundleShortVersionString of project GitX to:
    0.15.2310 dev.

Updating CFBundleShortVersionString in Info.plist(s)...

Updated CFBundleShortVersionString in "GitX.xcodeproj/../Resources/Info-gitx.plist" to 0.15.2310 dev
Updated CFBundleShortVersionString in "GitX.xcodeproj/../Resources/Info.plist" to 0.15.2310 dev
Setting version of project GitX to:
    0.15.2310.

Also setting CFBundleVersion key (assuming it exists)

Updating CFBundleVersion in Info.plist(s)...

Updated CFBundleVersion in "GitX.xcodeproj/../Resources/Info-gitx.plist" to 0.15.2310
Updated CFBundleVersion in "GitX.xcodeproj/../Resources/Info.plist" to 0.15.2310


** BUILD FAILED **


The following commands produced analyzer issues:
	AnalyzeShallow Classes/Views/GitXTextFieldCell.m
(1 command with analyzer issues)

The following build commands failed:
	Ld /Users/me/Desktop/gitx/build/Release/ObjectiveGit.framework/Versions/A/ObjectiveGit normal x86_64
	GenerateDSYMFile /Users/me/Desktop/gitx/build/Release/ObjectiveGit.framework.dSYM /Users/me/Desktop/gitx/build/Release/ObjectiveGit.framework/Versions/A/ObjectiveGit
	Ld build/Release/gitx normal x86_64
	GenerateDSYMFile build/Release/gitx.dSYM build/Release/gitx
	CpResource build/Release/gitx build/Release/GitX.app/Contents/Resources/gitx
	Ld build/Release/GitX.app/Contents/MacOS/GitX normal x86_64
	GenerateDSYMFile build/Release/GitX.app.dSYM build/Release/GitX.app/Contents/MacOS/GitX
(7 failures)
error: Command '['xcrun', 'xcodebuild', '-workspace', 'GitX.xcworkspace', '-scheme', 'GitX', '-configuration', 'Release', 'build', 'BUILD_DIR=/Users/me/Desktop/gitx/build']' returned non-zero exit status 65.

When I try to build in Xcode, I get the following error:

error: cannot parse the debug map for 
"/Users/me/Library/Developer/Xcode/DerivedData/GitX-fjadmvsllzceyzagcehzhasxlkwr/Build/Products/Debug/ObjectiveGit.framework/Versions/A/ObjectiveGit": 
No such file or directory

I've tried both a Debug and a Release build, with Cleans in between. I've also read through the entire Build Instructions. I'd be quite happy to update the FAQ if we can find a solution to my problem. Thanks for the response!

[beporter]

Posted a solution comment: gitx/gitx#94 (comment)

[zuk]

Current build instructions from the wiki worked flawlessly for me on High Sierra. Thanks for your work on this guys — glad GitX is staying alive.

[szTheory]

I was able to build the latest commit on High Sierra 10.13.4 as of Mar 15, 2018, using instructions from @stepheneb here and here. Also, any plans to make this a Homebrew package or cask for easy, secure installs going forward?