[HN Gopher] GitHub Desktop 3.2: Preview your pull request
___________________________________________________________________
GitHub Desktop 3.2: Preview your pull request
Author : todsacerdoti
Score : 46 points
Date : 2023-03-03 19:00 UTC (4 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| coldblues wrote:
| Sublime Merge is still the best option so far (not Electron)
| steve_adams_86 wrote:
| Absolutely, what an excellent tool. One of those one-time
| purchases I almost wish was a subscription so I can be sure the
| team keeps working on it.
|
| I actually understand git better because of Merge. It's great
| because it provides a great interface into git, but it doesn't
| _hide_ git from you; it explains it quite a well.
|
| I suppose a newcomer to git might find Merge intimidating, but
| for anyone with a bit of experience I think it's quite an
| awesome power tool with a rare balance of handy abstraction and
| transparency around git itself.
| EduardoBautista wrote:
| Licenses are valid for three years of updates. So, it is a
| subscription, just a very long one with a fallback version
| when the subscription ends.
| steve_adams_86 wrote:
| I can't imagine the Sublime Merge version I have today
| won't still be super useful once my license expires, so for
| a lot of people, buying a new copy might not seem
| particularly compelling. It's also so cheap (or it was when
| I bought it) that it's waaayyyyy less expensive than any 3
| year subscription I've ever seen - something like $2/month.
| nkozyra wrote:
| Then the software isn't a subscription, the updates are.
| This is also kind of how the Jetbrains stuff works and it's
| far less user-hostile than making someone pay in perpetuity
| to simply use the software.
| hnbad wrote:
| Still no support for WSL and VSCode Remote with WSL tho, sadly.
| nusaru wrote:
| So basically, now we can do `git diff master` in a GUI. Hooray, I
| guess.
| netr0ute wrote:
| Why use nano when vi works just fine?
| nusaru wrote:
| I mean, if vi is what you prefer, more power to you.
| nkozyra wrote:
| I'm assuming the point was power tools versus very basic
| and more approachable ones, and I think there's a place for
| both. To use this example, I use vim most of the time but
| sometimes I jump into nano to do a quick edit on something.
|
| I don't love most of the GUI tools for git, but I use
| Sourcetree for 10,000 ft visualization and can't really
| parse CLI git --log graphs, even if they're heavily
| decorated.
| 2OEH8eoCRo0 wrote:
| Yeah, what we really need is yet _another_ electron app.
| ripplefringe wrote:
| I use Github Desktop. One thing I do like a lot is that the
| diff I see is exactly what my code reviewers will see.
|
| Personally, I spend a lot of time reviewing other's code ad
| also going through my own PR's in Github. I'm very familiar
| with that view. I think it helps my brain that I use the same
| diff view when I'm working locally and when I'm reviewing code
| on Github.
| u801e wrote:
| >> So basically, now we can do `git diff master` in a GUI.
|
| > One thing I do like a lot is that the diff I see is exactly
| what my code reviewers will see.
|
| What will they see in the diff that you can see using Github
| Desktop that you wouldn't see by running git diff master?
| randyrand wrote:
| The UI for the diff is actually useful though.
|
| Much easier to read and browse than a terminal.
| nusaru wrote:
| You're not wrong. Personally, I just used GitHub's web UI to
| preview my PRs, but I suppose having a local GUI makes it
| easier to amend commits and not have to force push changes.
| 2OEH8eoCRo0 wrote:
| Electron apps eat my ram and web UIs run like shit when
| backed by a large private instance.
| steve_adams_86 wrote:
| It was mentioned elsewhere but you might find Sublime
| Merge to be useful; it's not based on Electron, it's very
| fast, and it makes working with various git workflows a
| lot nicer (to me, at least).
| u801e wrote:
| I've found piping the output of git diff to my editor makes
| it much easier to browse compared to using the UI. For
| instance, searching for a particular file or line of code it
| much easier in the editor compared to the browser.
| david2ndaccount wrote:
| You can use `git difftool` to view the diff in your tool of
| choice (including gui editors).
| heydenberk wrote:
| If you get a lot of value out of the pull request view, you might
| enjoy adding partial committing to your workflow. Rather than
| committing entire directories or folders at a time, you can page
| chunk by chunk through uncommitted changes, committing only the
| ones you select. You'll easily spot those stray logging
| statements you don't want to commit. (You can also discard chunk
| at a time by using partial checkout/restore.) If you have, for
| example, two pairs of backend/frontend changes that you want to
| commit logically rather than simply according to their directory
| structure, partial committing is handy.
|
| It's just `git commit -p` (and `git checkout -p`). It's not
| exactly a deep cut, but I encourage people who are familiar but
| don't use it to give it a try.
| tomschlick wrote:
| You can commit line by line within Github Desktop and its a
| much nicer experience IMO than doing so via CLI. Its much
| easier to jump around to different files and commit related
| line changes in a bigger PR than jumping in and out of the
| patch command.
| Symbiote wrote:
| git gui
|
| which you probably already have if you use Linux also has
| this functionality.
| btown wrote:
| For those who want a GUI around this on Mac,
| https://rowanj.github.io/gitx/ is an incredible secret weapon.
| You can swipe over a bunch of lines or let the software
| identify a whole span of contiguous changed lines, click a
| button, and see just those changes move over from your unstaged
| to staged changes, then commit exactly what you want.
|
| A lot of times people don't even understand how powerful the
| staging area is; they're just used to saying git add && git
| commit without realizing that it can be an incredible way to
| take a day of chaotic fixes and turn it into a set of commits
| you can be proud of!
|
| It also provides an incredible tree view of commit parentage,
| perfect for when you need to instantly understand what happened
| with this weird merge/rebase that broke things, and to
| screenshare it to teach colleagues who might not have developed
| an internal understanding of the tree structure that Git is
| based on.
|
| The software is now 9 years old and abandoned, but I've used
| this specific fork at least weekly - often daily - for every
| one of those years, across Intel and M1 Macs, and it's never
| let me down!
| aldanor wrote:
| There's decent well maintained git ui clients for Mac, eg
| Fork
| iamcreasy wrote:
| Can you briefly explain what you meant by staging area is
| powerful?
| Rushsick wrote:
| I assume it's the fact that staging changes takes them out
| of your working tree. From there, a lot of git operations
| (diff, restore) will not include or modify the staged
| changes. This can help reason about logical chunks of code
| within a commit
| jonas-w wrote:
| According to this issue[0] there is a newer and maintained
| version of gitx.
|
| [0] https://github.com/rowanj/gitx/issues/481
| steve_adams_86 wrote:
| Interesting, I knew of `git add -p` (which I then use to `git
| commit -m ...`, but it looks like I could add all changes and
| _then_ decide what to commit. I think I'd still use `add -p` (I
| like being thorough), but I like that I can add all at once and
| then make partial commits based on specific change sets.
|
| Thanks for pointing this out, I feel like git is the thing I
| should know best by now yet I'm missing so much of what it can
| do. It's great to see others' workflows.
| tracker1 wrote:
| I've tended to have a similar workflow... but since I use VS
| Code mostly, then I do use the git tab a lot for previewing
| changes before committing them. Other than that, I've mostly
| avoided using any GUI for git, mostly because I find it
| annoying. I'll say that the Github client and the VS Code
| integrations for Github have come a long way all the same for
| those that use and like them.
| tomodachi94 wrote:
| This functionality is built-in to vim-fugitive and VS Code.
|
| In Fugitive, open it with :Git , select the unstaged file then
| press = . Select the desired range with visual mode, then press
| s and commit as normal.
|
| In VS Code, select a hunk, press Ctrl+P, then type "Stage
| Selected Range." Repeat this process and commit as normal.
|
| Edit: formatting and typo.
| _hao wrote:
| Seems to compare quite poorly to GitKraken (which I realize is
| paid, but it's really good).
| nixpulvis wrote:
| GitHub desktop/mobile apps have been the worst thing to happen to
| GH since / along with the acquisition.
|
| The website is being neglected, (especially on mobile) which is
| the primary value the service has for me. If I have `git` I
| really don't need GitHub except to view comments.
|
| Ironically, notifications and comment management is still pretty
| bad.
|
| Don't get me wrong, I still think GitHub is the best at what they
| do, but like many incumbents, I feel like they are losing a bit
| of what makes them so great.
|
| Polish up the features you have, we don't need endless feature
| releases, we need smooth features we know and love.
| nightpool wrote:
| "The website is being neglected"--really? Compared to their
| complete feature freeze pre-acquisition, new Github platform
| features come out regularly (WIP PRs, code owners, the entire
| Actions and Codespaces products, and Merge Queue being the most
| recent one). I've never used Github Desktop, but the idea that
| the website is being neglected just doesn't make any sense to
| me.
| joshcanhelp wrote:
| Completely disagree. The desktop app helps me greatly to create
| digestible commute and PRs. I use the command line for 99% of
| the actions I take but the desktop app gives me a much better
| visual of my changes and has helped me catch unintended (or
| temporary) changes many times.
|
| On the website, the Notification Center has gotten better,
| linked methods is very helpful, code spaces are very cool
| (though I haven't gone deep on them), repo redesign is great
| ... IMHO, only gotten better.
| nixpulvis wrote:
| I'm just saying that they should be focused on the webapp,
| not slowly abandoning it and making us use the native apps.
| bastardoperator wrote:
| Facts over perception, go look at changelog, look at
| primer... The Web UI gets new features almost daily.
| nixpulvis wrote:
| You're missing my point. I don't want all the new
| features. I want the existing ones taken care of and
| polished.
| thrashh wrote:
| As someone who has built GUI wrappers for perfectly working
| tools, it's because support is a nightmare.
|
| There's a subset of your users who aren't going to invest in
| learning your existing tools but you still want them to use
| your product.
|
| You can't write more documentation because the more
| documentation there is, the less people will read it. You can't
| tell them to ask for support because they'll just flood you and
| eventually give up.
|
| So you build a GUI for these users and they're happy and you're
| happy. Your expert users won't understand, will complain that
| you're wasting your time, but that's a price worth paying.
| motoxpro wrote:
| Github Desktop is the best thing to happen to GH for me. Makes
| my workflow so much nicer.
| slugiscool99 wrote:
| The worse thing to happen to GH? Really?
|
| Using git on the command line can be hard to learn and
| unintuitive for people - the desktop client makes things easier
| and that's a good thing (kind of like how the GUI made
| computers accessible to more people and ended up benefiting
| everyone in software...)
| tracker1 wrote:
| TBH, I felt the same way for a while... but I found that I
| really only need to actually remember a handful of things..
| git add, git commit, git pull --rebase, and the git rebase -i
| HEAD~N
|
| Other than those, when I need something I don't typically
| use, I have google. And most of those instances where it's
| not one of the commands above, the UI is usually pretty bad
| anyway. I do like the preiew/diff in VS Code a lot though on
| the git tab.
|
| I do wish there was a way to post-operate on the most recent
| commit (uncommit) via the gui though. I tend to work in a
| branch, regularly squashing and rebasing against upstream
| branch... then would prefer to be able to (via gui) uncommit
| the most recent commit, just so I can preview/edit a final
| pass at once. That is about the only workflow that I
| sometimes want/need that isn't really in the box, or
| otherwise more of a pain in the UI anyway.
| ocdtrekkie wrote:
| I would use more non-GitHub solutions if they had GitHub
| Desktop or equivalent. The number of accidental commits I've
| seen by long term industry experts demonstrates that command
| line isn't always the best for all things. I _generally_ avoid
| opening PRs on machines I don 't have Desktop, which is why
| it's such an embarrassment GitHub has refused to publish an
| official Linux version, despite an employee maintaining one for
| years.
___________________________________________________________________
(page generated 2023-03-03 23:02 UTC)