Updated CFBundleVersion in 'GitX.xcodeproj/./Resources/ist' to Updated CFBundleShortVersionString in 'GitX.xcodeproj/./Resources/ist' to devĪlso setting CFBundleVersion key (assuming it exists) Updated CFBundleShortVersionString in 'GitX.xcodeproj/./Resources/ist' to dev

Updating CFBundleShortVersionString in ist(s). Setting CFBundleShortVersionString of project GitX to: 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). I can obviously rebase my work (which is switching GTIndex to use libgit2 directly). 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. 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. 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. Libgit2 is mostly-compatible with shallow repositories (eg. 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).Īnd 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). 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.

My rationale is that I'm not fond of blanket-fetching the repository, because it is shallow for a reason. 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.Īfter that point, I'm cautious about the stuff that touches shallow repositories in 97f2e2c. 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. Direct pull requests would have many who could act on them, reducing the time to get a release out there. A place where could have had an active participation without feeling he is carving yet another corner in the already crowded GitX history.įor example, we would point right at the beginning of the README page to all the relevant existing repos ( etc.) where fixes are drawn from.

Bottlenecks on a single person’s schedule can be removed since others can easily take overĬonsider it an aggregator, if you will.

Any major changes in direction can be discussed and agreed as a group.

People collect and merge patches/fixes waiting in the sidelines of the other repos.

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:

Gitx for linux