Re: git commit/push and VC

[Stephen J. Turnbull]

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).  But aside from this difference in terminology,
this should be familiar to bzr and Mercurial users who use multiple
workspaces.  (In fact Mercurial users also use "pull", but it doesn't
update and commit.)

Another issue is that I find it easy to do fixes to the "wrong" branch
in the current repo, and that gets confusing.  I also know how to
unwedge myself now, but I can remember getting confused about the
state of my repos occasionally.  That might just be me, since I was
experimenting with various workflows.

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