51–60 of 66 posts
Can this stage individual lines, and then display a view of only staged lines and no un-staged lines? AKA only the things you are about to commit. In SourceTree this is called "split view staging" and I find it indispensable. But SourceTree is so old as slow and unsupported that I'm desperately trying to find an alternative. Most of the existing GUI clients don't have this option.
How would I get this to run on MacOS?
$ qmake && make
Is anyone aware of a publicly available code base to look into when searching for high quality Qt-based (desktop) applications? Think chromium-quality software quality code base. I am looking for inspiring patterns and also things such as naming schemes as I regularly change my mind when it comes to developing Qt based applications with regard to: - naming things (e.g. should signals/slots be prefixed (sigFoo() -> on…
There's an irony somewhere in there that Chromium is a descendant of KHTML, KDE's rendering engine, which became WebKit and was originally written using Qt. And Google and Apple's contributions were regularly derided for being relatively low quality.
Qt and KDE have always had a lot of cross-contribution, so KDE (its libraries, for example) is a good place to start:
https://github.com/KDE/kdelibs
There's also this old, but still relevant, article on designing Qt-style APIs (which had a big impact on me personally):
Can this stage individual lines, and then display a view of only staged lines and no un-staged lines? AKA only the things you are about to commit. In SourceTree this is called "split view staging" and I find it indispensable. But SourceTree is so old as slow and unsupported that I'm desperately trying to find an alternative. Most of the existing GUI clients don't have this option.
SublimeMerge[1] allows staging only chunks of files. [1]: https://www.sublimemerge.com/
Not super discoverable but pretty useful.
This looks cool. I'm curious if people use Git's tree view, in any form, as part of the regular workflow? If so, how? I have never found it useful, intuitive, or usually readable / parsable. Not the graph drawn on the command line, certainly not Github's tree view GUI of forked projects. I've also only ever worked on a project with one or two main trunk branches (master, and maybe dev), and feature branches, and very…
One example: I work on a feature, which necessitates some refactoring, maybe upgrading a dependency, and oh, while I'm in the middle of it I notice some other, unrelated things, that need changing. In order to not have to break my flow and think too much about which changes are required for what, I just commit it all on the same local branch.
This then gets broken up into different branches in individual PRs.
This looks cool. I'm curious if people use Git's tree view, in any form, as part of the regular workflow? If so, how? I have never found it useful, intuitive, or usually readable / parsable. Not the graph drawn on the command line, certainly not Github's tree view GUI of forked projects. I've also only ever worked on a project with one or two main trunk branches (master, and maybe dev), and feature branches, and very…
I use it as part of my daily flow. One example: I work on a feature, which necessitates some refactoring, maybe upgrading a dependency, and oh, while I'm in the middle of it I notice some other, unrelated things, that need changing. In order to not have to break my flow and think too much about which changes are required for what, I just commit it all on the same local branch. This then gets broken up into different…
Earlier quoted context omitted.
I use it as part of my daily flow. One example: I work on a feature, which necessitates some refactoring, maybe upgrading a dependency, and oh, while I'm in the middle of it I notice some other, unrelated things, that need changing. In order to not have to break my flow and think too much about which changes are required for what, I just commit it all on the same local branch. This then gets broken up into different…
I don't understand what this has to do with a visual view of branches and merges
Oh, and re Githubs fork view (which could be improved on the UI side), is helpful when seeing if anyone else has picked up the ball on unmaintained repos.
If you don't find it useful, fine, I don't think we all need to grok each others personal workflows and motivate them to each other?
Maybe you can compare it to a visual file manager that visualizes your directory structure as a tree; some people find it a necessity to get an overview of their file system, some don't.
Nice, good job, specially for going with Qt instead of Electron.
EVen thought I understand the bashing Electron gets, it doesn't seem that Qt is the right choice right now. I tried to test the software: Needed Qt as there are no releases, but Qt is behind a paywall, and according to a previous post here in HN [1] it seems they resorted back to tactics they already reckoned (In 2015) were not good. I guess I'll just have to wait until the page has the releases ready. [1] https://ne…
This probably the less mobile friendly website I've seen in a while! I'll have to check it in my laptop later on.
Earlier quoted context omitted.
JFTR, Also take a look on Guitar [0] - another Qt-based Git GUI client. I actually use Guitar, but GitQlient is also installed on my PC. [0] https://github.com/soramimi/Guitar
What does GitQlient do that Guitar, QGit, CodeReview, GitAhead, or git-cola do not?
I couldn't find a way to do that in QGit and GitAhead at least. I didn't try the others.