[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: git commit/push and VC
From: |
Stephen J. Turnbull |
Subject: |
Re: git commit/push and VC |
Date: |
Fri, 21 Nov 2014 09:31:17 +0900 |
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
- git commit/push and VC, Stephen Berman, 2014/11/19
- Re: git commit/push and VC, Glenn Morris, 2014/11/19
- Re: git commit/push and VC, Yuri Khan, 2014/11/19
- Re: git commit/push and VC, Eli Zaretskii, 2014/11/20
- Re: git commit/push and VC, Achim Gratz, 2014/11/20
- Re: git commit/push and VC, Eli Zaretskii, 2014/11/20
- Re: git commit/push and VC,
Stephen J. Turnbull <=
- Re: git commit/push and VC, Eli Zaretskii, 2014/11/21
- Re: git commit/push and VC, Stephen J. Turnbull, 2014/11/22
- Re: git commit/push and VC, Yuri Khan, 2014/11/22
- Re: git commit/push and VC, Stephen J. Turnbull, 2014/11/22
- Re: git commit/push and VC, Ivan Shmakov, 2014/11/22
- Re: git commit/push and VC, Stephen J. Turnbull, 2014/11/22
- Re: git commit/push and VC, Ivan Shmakov, 2014/11/22
- Re: git commit/push and VC, Stephen J. Turnbull, 2014/11/22
- Re: git commit/push and VC, Eli Zaretskii, 2014/11/22
- Re: git commit/push and VC, Andreas Schwab, 2014/11/22