31–40 of 143 posts
A very satisfied user. As a (neo)vim user, I did suffer from magit envy but at the end, Lazygit takes care of all my needs. I prefer the UX (Just a personal preference). Kudos to the dev for the wonderful tool PS: There is also lazydocker by same person https://github.com/jesseduffield/lazydocker
Earlier quoted context omitted.
As far as I have seen (I prefer the cmdline myself) Git UIs usually have all sorts of features to select what changes should go into what commits down to single text lines. IMHO this sort of fine grained 'commit management' would be the only reason to use a git UI over what the command line offers.
`git add -p` does that as well, it's effectively what the GUIs are using. You can also [e]dit each thing and rewrite as desired, though it can be a bit fiddly. UIs can be nicer though for rewriting / making finer-grained splits than the hunks that -p decides on, definitely agreed there. I have broken out a UI just to simplify staging some gnarly commits. GUIs are also often nicer for understanding and resolving nasty…
Earlier quoted context omitted.
Exactly the opposite for me. I absolutely do not trust GUIs to do the right thing. I don't trust text area to use correct line endings consistently across platforms, I don't trust them to be up to date with new options for `commit` or `checkout`, they never show examples what result will be (--dry-run). None GUI is ever up to date with documentation and contains all functionality which I can autocomplete with [tab][t…
Literally every git GUI I've used has screwed up a git repository at some point, requiring relatively-advanced CLI use to untangle it. They're wildly untrustworthy IMO. They also almost never perform reasonably on truly large repos, aside from gitk. Since using a GUI has inevitably required me to learn CLI in depth, and adds the complexity of figuring out what the hell the GUI actually did because of course it doesn'…
I got burnt by this with svn... when unfucking things was a lot more complicated and required faster disk and connection.
Earlier quoted context omitted.
Exactly the opposite for me. I absolutely do not trust GUIs to do the right thing. I don't trust text area to use correct line endings consistently across platforms, I don't trust them to be up to date with new options for `commit` or `checkout`, they never show examples what result will be (--dry-run). None GUI is ever up to date with documentation and contains all functionality which I can autocomplete with [tab][t…
Literally every git GUI I've used has screwed up a git repository at some point, requiring relatively-advanced CLI use to untangle it. They're wildly untrustworthy IMO. They also almost never perform reasonably on truly large repos, aside from gitk. Since using a GUI has inevitably required me to learn CLI in depth, and adds the complexity of figuring out what the hell the GUI actually did because of course it doesn'…
I always use(d) the terminal, but Fork is the first time I am considering using a GUI as my main tool.
Granted I haven't had to do anything complicated yet with it, so I don't know if it supports it, but I love it for the basic day-to-day tasks that I do 100's of times a week.
Earlier quoted context omitted.
`git add -p` does that as well, it's effectively what the GUIs are using. You can also [e]dit each thing and rewrite as desired, though it can be a bit fiddly. UIs can be nicer though for rewriting / making finer-grained splits than the hunks that -p decides on, definitely agreed there. I have broken out a UI just to simplify staging some gnarly commits. GUIs are also often nicer for understanding and resolving nasty…
I very much agree to this. I almost always use “git add -p”.
distributed VCS is neat and all, but the vast, vast majority of cases have a canonical source-of-truth repo somewhere, and the rest are effectively just private mirrors. for those cases, distributed is mostly a significant source of complexity rather than capability. though it is significant to have an "escape hatch" when you need it.
Earlier quoted context omitted.
Literally every git GUI I've used has screwed up a git repository at some point, requiring relatively-advanced CLI use to untangle it. They're wildly untrustworthy IMO. They also almost never perform reasonably on truly large repos, aside from gitk. Since using a GUI has inevitably required me to learn CLI in depth, and adds the complexity of figuring out what the hell the GUI actually did because of course it doesn'…
I found this to be true for a long time, but these days you have something like Fork which is much lore user friendly and FAST! We used to use Sourcetree, which is an abomination in comparison. I always use(d) the terminal, but Fork is the first time I am considering using a GUI as my main tool. Granted I haven't had to do anything complicated yet with it, so I don't know if it supports it, but I love it for the basi…
And agreed on Sourcetree. It started out promising, but oof. Not any more.
Jesse you're leaking email addresses in your interactive rebasing example animated gif.
Earlier quoted context omitted.
As far as I have seen (I prefer the cmdline myself) Git UIs usually have all sorts of features to select what changes should go into what commits down to single text lines. IMHO this sort of fine grained 'commit management' would be the only reason to use a git UI over what the command line offers.
`git add -p` does that as well, it's effectively what the GUIs are using. You can also [e]dit each thing and rewrite as desired, though it can be a bit fiddly. UIs can be nicer though for rewriting / making finer-grained splits than the hunks that -p decides on, definitely agreed there. I have broken out a UI just to simplify staging some gnarly commits. GUIs are also often nicer for understanding and resolving nasty…
If there is one thing that terrifies me it's using Git, or any source control, from the command line. No matter how long I've been in this industry, I just can't get cozy with doing a lot of heavy lifting in any shell environment. Give me the GUI all day every day.
if you know the bare basics of emacs(like a few file commands and how to exit), magit and vim that is a huge productivity win. magit is simply the finest complete git gui that does most things seamlessly.
simple workflow
in the project dir
$ emacs
spc-g-g to enter magit
? shows help(and every command pops up a menu with options)
j/k to navigate lines up and down
s and u to stage and unstage chunks of text/files/lines
x to delete something
cc to initiate a commit
edit the commit message
ctrl-c ctrl-c commit.
ctrl-c ctrl-c abort commit
q or escape goes back a "page" like from viewing the log to go back to the staging area
the trick is everything follows that basic form where [a-zA-Z] starts a command, pops up a menu and shows the next options but the general trend is that it usually is the same two letters. bb is checkout a branch and it usually pre-populates the thing you are on if that is applicable. ll is log this branch. la is log all branches and everything in the log is interactive.
it's pretty magical.