all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: Stromeko@nexgo.de, emacs-devel@gnu.org
Subject: Re: git commit/push and VC
Date: Fri, 21 Nov 2014 11:01:29 +0200	[thread overview]
Message-ID: <83oas13p1y.fsf@gnu.org> (raw)
In-Reply-To: <87h9xttmwa.fsf@uwakimon.sk.tsukuba.ac.jp>

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 21 Nov 2014 09:31:17 +0900
> Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
> 
>  > 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	other threads:[~2014-11-21  9:01 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-19 23:36 git commit/push and VC Stephen Berman
2014-11-20  2:07 ` Glenn Morris
2014-11-20 12:28   ` Stephen Berman
2014-11-20  3:29 ` Yuri Khan
2014-11-20 15:45   ` Eli Zaretskii
2014-11-20 18:17     ` Achim Gratz
2014-11-20 20:59       ` Eli Zaretskii
2014-11-21  0:31         ` Stephen J. Turnbull
2014-11-21  9:01           ` Eli Zaretskii [this message]
2014-11-22  5:30             ` Stephen J. Turnbull
2014-11-22  5:50               ` Yuri Khan
2014-11-22  7:17                 ` Stephen J. Turnbull
2014-11-22  6:50               ` Ivan Shmakov
2014-11-22  7:25                 ` Stephen J. Turnbull
2014-11-22  7:42                   ` Ivan Shmakov
2014-11-22  8:59                     ` Stephen J. Turnbull
2014-11-22  8:36                 ` Eli Zaretskii
2014-11-22  8:37                 ` Andreas Schwab
2014-11-22  8:50                   ` Ivan Shmakov
2014-11-22  8:35               ` Eli Zaretskii
2014-11-22  9:36                 ` Stephen J. Turnbull
2014-11-22 10:25                   ` Eli Zaretskii
2014-11-22 11:31                     ` Andreas Schwab
2014-11-22 12:37                       ` Eli Zaretskii
2014-11-22 13:00                         ` Andreas Schwab
2014-11-22 13:45                           ` Eli Zaretskii
2014-11-22 14:12                             ` Andreas Schwab
2014-11-22 15:20                               ` Eli Zaretskii
2014-11-21  8:23         ` martin rudalics
2014-11-21  9:06           ` Eli Zaretskii
2014-11-21  9:40             ` Dani Moncayo
2014-11-21 10:24             ` martin rudalics
2014-11-21 10:40               ` Eli Zaretskii
2014-11-21  8:49         ` Thien-Thi Nguyen
2014-11-21  9:12           ` Eli Zaretskii
2014-11-22 10:30       ` Eli Zaretskii
2014-11-22 10:43         ` David Kastrup
2014-11-22 11:01           ` Eli Zaretskii
2014-11-22 11:16             ` Eli Zaretskii
2014-11-22 11:22               ` David Kastrup
2014-11-21 10:34     ` Stephen Berman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83oas13p1y.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=Stromeko@nexgo.de \
    --cc=emacs-devel@gnu.org \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.