lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Git vs Vim Fugitive (was: valyuta/002 18ab8be 5/5: Oops)


From: Vadim Zeitlin
Subject: Re: [lmi] Git vs Vim Fugitive (was: valyuta/002 18ab8be 5/5: Oops)
Date: Mon, 21 Sep 2020 17:25:57 +0200

On Mon, 21 Sep 2020 01:07:36 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> The best solution to merge conflicts is to avoid them,

 This is akin to saying that the best solution for having clean history is
to never make mistakes and always choose the right approach from the
beginning: both statements are true, of course, but just not particularly
helpful... Whenever you try something first, then (but not immediately,
but only after making some more changes) realize that it could be done
better and replace it with something else and then, finally, try to rebase
it, you're almost invariably going to have some conflicts.

GC> I assume "git-add-p" means the same as "git add --patch".
GC> I use it so often that I've even memorized some of the
GC> single-letter subcommands. I tried 'fugitive'; I watched
GC> the vimcast about it; and still I don't like it. My issue
GC> has nothing to do with the plug-in's quality. Rather, it's
GC> a matter of eyesight. I can comfortably use a single 27x90
GC> text window at most. Splitting windows is really not a
GC> solution for me, simply because thirteen lines or forty-five
GC> columns is too small.

 Yes, this is indeed a problem because without (vertically) splitting the
windows Fugitive isn't very useful. I do wonder if this couldn't be fixed
by just buying a wide monitor: I hate them, because I prefer having more
vertical space, but there are many "ultrawide" (21:9 or more) monitors
nowadays, and their resolution of 3440x1440 (or more) should allow you to
comfortably have 160+ columns of text even in a very large font.

GC> Consider these few lines chosen from my command history:
GC> 
GC> git diff --patch `git rev-parse valyuta/000` -- ihs_avmly.cpp

 If you don't mind my nitpicking, this command is rather redundant and
could have been written as

        git diff valyuta/000 -- ihs_avmly.cpp

instead: "--patch" is the default behaviour (i.e. it's only useful to use
it with something like "--stat", which would normally suppress the patch
generation) and git-rev-parse is just redundant because all git commands,
including git-diff, will already use it internally anyhow for their
'committish" arguments.

GC> I do understand at least some of what git has to offer.
GC> If your concern is that I'm not taking advantage of
GC> git's features, then tell me I'm missing. But if one
GC> knows how to use git, then 'fugitive', AFAICT, adds
GC> nothing--it's just an alternative way of doing the same
GC> things, which for me is more cumbersome than working in
GC> a terminal window.

 I find "git add -p" and "git reset -p" much more clunky than using
Fugitive, if only because they're sequential, while Fugitive provides
"random access" to the patch being composed. I remember it only vaguely,
because I haven't used these options of these commands for a very long
time, but I think it was pretty aggravating to forget to add some hunk in
the middle of the file, as you had to start anew and ignore all the
previous ones before being finally able to add it.

 Also, Fugitive is a Vim plugin, i.e. you have all the features of Vim at
your disposal when using it. In particular, I frequently find it very
convenient to edit the index text directly: this is much simpler than
editing the diff directly, which is what Git interactive commands allow to
do.

 But, to answer your question, Fugitive "Gdiff" command is indeed
functionally equivalent to "git {add,reset} -p", even though it is
incomparably easier to use. The only Fugitive command which can't be
directly mapped to a Git command at all is "Gblame": the difference with
"git blame" is that in the blame window you can press a single key to
rerun git-blame at the parent of the currently chosen commit. This means
that you can easily drill into the history of any line, instead of having
to rerun git-blame manually many times. IME this is really invaluable.

 Regards,
VZ

Attachment: pgp0y7PueKWaI.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]