How to switch Git branches with VC?

How to switch Git branches with VC?

[Eli Zaretskii]

It sounds like there's no command (except M-!) to do that.  Did I miss
something?

Re: How to switch Git branches with VC?

[Dmitry Gutov]

Eli Zaretskii <eliz@gnu.org> writes:

> It sounds like there's no command (except M-!) to do that.

`C-x v r' works okay for this, at least with vc-git.

Re: How to switch Git branches with VC?

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: emacs-devel@gnu.org
> Date: Tue, 18 Nov 2014 21:15:11 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It sounds like there's no command (except M-!) to do that.
> 
> `C-x v r' works okay for this, at least with vc-git.

Thanks.

Talk about obfuscation: a command that's called "retrieve-tag" doesn't
retrieve anything and is normally unrelated to tags!

I pushed to the emacs-24 branch some documentation changes that should
serve as stopgap.  But I really think we should have a set of VC
commands that deal with branches: create them, switch to them, remove
them, etc.  That the command to switch to a branch and to an arbitrary
commit or tag is the same with some VCSes is sheer luck: other VCSes
don't fit in this scheme, and require different commands and different
options for them.

Re: How to switch Git branches with VC?

[Dmitry Gutov]

On 11/19/2014 08:39 PM, Eli Zaretskii wrote:

> Talk about obfuscation: a command that's called "retrieve-tag" doesn't
> retrieve anything and is normally unrelated to tags!

Yep, I certainly didn't mean that the situation is ideal.

> I pushed to the emacs-24 branch some documentation changes that should
> serve as stopgap.

Looks good to me.

> But I really think we should have a set of VC
> commands that deal with branches: create them, switch to them, remove
> them, etc.

Indeed. Maybe less related, but we could also use a 'merge' command and 
an 'amend' command (which is a fairly normal action when working on a 
branch, and will become more important when change logs are generated 
from commit messages).

Re: How to switch Git branches with VC?

[Eli Zaretskii]

> Date: Thu, 20 Nov 2014 18:00:36 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> > But I really think we should have a set of VC
> > commands that deal with branches: create them, switch to them, remove
> > them, etc.
> 
> Indeed. Maybe less related, but we could also use a 'merge' command and 
> an 'amend' command (which is a fairly normal action when working on a 
> branch, and will become more important when change logs are generated 
> from commit messages).

Agreed.  Any takers?

Re: How to switch Git branches with VC?

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > Date: Thu, 20 Nov 2014 18:00:36 +0200
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > CC: emacs-devel@gnu.org
> > 
> > > But I really think we should have a set of VC
> > > commands that deal with branches: create them, switch to them, remove
> > > them, etc.
> > 
> > Indeed. Maybe less related, but we could also use a 'merge' command and 
> > an 'amend' command (which is a fairly normal action when working on a 
> > branch, and will become more important when change logs are generated 
> > from commit messages).
> 
> Agreed.  Any takers?

See my previous post.  This is clearly my pigeon, and now that we've
switched VCSes I can be much more active.

I don't have current plans to fix merging, but I at least know what
needs to be done about branching.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Inadequate branch support in VC

[Eric S. Raymond]

Dmitry Gutov <dgutov@yandex.ru>:
> >But I really think we should have a set of VC
> >commands that deal with branches: create them, switch to them, remove
> >them, etc.
> 
> Indeed. Maybe less related, but we could also use a 'merge' command
> and an 'amend' command (which is a fairly normal action when working
> on a branch, and will become more important when change logs are
> generated from commit messages).

I missed Dmitri's original post, but it happens I was looking at this
part of VC just hours ago.  Motivation - I'm writing a VC back end for SRC,
and this required me to get re-acquainted with the front-end/back-end
interface.

In brief, it's a pretty messy pile.

The sort of good news: there is an amend capability.  Nothing newer than
svn supports it, though - in particular, the git back end could but does not.
(SRC wlll support it.)  It's accessed through log-view, which is ... even
more confusing than the rest of the code.

As regards branching, there was an attempt to support it directly in
just two back ends (CVS and RCS) as a bag on the side of the checkin
capability, but nothing in VC actually exercised that code.  I removed 
the unused cruft to simplify the interface and at least gesture in the
direction of proper orthogonality.  That was completely the wrong place
to try to do branch switching (but I preserved the unused CVS logic in
a comment - we will need to re-use it sometime.)

There's another checkout flag case I'm probably going to abolish on my
next pass through the code.  A revision of t is suppose to force
checkout on the current branch (vs. nil which is theoretically
checkout on trunk). But in most back ends the revision flag silently
does nothing. This was another half-baked attempt to support branching
that didn't work.

Dmitri is correct.  VC needs a set of branching primitives:
get-current-branch, set-current-branch, create-branch, delete-branch,
rename-branch.  And we need a standard way to exercise them in the
UI.  Both are presently lacking.

I also, by the way, removed the "editable" flag on the checkout
capability; where it matters (SCCS and RCS) files are now always
checked out editable.  I'm almost sure the code paths with it bound to
nil weren't actually exercised - there's been a lot of drift in this
code.

In general, the back-end interface is in severe need of attention and
a design rethink.  Again.  I think the number of code paths and
back-end methods could be seriously reduced.  Can't promise when I'll
do it, but I'm at least clearing away the rubble and detritus now.

Does anyone active on the list have a direct interest in the CVS code?
That's the one problem case that's not easy for me to test.  I could
use some help verifying that my next round of changes don't break it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Inadequate branch support in VC

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

() "Eric S. Raymond" <esr@thyrsus.com>
() Thu, 20 Nov 2014 12:30:52 -0500

   I also, by the way, removed the "editable" flag on the checkout
   capability; where it matters (SCCS and RCS) files are now always
   checked out editable.

Maybe you can move that functionality into those backends.  I use a
RCS- (and CVS-, for that matter) controlled file's read-only status
in my workflow.  FWIW, locally, i've kludged Git to work similarly.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Inadequate branch support in VC

[Dmitry Gutov]

On 11/20/2014 07:30 PM, Eric S. Raymond wrote:

> The sort of good news: there is an amend capability.  Nothing newer than
> svn supports it, though - in particular, the git back end could but does not.
> (SRC wlll support it.)  It's accessed through log-view, which is ... even
> more confusing than the rest of the code.

Huh, I didn't know about that.

First, the git backend does support amending, but in a very different 
way (press `C-c C-e' in log-edit buffer, when making a new commit). That 
doesn't allow amending when you have to modified files, though, which is 
something that I do often. Improving that would be good.

Second, `log-view-modify-change-comment' doesn't seem to support modern 
backends at all because `log-view-extract-comment' unconditionally calls 
`log-view-current-file'. This should be easy to fix.

Third, doing message editing in log-view might be a natural way to go 
about it, but editing any but the last commit (and even it, if it's been 
pushed) is a dangerous operation in Git, which we shouldn't make too 
easy for users to perform.

Should there be, like, a check that the given comment is not reachable 
from any of the "remote" refs?

> Dmitri is correct.  VC needs a set of branching primitives:
> get-current-branch, set-current-branch, create-branch, delete-branch,
> rename-branch.  And we need a standard way to exercise them in the
> UI.  Both are presently lacking.

You probably meant Eli here. :)