vc for git users.

vc for git users.

[Ergus]

Hi:

Considering that in these days 90% of the users who use version control
systems are git users. I was recommending to some friends to use the
native vc inside emacs when they were outside their machine (so no magit
installed) But after a while I found that the vc documentation is so
generic that it is not clear got a git user how to do a simple task like
creating a commit.

Could anyone provide like a small set of commands in vc that perform
frequent git operations, but with no intuitive names? Ex: commit, add,
status.

Should we consider to add such a documentation (like an annex) in the
emacs manual?

Re: vc for git users.

[Pankaj Jangid]

Ergus <spacibba@aol.com> writes:

> Could anyone provide like a small set of commands in vc that perform
> frequent git operations, but with no intuitive names? Ex: commit, add,
> status.
>
> Should we consider to add such a documentation (like an annex) in the
> emacs manual?
>
Agree. Instead of annex, this should be considered in git specific
subsection somewhere. This could be done for any other tool also not
only for git.

-- 
Pankaj Jangid

Re: vc for git users.

[Eli Zaretskii]

> Date: Mon, 28 Oct 2019 15:21:07 +0100
> From: Ergus <spacibba@aol.com>
> 
> Could anyone provide like a small set of commands in vc that perform
> frequent git operations, but with no intuitive names? Ex: commit, add,
> status.

There should be only one: "C-x v v".  If that's not enough, it's a
bug, IMO.

Re: vc for git users.

[Skip Montanaro]

>
> There should be only one: "C-x v v".  If that's not enough, it's a
> bug, IMO.
>

Agreed. The basic idea of vc is to provide a uniform user interface across
multiple version control systems.

Skip

>

Re: vc for git users.

[VanL]

Skip Montanaro <skip.montanaro@gmail.com> writes:

>> There should be only one: "C-x v v".
>> If that's not enough, it's a bug, IMO.
>>
>
> Agreed. The basic idea of vc is to
> provide a uniform user interface across
> multiple version control systems.

I prefer the built-in generic vc interface
to git after first using Magit for some
time.

Two key sequences to explore after "C-x v v" are:

1) C-x v g
2) C-x v C-h

-- 
© 2019 VanL
gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
          'If the bug bites,don't fight it.' - Nancy S. Steinhardt

Re: vc for git users.

[Eric S Fraga]

On Tuesday, 29 Oct 2019 at 10:40, VanL wrote:
> I prefer the built-in generic vc interface
> to git after first using Magit for some
> time.

In my case, although I really like magit, I use more than one version
control system: hg, git, src.  Having a consistent interface (vc-*) wins
in the end.  I don't have to remember what vc system I am using for any
individual file and it works well in general.

-- 
Eric S Fraga via Emacs 27.0.50 & org 9.2.6 on Debian bullseye/sid

Re: vc for git users.

[Ergus via Users list for the GNU Emacs text editor]

I was referring more to the terminology in the documentation, not the functionality. Only by reading the documentation a git user can't understand what means "next action". Or can't find if it is possible to stage changes (or even if it is needed). There are also some git specific interactive functions I didn't find the documentation for them.

It looks like the documentations and functions were actually written for older VCS with different terminologies/steps/workflows. Not common anymore in git or mercurial.

On October 28, 2019 5:16:19 PM GMT+01:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 28 Oct 2019 15:21:07 +0100
>> From: Ergus <spacibba@aol.com>
>> 
>> Could anyone provide like a small set of commands in vc that perform
>> frequent git operations, but with no intuitive names? Ex: commit,
>add,
>> status.
>
>There should be only one: "C-x v v".  If that's not enough, it's a
>bug, IMO.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: vc for git users.

[Eli Zaretskii]

> Date: Tue, 29 Oct 2019 03:42:21 +0100
> From: Ergus <spacibba@aol.com>
> 
> I was referring more to the terminology in the documentation, not the functionality. Only by reading the
> documentation a git user can't understand what means "next action".

Of course.  But the same is true for every non-trivial Emacs command,
isn't it?  For example, "C-x `", a.k.a. "next-error".  Why do you
expect VC commands to be more self-explanatory?

> Or can't find if it is possible to stage changes (or even if it is
> needed).

Staging is Git-specific.  VC doesn't support that, at least not
AFAIK.  VC does the staging when necessary behind the scenes.  The
user only sees the "commit" operation.

> There are also some git specific interactive functions I didn't find the
> documentation for them.

Which functions are those?

> It looks like the documentations and functions were actually written for older VCS with different
> terminologies/steps/workflows. Not common anymore in git or mercurial.

Are you sure?  I see the modern VCSes described in the VC chapter.  We
actually made an effort a few years back to describe the modern
systems before the older ones.  Of course, there could always be ways
to improve the documentation, but the general assertion that the
manual is written for old VCS systems is factually incorrect.

Bottom line, I don't understand the specifics of the complaint.
Perhaps you have in mind a user who wants to find an Emacs command for
every Git command they are familiar with: vc-push for pushing, vc-pull
for pulling, vc-merge for merging, vc-blame, vc-cherry-pick, etc.  But
VC doesn't work that way, it attempts to abstract common VCS
operations and provide a unified UI that depends on specific VCS
features as little as practically possible.  That has a disadvantage:
you need to learn the VC concepts and commands before you can use them
efficiently, but the significant advantage is that once you learned
them, you can use them with any supported VCS.

Re: vc for git users.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Bottom line, I don't understand the specifics of the complaint.

I tried explaining Emacs' git support through vc was the other day, and
he just couldn't wrap his head around how easy Emacs makes it.  "But...
but...  staging...  the index...  how...  wha..."  When you're finally
proficient in a nigh-incomprehensible tool like command line git, it
sounds as if something's missing in Emacs somehow.

So I think it might make some sense to write some text that explains
that, indeed, `C-x v v' makes most of that just go away -- you don't
have to think explicitly in those git terms.  And `M-x vc-dir' takes
care of the rest.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: vc for git users.

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <lmi@gnus.org>
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 29 Oct 2019 14:59:28 +0100
> 
> I tried explaining Emacs' git support through vc was the other day, and
> he just couldn't wrap his head around how easy Emacs makes it.  "But...
> but...  staging...  the index...  how...  wha..."  When you're finally
> proficient in a nigh-incomprehensible tool like command line git, it
> sounds as if something's missing in Emacs somehow.

Yes, Git is brainwashing us.

> So I think it might make some sense to write some text that explains
> that, indeed, `C-x v v' makes most of that just go away -- you don't
> have to think explicitly in those git terms.

Wouldn't that explanation just repeat what we say in "Basic VC
Editing"?

Re: vc for git users.

[Dmitry Gutov]

On 29.10.2019 16:18, Eli Zaretskii wrote:
>> From: Lars Magne Ingebrigtsen<lmi@gnus.org>
>> Cc:help-gnu-emacs@gnu.org
>> Date: Tue, 29 Oct 2019 14:59:28 +0100
>>
>> I tried explaining Emacs' git support through vc was the other day, and
>> he just couldn't wrap his head around how easy Emacs makes it.  "But...
>> but...  staging...  the index...  how...  wha..."  When you're finally
>> proficient in a nigh-incomprehensible tool like command line git, it
>> sounds as if something's missing in Emacs somehow.
> Yes, Git is brainwashing us.

I don't think it's fair. Git provides good tools. Just the other day I 
was thinking of how to commit only a part of changes in a file. Git 
makes it easy with 'git add -p', using the staging area.

Not sure what the closest VCS-neutral approach would be. Selecting 
chunks somehow in a vc-diff buffer?

Re: vc for git users.

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 29 Oct 2019 17:31:47 +0200
> 
> > Yes, Git is brainwashing us.
> 
> I don't think it's fair. Git provides good tools.

That's orthogonal.  The "brainwashing" part is about breaking too many
mental models the other VCSes follow, and adding too many concepts
that are unique to Git.

> Just the other day I was thinking of how to commit only a part of
> changes in a file. Git makes it easy with 'git add -p', using the
> staging area.
> 
> Not sure what the closest VCS-neutral approach would be. Selecting 
> chunks somehow in a vc-diff buffer?

No, the VCS-neutral approach is let you commit only the part of the
changes you want.  The backend could stash the rest, or use "git add",
or whatever.

Re: vc for git users.

[Stefan Monnier]

> Not sure what the closest VCS-neutral approach would be.

Back in PCV-CVS days I had a `vc-start-partial-checkin`
which would copy the current buffer's file to <filename>.~vc-ppci~ and
setup had an after-commit hook which reverted to the saved
<filename>.~vc-ppci~ copy.

So I used M-x vc-start-partial-checkin RET, then used diff-mode and
direct editing to undo the parts I didn't want to commit yet, then did
the C-x v v.

I still think it's a pretty convenient workflow since you're not limited
to a hunk granularity.  I often do the same by hand nowadays:
- git stash
- vc-git-stash-show
- from the *vc-diff*, re-apply the parts I want
- commit
- git stash apply+drop


        Stefan

Re: vc for git users.

[Steinar Bang]

>>>>> Dmitry Gutov <dgutov@yandex.ru>:

> I don't think it's fair. Git provides good tools. Just the other day I
> was thinking of how to commit only a part of changes in a file. Git
> makes it easy with 'git add -p', using the staging area.

(last Friday I, mostly by accident, discovered that magit supports 'git
add -p': go to the diff buffer (ie. 'd d' with the cursor on a file with
changes) and stage the indivdual hunks https://stackoverflow.com/a/1096508)

> Not sure what the closest VCS-neutral approach would be. Selecting
> chunks somehow in a vc-diff buffer?

That descibes the magit approach.  But having no concept of staging
would make it hard to implement.

Re: vc for git users.

[Štěpán Němec]

On Tue, 29 Oct 2019 19:00:17 +0100
Steinar Bang wrote:

> (last Friday I, mostly by accident, discovered that magit supports 'git
> add -p': go to the diff buffer (ie. 'd d' with the cursor on a file with
> changes) and stage the indivdual hunks https://stackoverflow.com/a/1096508)

You can (in Magit) also use region to select the parts you want to
stage; the minimal granularity is line, not hunk.

-- 
Štěpán

Re: vc for git users.

[Marcin Borkowski]

On 2019-10-29, at 19:00, Steinar Bang <sb@dod.no> wrote:

>>>>>> Dmitry Gutov <dgutov@yandex.ru>:
>
>> I don't think it's fair. Git provides good tools. Just the other day I
>> was thinking of how to commit only a part of changes in a file. Git
>> makes it easy with 'git add -p', using the staging area.
>
> (last Friday I, mostly by accident, discovered that magit supports 'git
> add -p': go to the diff buffer (ie. 'd d' with the cursor on a file with
> changes) and stage the indivdual hunks https://stackoverflow.com/a/1096508)

Do you know that you can mark selected lines and stage a region, too?

Best,

--
Marcin Borkowski
http://mbork.pl

Re: vc for git users.

[Robert Pluim]

>>>>> On Wed, 30 Oct 2019 10:34:27 +0100, Marcin Borkowski <mbork@mbork.pl> said:

    Marcin> On 2019-10-29, at 19:00, Steinar Bang <sb@dod.no> wrote:

    >>>>>>> Dmitry Gutov <dgutov@yandex.ru>:
    >> 
    >>> I don't think it's fair. Git provides good tools. Just the other day I
    >>> was thinking of how to commit only a part of changes in a file. Git
    >>> makes it easy with 'git add -p', using the staging area.
    >> 
    >> (last Friday I, mostly by accident, discovered that magit supports 'git
    >> add -p': go to the diff buffer (ie. 'd d' with the cursor on a file with
    >> changes) and stage the indivdual hunks https://stackoverflow.com/a/1096508)

    Marcin> Do you know that you can mark selected lines and stage a region, too?

You donʼt even need to run 'd d', you can uncollapse the file diff in
the magit buffer, and do it from there.

Robert

Re: vc for git users.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> So I think it might make some sense to write some text that explains
>> that, indeed, `C-x v v' makes most of that just go away -- you don't
>> have to think explicitly in those git terms.
>
> Wouldn't that explanation just repeat what we say in "Basic VC
> Editing"?

It would, but with a different emphasis (i.e., mention that there's no
separate "staging" step and so on).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no