unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: David Engster <deng@randomsample.de>
Cc: emacs-devel@gnu.org
Subject: Re: master c6f03ed: Fix a problem in url.el without GnuTLS
Date: Sun, 14 Dec 2014 18:09:49 +0200	[thread overview]
Message-ID: <83iohe43hu.fsf@gnu.org> (raw)
In-Reply-To: <874mszp2i7.fsf@engster.org>

> From: David Engster <deng@randomsample.de>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Dec 2014 00:13:20 +0100
> 
> > Sorry, I still don't understand.  Which commits from what branches
> > does Git merge after 'rebase=preserve'?
> 
> It merges the branch that is implicitly created by moving
> 'origin/emacs-24' to a newer parent.

That's the missing link, thanks.

So this means that:

  . Using "pull --rebase=preserve" always rewrites the merge to come
    from some unnamed branch, which is different from the branch that
    originated the merged commits.

  . This is true for merges from local branches as well.  Therefore,
    using this option is not advisable for local branches, because
    doing that would mean trouble when I next merge from master into
    my local branch -- I will get the same commits back again.

  . IOW, rebase=preserve is not useful in a merge-based workflow.

Is my interpretation correct?

If it is, then here's my conundrum.  When I make changes in master, I
don't want them to look as if they were made on some branch when I
push them.  Why? for starters, because "log --first-parent" won't show
them.  So I use "pull --rebase" to avoid that.  This works well as
long as I didn't make any local merge-commits, be it from my local
branches or from public branches such as emacs-24.  I thought that
using rebase=preserve would cover the latter use cases as well, but
now I understand I was mistaken: I can use "pull --rebase" only if
there were no merge-commits since the last refs update; otherwise I
need to use "pull".  So I cannot configure Git to always use some
option when pulling, and forget about that.

AFAIU, an alternative, when I have local merge-commits, is to use
"pull --ff-only", and when it refuses to pull, use "reset --hard
origin/master", and then "merge -no-ff" and commit, before pushing.
That's significantly more complicated, sigh.

Which means there's no easy way with Git to support a workflow that
preserves mainline, without jumping through some hoops.

Is that correct?  Or is there a better workflow that preserves the
mainline?

If there is no better workflow, perhaps we need to radically rethink
our recommended project workflow, like not base it on merges but on
rebase, or push fixes to master and then cherry-pick them to the
release branch, or something else.  Because what bzr supported easily
and almost seamlessly, Git doesn't -- in the sense that emulating the
same workflow is more complicated and thus error-prone.  To me, this
spells that we fight the tool, i.e. our workflow should change.

> You can't at the same time move a branch onto a new parent (which is
> what rebase does) and then merge it, so that it looks like you've merged
> the original one which had another parent.

I only use rebase because I don't know of another way of being able to
work on master without having my commits look as if they were made on
a branch, after I push them, which AFAIU will happen if someone else
pushes before I push my local commits made on master.  If there's a
reasonably simple way to avoid this effect without rebasing, I guess
I'll switch to that.  I didn't use rebase with bzr, because there was
a simple way to preserve the mainline without rebasing.

Btw, I think we need to do something urgently in gitmerge.el to avoid
this kind of mistakes.  Otherwise, people will keep making these
mistakes, and no amount of explanations will ever be able to prevent
that.

Thanks.



  reply	other threads:[~2014-12-14 16:09 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20141211155740.11916.1584@vcs.savannah.gnu.org>
     [not found] ` <E1Xz67Y-00036o-Vf@vcs.savannah.gnu.org>
2014-12-11 16:47   ` master c6f03ed: Fix a problem in url.el without GnuTLS Leo Liu
2014-12-11 18:08     ` Eli Zaretskii
2014-12-11 23:00       ` Ted Zlatanov
2014-12-12  9:23         ` Eli Zaretskii
2014-12-12 13:24           ` Ted Zlatanov
2014-12-12 14:28             ` Eli Zaretskii
2014-12-12 16:06               ` Stefan Monnier
2014-12-13  0:25               ` Ted Zlatanov
2014-12-13  0:28                 ` Lars Magne Ingebrigtsen
2014-12-13  1:25                 ` Ted Zlatanov
2014-12-13  8:04                 ` Eli Zaretskii
2014-12-13 10:16                   ` David Engster
2014-12-18 22:38                     ` David Engster
2014-12-19  8:50                       ` Eli Zaretskii
2014-12-13  9:04                 ` David Engster
2014-12-13  9:50                   ` David Engster
2014-12-13 13:19                     ` Ted Zlatanov
2014-12-13 14:13                       ` David Engster
2014-12-13 14:25                         ` Ted Zlatanov
2014-12-13 15:18                         ` Eli Zaretskii
2014-12-13 19:44                           ` David Engster
2014-12-13 19:59                             ` Eli Zaretskii
2014-12-13 22:00                               ` Dmitry Gutov
2014-12-14  3:36                                 ` Eli Zaretskii
2014-12-13 23:13                               ` David Engster
2014-12-14 16:09                                 ` Eli Zaretskii [this message]
2014-12-14 16:37                                   ` Ted Zlatanov
2014-12-14 16:55                                     ` Eli Zaretskii
2014-12-14 17:00                                       ` Ted Zlatanov
2014-12-14 23:21                                     ` Stefan Monnier
2014-12-14 17:46                                   ` Paul Eggert
2014-12-14 17:50                                     ` Eli Zaretskii
2014-12-14 18:28                                     ` Ted Zlatanov
2014-12-14 19:41                                       ` David Engster
2014-12-14 21:40                                   ` David Engster
2014-12-15  3:47                                     ` Eli Zaretskii
2014-12-15 20:39                                       ` David Engster
2014-12-16 19:42                                         ` Eli Zaretskii
2014-12-17  9:58                                           ` Steinar Bang
2014-12-17 10:52                                             ` Steinar Bang
2014-12-17 15:36                                               ` Eli Zaretskii
2014-12-17 15:35                                             ` Eli Zaretskii
2014-12-17 20:37                                           ` David Engster
2014-12-18  4:55                                             ` Stephen J. Turnbull
2014-12-18 15:39                                               ` Eli Zaretskii
2014-12-18 20:00                                                 ` Steinar Bang
2014-12-18 20:40                                                   ` Eli Zaretskii
2014-12-19  8:09                                                     ` Steinar Bang
2014-12-19  9:16                                                       ` Eli Zaretskii
2014-12-19 10:33                                                         ` Steinar Bang
2014-12-18 21:18                                               ` David Engster
2014-12-18 15:38                                             ` Eli Zaretskii
2014-12-18 19:46                                               ` Steinar Bang
2014-12-18 20:35                                                 ` Eli Zaretskii
2014-12-19  6:07                                                   ` Yuri Khan
2014-12-19  7:57                                                     ` Steinar Bang
2014-12-19  9:09                                                     ` Eli Zaretskii
2014-12-18 20:46                                               ` David Engster
2014-12-14 22:42                                   ` Stefan Monnier
2014-12-15  3:37                                     ` Eli Zaretskii
2014-12-15  4:46                                       ` Stefan Monnier
2014-12-12 20:46             ` Lars Magne Ingebrigtsen
2014-12-12  0:30       ` Leo Liu

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83iohe43hu.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=deng@randomsample.de \
    --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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).