[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?
- 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, 2014/11/20
- Re: git commit/push and VC,
Eli Zaretskii <=
- 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
- Re: git commit/push and VC, Ivan Shmakov, 2014/11/22