[Top][All Lists]

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

Re: git commit/push and VC

From: Eli Zaretskii
Subject: Re: git commit/push and VC
Date: Fri, 21 Nov 2014 11:01:29 +0200

> From: "Stephen J. Turnbull" <address@hidden>
> Date: Fri, 21 Nov 2014 09:31:17 +0900
> Cc: Achim Gratz <address@hidden>, address@hidden
>  > But that's me, and I already know how to solve this.  I'm asking what,
>  > if anything, do we want to recommend.
> I would say either go with *your* gut feeling, or if you prefer,
> somebody else you trust. ;-)

I don't yet trust my gut feeling with Git, except with features I
myself have enough experience with.  This particular one is not among
them, as all the other projects where I gained my Git experience don't
present problems with several branches in the same tree.

> 1) single clone, multiple out-of-tree build directories (this is what
>    I use).  Disadvantages: IIRC Emacs uses the same "link lisp/ ->
>    $srcdir/lisp" strategy that XEmacs does, so bootstrap takes a long
>    time, and the first make after switching is likely to take a long
>    time even if you don't bootstrap (because checked-out files all
>    appear to have been touched).  There will be several emacs binaries
>    associated with the clone, so there is potential for confusion
>    between the running Emacs and the checked-out version.
> 2) single clone, in-tree build.  Disadvantages: as (1), but even more
>    so, except that it's easier to keep emacs in synch with the sources
>    as there's only one binary in existence.
> 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.
> 4) single repo, multiple workspaces (use GITDIR variable, for
>    example).  Disadvantages: not well-supported by git AFAIK, so the
>    user has to keep track of the global branch.
> Maybe you shouldn't mention (4).

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?

reply via email to

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