Using VC

Using VC

[Rustom Mody]

The VC command C-x v v claims to cycle through the appropriate actions

However I find it does neither
- push to remote
- save file

Am I missing something

[Backend git]

Re: Using VC

[Dale Snell]

On Sat, 4 Jan 2014 12:01:20 +0530
Rustom Mody <rustompmody@gmail.com> wrote:

> The VC command C-x v v claims to cycle through the appropriate actions
> 
> However I find it does neither
> - push to remote
> - save file
> 
> Am I missing something
> 
> [Backend git]


I haven't used git with Emacs VC before, only RCS.  However, I
have occasionally been unable to check a new file with C-x v v.
The problem was that I forgotten to register the new file in with
the command C-x v i.  Oops.

If that isn't the problem, I'm afraid I'm out of my depth.  Hope this
helps.

--Dale

--
"Shambling, drooling, bent on destruction and biting people's
heads off... it's either zombies or upper management." -- Ebenezer
Dusk, Esquire

Re: Using VC

[Rustom Mody]

Dale Snell wrote:
> I haven't used git with Emacs VC before, only RCS.  However, I
> have occasionally been unable to check a new file with C-x v v.
> The problem was that I forgotten to register the new file in with
> the command C-x v i.  Oops.
>
> If that isn't the problem, I'm afraid I'm out of my depth.  Hope this
> helps.

Ok if a new (to vc) file needs to be registered.
I am talking of an already registered file

Re: Using VC

[Stefan Monnier]

> The VC command C-x v v claims to cycle through the appropriate actions

That was somewhat true back in the days of RCS (where there were
basically only 2 actions: checkout and checkin), then a bit less in the
days of CVS, and nowadays it's completely untrue since the set of
appropriate actions possible at a given time is much larger than 1.


        Stefan

Re: Using VC

[Bob Proulx]

Rustom Mody wrote:
> The VC command C-x v v claims to cycle through the appropriate actions
> 
> However I find it does neither
> - push to remote

That would be a misfeature if it did it.  The key phrase is
"appropriate".  A 'git push' is quite different from a 'git commit'.
A local commit is appropriate but pushing to a remote is not.

A typical git workflow includes local commits but publishing your
content by pushing it up to a remote should only be done after more
consideration.  Because a typical git workflow usually includes many
changes in a changeset and often we rebase and cherrypick in our local
repository to prepare it properly for publishing it.  Check that a
program still builds and runs the test suite.  Only then should you
publish.  Basically shaping it like a sculpture into a good changeset
and then intentionally publishing the changeset.

> - save file

This works for me.  If I haven't saved the file then emacs vc mode
prompts me with:

  Buffer foo modified; save it? (y or n) 

If you respond y then it saves the buffer before committing it.  It
does this *after* collecting the commit message.  Go ahead and test it
by typing in a commit message and finishing it with C-c C-c and if by
then you haven't saved the buffer then it will prompt you.  It is late
in the process but all of the way up to that point you may be editing
and changing the file.  The commit doesn't happen until that point.

> Am I missing something
> [Backend git]

Works for me.

Bob

Re: Using VC

[Rustom Mody]

Bob Proulx wrote:
> > - save file

> This works for me.  If I haven't saved the file then emacs vc mode
> prompts me with:

>  Buffer foo modified; save it? (y or n)

I just get "File-set is up-to-date"

Re: Using VC

[Ted Zlatanov]

On Sat, 04 Jan 2014 14:28:04 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> The VC command C-x v v claims to cycle through the appropriate actions
SM> That was somewhat true back in the days of RCS (where there were
SM> basically only 2 actions: checkout and checkin), then a bit less in the
SM> days of CVS, and nowadays it's completely untrue since the set of
SM> appropriate actions possible at a given time is much larger than 1.

I think some form of "git push" should at least be offered as a choice.

Scenario:

repo is clean and ahead of remotes "origin" and "core"

I use `C-x v v'

Right now it does nothing.

It should, IMHO, offer three choices (and a way to cancel, of course):

"Push"
"Push to origin"
"Push to core"

I know there are many possible paths, but with Git you tend to use those
two paths (push + push to a specific remote) pretty often after a commit.

Ted

Re: Using VC

[Jorgen Grahn]

On Sat, 2014-01-04, Stefan Monnier wrote:
>> The VC command C-x v v claims to cycle through the appropriate actions
>
> That was somewhat true back in the days of RCS (where there were
> basically only 2 actions: checkout and checkin), then a bit less in the
> days of CVS, and nowadays it's completely untrue since the set of
> appropriate actions possible at a given time is much larger than 1.

Yeah. I use C-x v v a lot with RCS and CVS (which I still use) and
with ClearCase, but I don't use it at all with Git.  No doubt there is
some other Git support mode for Emacs, but I'm quite happy doing such
stuff in a shell on the side.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

Re: Using VC

[Bob Proulx]

Ted Zlatanov wrote:
> I think some form of "git push" should at least be offered as a choice.
> ...
> It should, IMHO, offer three choices (and a way to cancel, of course):
> 
> "Push"
> "Push to origin"
> "Push to core"
> 
> I know there are many possible paths, but with Git you tend to use those
> two paths (push + push to a specific remote) pretty often after a commit.

No 'git pull'?  For the most part git is all about pulling changesets
from place to place.

Bob

Re: Using VC

[Ted Zlatanov]

On Tue, 7 Jan 2014 18:04:32 -0700 Bob Proulx <bob@proulx.com> wrote: 

BP> Ted Zlatanov wrote:
>> I think some form of "git push" should at least be offered as a choice.
>> ...
>> It should, IMHO, offer three choices (and a way to cancel, of course):
>> 
>> "Push"
>> "Push to origin"
>> "Push to core"
>> 
>> I know there are many possible paths, but with Git you tend to use those
>> two paths (push + push to a specific remote) pretty often after a commit.

BP> No 'git pull'?  For the most part git is all about pulling changesets
BP> from place to place.

It may require interaction so it's not ideal.  But "git fetch" and "git
fetch [remote]" would make sense, they are generally harmless and don't
need input.

The more advanced things like rebase, merge, etc. don't make sense here
either.

Ted