[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: master c6f03ed: Fix a problem in url.el without GnuTLS
From: |
Eli Zaretskii |
Subject: |
Re: master c6f03ed: Fix a problem in url.el without GnuTLS |
Date: |
Thu, 18 Dec 2014 17:39:22 +0200 |
> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,
> address@hidden
> Date: Thu, 18 Dec 2014 13:55:26 +0900
>
> > > That'd lose too much information, so I'd like to avoid that if
> > > possible.
> >
> > What kind of information do you mean here? I'm guessing you want to see
> > the merges from master and how you reacted to them? You're right that
> > this will be lost.
>
> I think this is the crucial question. git documents are very good at
> explaining implementations, but people have a habit of deciding what
> they think a command does based on its name. That matters a little
> for Eli, and a lot for GitForEmacsDevs.
>
> We really need to see what DAG Eli wants to construct.
The one that would be there if the push from master following a merge
from a feature branch succeeded. I hope this is clear enough; if not,
please ask more specific questions.
> (where "reasonable" is defined "Eli feels comfortable with it
> for the purposes he has in mind" -- we have to ask Eli :-).
I don't think I've invented something unnatural here. What I'd like
is to have a merge-based workflow where the DAG reflects all the
merges between 2 branches as they happened in real time. Race
conditions interfere with that, but I'd like to resolve that issue
in a way that only affects the last merge before the final successful
push from the local master to upstream.
> > . You want to keep a clear history of 'mainline', meaning you want to
> > achieve a similar log view to that from Bazaar, using 'git log
> > --first-parent'.
> >
> > This conflicts with how Git orders the parents of a merge. The first
> > parent is always the tip of the branch you're currently on. And since
> > you do 'git pull' while being on your local master, that will be the
> > first parent.
> I don't see a conflict here. What I do see is an ambiguity in the
> discription of entry conditions. If you bzr-think, on a feature
> branch the "local master" is likely to be the feature branch.[1] That
> is, the workflow is
> git clone git:emacs ./feature-1
> cd feature-1
> emacs file1 ...
> git commit
> git pull git:emacs # we've just swapped master and
> # origin/master, ie, the public mainline,
> # when we push mainline is nonlinear
>
> without actually defining a branch.
This is not how work on a branch happens (and not how it happened with
bzr). There's an actual named branch, and changes are merged from
there to master, before pushing them.
> git clone git:emacs ./feature-1
> cd feature-1
> git checkout -b feature-1
> emacs file1 ...
> git commit
> git pull git:emacs # origin/master contains public mainline
> # feature-1 contains local mainline
> To push to public:
> git checkout master
> git push # public mainline is preserved
> git checkout feature-1 # #### these three commands are error-prone
> AFAICS this is what you need to do for emacs-24, too.
What I do for emacs-24 is similar, but not identical:
git clone git:emacs ./emacs-24
cd emacs-24
git checkout emacs-24
<hack, hack>
git commit
git push
cd ../trunk # another clone
git checkout master
git pull
git merge origin/emacs-24
<test, fix problems, commit>
git push
> The problems are (1) a convenient discipline for those last three
> commands
What is error-prone about them?
> I think that one way to provide convenience and discipline would be
> to (a) require that the feature branch workspace be located in a
> directory with the same name as the feature branch, and (b) provide
> git-pull-emacs and git-push-emacs scripts that check for $(basename
> $cwd) == feature-name as a precondition.
Sounds complicated, and I'm not sure it's really needed. Local
feature branches (unlike emacs-24) don't need to be in a separate
directory, because they usually don't diverge from master enough to
justify that. What remains is the requirement to be aware of the
currently checked-out branch, something that is quite easy both at the
shell prompt (where Git instructs Bash to show the branch) and in
Emacs.
A significant disadvantage of this proposal, at least for me, is that
it defines a set of commands and some details of the workflow that are
specific to Emacs and not available and/or unneeded in any other
project that uses Git. So it gets in the way of a more efficient
learning to use Git by combining the experience from other projects.
> > One could implement a git hook that checks for a linear git history
> > of mainline and that rejects pushes otherwise, but I guess Stefan
> > isn't very inclined to agree to that.
>
> My impression is that Stefan is not inclined to encourage work on this
> problem; he thinks it's a waste of time. I think he'd come around
> quickly if presented with either another problem that would be solved
> by the same workflow that preserves linear mainline, or a
> "sufficiently convenient" workflow that preserves linear mainline.
But there doesn't appear to be such a sufficiently convenient
workflow, not with Git.
> [1] I think Eli means that in his feature branch workspace he uses a
> branch named for the feature rather than master
Of course!
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, (continued)
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, David Engster, 2014/12/14
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Eli Zaretskii, 2014/12/14
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, David Engster, 2014/12/15
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Eli Zaretskii, 2014/12/16
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Steinar Bang, 2014/12/17
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Steinar Bang, 2014/12/17
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Eli Zaretskii, 2014/12/17
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Eli Zaretskii, 2014/12/17
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, David Engster, 2014/12/17
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Stephen J. Turnbull, 2014/12/17
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS,
Eli Zaretskii <=
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Steinar Bang, 2014/12/18
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Eli Zaretskii, 2014/12/18
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Steinar Bang, 2014/12/19
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Eli Zaretskii, 2014/12/19
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Steinar Bang, 2014/12/19
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, David Engster, 2014/12/18
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Eli Zaretskii, 2014/12/18
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Steinar Bang, 2014/12/18
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Eli Zaretskii, 2014/12/18
- Re: master c6f03ed: Fix a problem in url.el without GnuTLS, Yuri Khan, 2014/12/19