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?
next prev parent 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.