emacs-devel
[Top][All Lists]
Advanced

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

Re: VC mode and git


From: Yann Hodique
Subject: Re: VC mode and git
Date: Thu, 26 Mar 2015 08:38:08 -0700
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4 (darwin)

>>>>> "Richard" == Richard Stallman <address@hidden> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>> > The reason to make this change is to help people who are not
>> > sophisticated git users.

>> For those people it is even more important that vc does not push by
>> default.

> With all due respect, I think you are mistaken.  C-x v v pushes by
> default with CVS and with Bzr, and that has never been a problem.  Why
> would it be a problem with Git when it is not a problem with the
> others?

Arguably, C-x v v *never* pushes. What it does instead is always *record*
a commit object in the source of truth for commit objects.
Depending on the VCS that means different places:
- in CVS, that source of truth is a server (and that's not pushing,
  since the commit object doesn't exist elsewhere)
- in Bzr, it is the local repository, but depending on Bzr config it might
  - result in Bzr (not VC) automatically pushing to a remote location,
    if you're operating on a bound branch
  - stay local in the other cases (which is how people typically use Bzr)
- in Git, it is also the local repository (and while there is no
  bound-branches, they can be simulated via hooks, which is also VCS-side
  configuration)
Bottom-line, in CVS there is a source of truth per project, and in
DVCSes there is also (at least) one per developer.
Admittedly, those sources are generally *partially* re-synchronized from
time to time, but that does not make it the same situation.

If some projects (like Emacs) operate in a more centralized manner,
that's fine. But the VCS configuration (per project) is the right place
to accomodate that, not the global VC client.

The way we look at push is as a brand-new operation, not even something
that was done automatically by commit in the old days.
The reason being that there is absolutely no 1:1 relationship between
those operations:
- a push generally covers multiple commits (as in "look, my set of
  carefully crafted commits finally looks good enough to be published")
- "the" place to push to might not exist, or might not be unique (and
  this is generally not discoverable)

As others, I believe any attempt to automatically push will result in
more confusion from users than benefits (especially since the current
generation is pretty much DVCS-native). I also think we should not
encourage users to develop bad habits/expectations by artificially
keeping alive the assumption that there is always a central place where
all commits have to live.

my 2ยข

Yann.

-- 
Nature commits no errors; right and wrong are human categories.

  -- PARDOT KYNES, Arrakis Lectures




reply via email to

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