From: John Keeping <john@keeping•me.uk>
To: John Szakmeister <john@szakmeister•net>
Cc: Junio C Hamano <gitster@pobox•com>,
Philip Oakley <philipoakley@iee•org>,
Felipe Contreras <felipe.contreras@gmail•com>,
git@vger•kernel.org, Andreas Krey <a.krey@gmx•de>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Thu, 5 Sep 2013 12:38:22 +0100 [thread overview]
Message-ID: <20130905113822.GF2582@serenity.lan> (raw)
In-Reply-To: <CAEBDL5VfHObeWZWvj0bnv5x+QF1_DACdU+Ehds6fHUioziHWrQ@mail.gmail.com>
On Thu, Sep 05, 2013 at 07:01:03AM -0400, John Szakmeister wrote:
> On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano <gitster@pobox•com> wrote:
> [snip]
> > When "git pull" stops because what was fetched in FETCH_HEAD does
> > not fast-forward, then what did _you_ do (and with the knowledge you
> > currently have, what would you do)? In a single project, would you
> > choose to sometimes rebase and sometimes merge, and if so, what is
> > the choice depend on? "When I am on these selected branches, I want
> > to merge, but on other branches I want to rebase?"
>
> Our team isn't quite proficient enough yet to have a completely rebase
> workflow... though we might have less of a problem if we did. So,
> several interesting points. Most of the time, `git pull` would be a
> fast-forward merge. We typically perform the merges of topic branches
> server-side--we have a build server who checks to make sure the result
> would be successful--and we just hit the big green button on the Merge
> button for the pull request (we use GitHub Enterprise at the moment).
>
> However, nearly as often, we just merge the branch locally because
> someone on the team is doing some manual testing, and it's just
> convenient to finish the process on the command line. What
> occasionally happens is that you merge the topic locally, but someone
> else has introduced a new commit to master. We try to preserve the
> mainline ordering of commits, so `git pull` doing a merge underneath
> the hood is undesirable (it moves the newly introduced commit off to
> the side). Rebasing your current master branch is not the answer
> either, because it picks up the commits introduced by the topic branch
> and rebases those to--at least with the -p option, and without it, the
> results are just as bad). Instead, we want to unfold our work,
> fast-forward merge the upstream, and the replay our actions--namely
> remerge the topic branch. It often ends up translating to this:
>
> $ git reset --hard HEAD~1
> $ git merge --ff-only @{u}
> $ git merge topic
> $ git push
>
> So what I really want isn't quite rebase. I'm not sure any of the
> proposed solutions would work. It'd be really nice to replay only the
> mainline commits, without affecting commits introduced from a topic
> branch.
Does "git rebase --preserve-merges" do what you want here?
next prev parent reply other threads:[~2013-09-05 11:38 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-31 22:38 [PATCH 0/3] Reject non-ff pulls by default Felipe Contreras
2013-08-31 22:38 ` [PATCH 1/3] merge: simplify ff-only option Felipe Contreras
2013-08-31 22:38 ` [PATCH 2/3] t: replace pulls with merges Felipe Contreras
2013-08-31 22:38 ` [PATCH 3/3] pull: reject non-ff pulls by default Felipe Contreras
2013-09-03 17:21 ` [PATCH 0/3] Reject " Junio C Hamano
2013-09-03 21:50 ` Felipe Contreras
2013-09-03 22:38 ` Junio C Hamano
2013-09-03 22:59 ` Felipe Contreras
2013-09-04 8:10 ` John Keeping
2013-09-04 9:25 ` Jeff King
2013-09-04 10:16 ` John Keeping
2013-09-08 2:52 ` Felipe Contreras
2013-09-08 4:18 ` Jeff King
2013-09-08 4:37 ` Felipe Contreras
2013-09-08 4:43 ` Jeff King
2013-09-08 5:09 ` Felipe Contreras
2013-09-08 5:21 ` Jeff King
2013-09-08 6:17 ` Felipe Contreras
2013-09-08 6:54 ` Jeff King
2013-09-08 7:15 ` Felipe Contreras
2013-09-08 7:50 ` Jeff King
2013-09-08 8:43 ` Felipe Contreras
2013-09-09 20:17 ` Jeff King
2013-09-09 22:59 ` Felipe Contreras
2013-09-08 10:03 ` John Keeping
2013-09-09 20:04 ` Jeff King
2013-09-08 17:26 ` brian m. carlson
2013-09-08 22:38 ` Felipe Contreras
2013-09-09 0:01 ` brian m. carlson
2013-09-09 0:29 ` Felipe Contreras
2013-09-09 0:36 ` Felipe Contreras
2013-09-09 0:38 ` brian m. carlson
2013-09-09 7:18 ` Matthieu Moy
2013-09-09 18:47 ` Junio C Hamano
2013-09-09 19:52 ` Jeff King
2013-09-09 20:24 ` John Keeping
2013-09-09 20:44 ` Jeff King
2013-09-09 21:10 ` John Keeping
2013-09-09 21:48 ` Richard Hansen
2013-09-09 20:50 ` Matthieu Moy
2013-09-09 20:53 ` Jeff King
2013-09-09 21:34 ` Philip Oakley
2013-09-09 23:02 ` Felipe Contreras
2013-09-10 8:08 ` John Keeping
2013-09-09 20:47 ` Matthieu Moy
2013-09-10 21:56 ` Junio C Hamano
2013-09-09 23:17 ` Felipe Contreras
2013-09-10 8:26 ` Matthieu Moy
2013-09-11 10:53 ` Felipe Contreras
2013-09-11 11:38 ` Matthieu Moy
2013-09-13 0:55 ` Felipe Contreras
2013-09-04 16:59 ` Junio C Hamano
2013-09-04 17:17 ` Junio C Hamano
2013-09-04 22:08 ` Philip Oakley
2013-09-04 22:59 ` Junio C Hamano
2013-09-05 8:06 ` John Keeping
2013-09-05 19:18 ` Junio C Hamano
2013-09-05 19:26 ` John Keeping
2013-09-06 21:41 ` Jonathan Nieder
2013-09-06 22:14 ` Junio C Hamano
2013-09-07 11:07 ` John Keeping
2013-09-08 2:36 ` Felipe Contreras
2013-09-08 2:34 ` Felipe Contreras
2013-09-08 8:01 ` Philip Oakley
2013-09-08 8:16 ` Felipe Contreras
2013-09-08 8:42 ` Philip Oakley
2013-09-08 8:49 ` Felipe Contreras
2013-09-08 10:02 ` Philip Oakley
2013-09-08 10:39 ` Philip Oakley
2013-09-05 11:01 ` John Szakmeister
2013-09-05 11:38 ` John Keeping [this message]
2013-09-05 12:37 ` John Szakmeister
2013-09-05 15:20 ` Richard Hansen
2013-09-05 21:30 ` Philip Oakley
2013-09-05 23:45 ` Junio C Hamano
2013-09-05 23:38 ` Junio C Hamano
2013-09-08 2:41 ` Felipe Contreras
2013-09-08 6:17 ` Richard Hansen
2013-09-08 18:10 ` Junio C Hamano
2013-09-08 20:05 ` Richard Hansen
2013-09-08 22:46 ` Philip Oakley
2013-09-08 22:46 ` Felipe Contreras
2013-09-08 23:11 ` Ramkumar Ramachandra
2013-09-05 13:31 ` Greg Troxel
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=20130905113822.GF2582@serenity.lan \
--to=john@keeping$(echo .)me.uk \
--cc=a.krey@gmx$(echo .)de \
--cc=felipe.contreras@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=john@szakmeister$(echo .)net \
--cc=philipoakley@iee$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox