emacs-devel
[Top][All Lists]
Advanced

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

Re: VC mode and git


From: Mike Gerwitz
Subject: Re: VC mode and git
Date: Tue, 31 Mar 2015 01:12:47 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Mar 30, 2015 at 17:40:35 +0300, Eli Zaretskii wrote:
>> If a push fails, that does not necessarily indicate a "bad state"---it
>> simply represents that your history is different than what the remote
>> server has, and that the tip of the branch you are pushing to cannot
>> simply be "fast-forwarded" to your commit.
>
> It is "bad" from the POV of someone who started with uncommitted
> changes, and ended with them committed locally, but not pushed
> upstream.  IOW, the command did half the work, and now the user needs
> to use commands she might consider "advanced" to fix that.

I intended to convey that recovery was easy and that it could be easily
rolled back as if commit+push were atomic; there's no need to worry,
- From a scripting perspective, that a push has failed, because such a
thing isn't "bad" in Git.

> We decided some time ago that we don't want to rebase, but to pull
> instead.

It is a pull---`git pull` is simply `git fetch && git merge remote`; its
- --rebase option uses `rebase` instead of `merge`.

Regardless, my apologies---I have only had time to read about 1/3 of the
discussion; this is a rather large thread going on.

> First, no one suggested any automation here.  "C-x v v" is a command
> that is invoked by the user, it doesn't invoke itself.  It could also
> show a warning and ask for confirmation in dubious situations.

The thread I responded to was about a hook, which is a script.

> And second, with VCSes as versatile as Git (and assuming that people
> who use Git in such workflows will at all want to use VC, an
> assumption that proved questionable in this discussion), VC should
> offer to customize its "next action" decisions so as to adapt them to
> a particular workflow.

Yes, that's fine; I suggested that.  But Richard wanted commit+push as
an atomic operation, so only a subset of the commands I provided will be
part of any sort of decision tree.

I'm not arguing for or against it.  I personally do not like the idea of
commit+push as an atomic operation, and would rather see VC treat them
separately, but that's not what I was providing my input on.

- -- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer
http://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVGizQAAoJEPIruBWO4w6rnI4QAKrGlbIhr+nqEUC6IOf1QNbE
kzuuDVwJC0Yt5kMbeN3cyChd8kp1zn/2iz2CaKgqm6muvMdVZ0elgqFKYhY7P/sw
E34YAaexLY1Xz4YfV5WCoR4S5WuQQ+JpxtQZYrlXdMnW7UFeFdzIbtEP45s8WoU6
DWx/R72uYOU5SICex8Hwsa+CkP7EDJ8hvj3VNbVb2/7bSx8qkBkb3s5P+gkC31tp
eG45R3HbFhchZ5HoAFTKLP3qDl/DoWocWv+6vUdBmVaqSUgwzYYGaGIdIPSoxVUP
DfOxPhLhrLNczZEiZZh07vfqMFlNk2Rhxtt/UmHEJgnteQtsNVmXgVI02y/l1mYP
bFJjL49LIieLphwmGoj3xXj8ZJZR1wqHuqjplLTcVsmlFPml7llf9bIs3kKmuZkc
NfaV4xZgtpnuTnFRa2slfTFlXs6hdGweMeBFokcldbzD/MTTAV1TQ7i9h7KBnI5l
RcTr8BfVgeDsKTMfcT1N2PJrMi69mDrcY1I6aB5CkW4B3tdq2damp0wCItYjZlPY
DaCgJ3VqAYyt7EznPwhfJEP54r5hJuqPPdX0rL97ojD+IOaDsdvKg4lgCMPKjO9v
VMkL5zqD4kl3YnDnXJ09bt2PtxoZRQxWwPAqOgcYkOb3IAajNEX23lWZiBtOuxR1
wkrasN3XLJ/FvpVMc6PE
=go3H
-----END PGP SIGNATURE-----



reply via email to

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