From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
Subject: Re: git commit/push and VC
Date: Fri, 21 Nov 2014 09:31:17 +0900 [thread overview]
Message-ID: <87h9xttmwa.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <83fvdd612c.fsf@gnu.org>
Eli Zaretskii writes:
> > > . do we want to explicitly recommend 2 different clones, one each
> > > for master and the release branch? there's nothing in the
> > > instructions about this, or about working with 2 divergent
> > > branches in general
> > Unless you're really working all the time in parallel on both branches
> > I'd say this setup is more trouble than it's worth.
> I personally am working on both branches in parallel, yes. Many
> others do, too. Bugfixes go to one branch, new features to the other,
> people report bugs on this or other, etc. Bootstrapping each time,
> which takes a couple of minutes, is annoying. And then you sometimes
> want to compare what the two binaries, one from master, the other from
> the release branch, do in the same situation.
>
> 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. ;-) You could also present several scenarios
with expected issues (people can probably judge the merits for
themselves, but the downside of messing up a personal repo is quite
large). I can think of the following:
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).
Steve
next prev parent reply other threads:[~2014-11-21 0:31 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 [this message]
2014-11-21 9:01 ` Eli Zaretskii
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=87h9xttmwa.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=Stromeko@nexgo.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.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.