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.
#Gitx 10.13 drivers#
"dont use web drivers or cuda drivers no need to install"
#Gitx 10.13 install#
Restart pc and select from clover Install macOS High Sierra install 2 partition on SDD use format bfore install jurnal and use name "HighSierra"įrom clover select install from HighSierra i think in 20 sec make one reboot.Īgain from clover select install from HighSierra in 8-10 min finish install +. Make sure you use boot disk from efi at start On samsung ssd is setup Partition 1 is very faster from usb. no injectĪfter install in partition 1 8gb HighSierra 10.13 open with clover and mount EFI. Install last ver UniBeast + image OS HighSierra 10.13 on partition 1 8gb. Make 1 partition on SSD 8gb for faster setup. Building a CustoMac Hackintosh: Buyer's GuideĬlean install 10.13.
0 kommentar(er)
