Re: git commit/push and VC

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Stromeko@nexgo.de,
>     emacs-devel@gnu.org
> Date: Sat, 22 Nov 2014 18:36:34 +0900
> 
>  >   git fetch ../my-other-clone <probably some arguments here>
>  >   git merge <more arguments here>
>  >   # fix conflicts, if any
>  >   git commit -a # only if there were conflicts
>  >   git push
>  > 
>  > Is that right?  Sounds a bot complicated and error-prone, I agree.
> 
> Well, the first two commands can probably be reduced to "git pull
> ../my-other-clone".
> 
> But it seems reasonably likely that both branches exist in at least
> one of the clones, because "git diff" requires that the commits being
> compared be in the same repo, and referring to them via SHA1 is chancy
> at best.

Yes, so I think merging from another clone is unnecessary.

>  >   git pull
>  >   git merge -m <commit-message> remotes/origin/emacs-24
>  >   # fix conflicts, if any
>  >   # run tests, fix bugs if any
>  >   git commit -a # only if there were conflicts
>  >   git push
>  > 
>  > Is this correct?  Because if it is, it's just like the "normal" merge
>  > workflow, just with the name of the merge source branch slightly
>  > special.  So it's easier to remember and less error-prone, I think.
> 
> I think just "git pull -e ../emacs-24" and edit the commit message is
> clearer, instead of pull and merging.

I don't think we need the "../" part, do we?  It's the same
repository, and emacs-24 is the name of a branch, not a directory.

I wonder if it's a good idea to tell people to pull from a different
branch, though.  It could cause errors down the road (not in this
scenario).  FWIW, I'd be nervous to do that.