Re: git commit/push and VC

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden
> Date: Sat, 22 Nov 2014 14:30:15 +0900
> 
> Eli Zaretskii writes:
>  > > From: "Stephen J. Turnbull" <address@hidden>
> 
>  > > 3) multiple clones, build per clone (I don't think it much matters
>  > >    whether it is in-tree or not, and people who use out-of-tree builds
>  > >    probably have other reasons for doing that already, and they'll
>  > >    know what they are doing).  Disadvantages: one of the clones will
>  > >    be used for "stable" -> trunk merges and reverse cherry-picking,
>  > >    and you need to keep track of which one.  You also need a lot more
>  > >    VCS operations to keep them in synch.
> 
>  > I tend to recommend 3), but I don't understand the disadvantages; can
>  > you elaborate?  I thought it was possible to merge between clones, are
>  > you saying that's not a good idea?
> 
> The disadvantages are relatively minor.  Technically speaking, it's
> not possible in git to merge between clones, you have to fetch and
> then merge (== pull).

So to do that inter-clone merge, one would need

  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.

How about the following alternative instead: we do NOT recommend
merging from the other clone.  The other clone is to be used only for
committing to the release branch and, rarely (probably never)
branching off that release branch for doing something that is not a
trivial one-off fix.  To merge to master, we recommend using the clone
that is normally used for working on master and on feature branches
(a.k.a. "master clone").  Specifically, when the time comes to merge
the changes on the release branch to master, we recommend this
sequence of commands in the "master clone":

  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.

The main point is to avoid "git checkout emacs-24" in the "master
clone" as much as possible, because once you switch back to master,
the build will most probably be annoyingly long.

> Another issue is that I find it easy to do fixes to the "wrong" branch
> in the current repo, and that gets confusing.

Does that happen with separate clones also?  I thought separate clones
make this less likely, since they allow you to seldom, if ever, switch
between master and the release branch in the same repo.

> Finally, I just find it more efficient to work in a single clone.

I agree, but I think the Emacs use case is special in this respect,
especially for people who are not proficient enough with Git.