From: Norbert Kiesel <nkiesel@gmail.com>
To: Elijah Newren <newren@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: "git rebase" behavior change in 2.26.0
Date: Wed, 25 Mar 2020 18:37:36 -0700 [thread overview]
Message-ID: <CAM+g_Nvt3X4d5cjKajzDOcoDgNS4bVkj3a0KvVm4yDEW-J7v2w@mail.gmail.com> (raw)
In-Reply-To: <CAM+g_NtHC5ukU3jchVfud_H_m_h29UQ8vmwQoND8s_Q9Hv70Fg@mail.gmail.com>
I have to wait for a few hours to see more changes in that branch that
showed this behavior.
I tried with this branch just now and my repo is in sync with
upstream. Nevertheless, I see messages about operations for both
backends now for `git pull` which I don't remember seeing before:
% git status --untracked-files=no
On branch nextrelease
Your branch is up to date with 'origin/nextrelease'.
nothing to commit (use -u to show untracked files)
% git -c rebase.backend=merge pull
Already up to date.
Successfully rebased and updated refs/heads/nextrelease.
% git -c rebase.backend=apply pull
Already up to date.
First, rewinding head to replay your work on top of it...
Fast-forwarded nextrelease to d008080d3f2dc5a9af30067f705a3cb26ed847b3.
%
Why is git doing anything if the branch is already up-to-date? The
commit it ff to is the HEAD of that branch so I don't think anything
is really changing. Also, if I use `-c pull.rebase=false` I see what I
think is the 2.25 behavior
% git status --untracked-files=no
On branch nextrelease
Your branch is up to date with 'origin/nextrelease'.
nothing to commit (use -u to show untracked files)
% git -c rebase.backend=merge -c pull.rebase=false pull
Already up to date.
% git -c rebase.backend=apply -c pull.rebase=false pull
Already up to date.
I had `pull.rebase=true` configured for quite some time now. And yes,
I should set it for just this "never push" branch instead of for all
branches. I just tried with `-c pull.rebase=false -c
branch.nextrelease.rebase=true` and that shows
the same behavior as `-c pull.rebase=true`.
One potential difference: I have tons of untracked files in my working
directory. Could that make a difference?
On Wed, Mar 25, 2020 at 2:39 PM Norbert Kiesel <nkiesel@gmail.com> wrote:
>
> I will try to reproduce and will report back.
>
> On Wed, Mar 25, 2020 at 2:21 PM Elijah Newren <newren@gmail.com> wrote:
>>
>> On Tue, Mar 24, 2020 at 10:40 PM Jeff King <peff@peff.net> wrote:
>> >
>> > On Tue, Mar 24, 2020 at 08:38:04PM -0700, Norbert Kiesel wrote:
>> >
>> > > I track an upstream repo with "pull.rebase = true" where I do a `git
>> > > pull` followed by a `git log -p ORIG_HEAD..` for a branch to see
>> > > changes since the last "pull". I normally do not commit to this
>> > > branch and thus this normally is a "fast-forward" merge.
>> > >
>> > > Starting with 2.26 this no longer works because ORIG_HEAD is always
>> > > set to HEAD after my `git pull`.
>> > >
>> > > I track other prances from the same repo where I do local changes and
>> > > then want the `git pull --rebase` and I thus do not want to
>> > > give up on the `pull.rebase = true` configuration.
>> >
>> > I can imagine this is related to the switch to the "merge" backend for
>> > git-pull, which may be more eager to overwrite ORIG_HEAD. Perhaps try:
>> >
>> > git -c rebase.backend=apply pull
>> >
>> > and see if that behaves differently.
>> >
>> > I tried to reproduce what you're seeing, but my recipe doesn't seem to
>> > show any difference between the two versions:
>> >
>> > -- >8 --
>> > #!/bin/sh
>> >
>> > rm -rf repo
>> >
>> > git init -q repo
>> > cd repo
>> > echo content >base && git add base && git commit -q -m base
>> > git clone -q . dst
>> > echo content >new && git add new && git commit -q -m new
>> >
>> > cd dst
>> > git rev-parse HEAD >.git/ORIG_HEAD
>> > echo before: $(git log -1 --oneline ORIG_HEAD)
>> > git -c pull.rebase=true pull -q ..
>> > echo after: $(git log -1 --oneline ORIG_HEAD)
>> > -- 8< --
>> >
>> > We don't seem to touch ORIG_HEAD in either case. But maybe a more
>> > complex set of pulled commits would trigger it?
>>
>> I can't duplicate either. I suspected that perhaps rebase.autoStash
>> might help cause it to happen if you had local changes, but I didn't
>> succeed in reproducing with that either.
>>
>> Norbert: Any ideas what you may be doing differently to trigger this?
>> And does it still happen with rebase.backend=apply, as Peff asked
>> about?
>>
>>
>> Elijah
next prev parent reply other threads:[~2020-03-26 1:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 3:38 "git rebase" behavior change in 2.26.0 Norbert Kiesel
2020-03-25 5:39 ` Jeff King
2020-03-25 21:21 ` Elijah Newren
[not found] ` <CAM+g_NtHC5ukU3jchVfud_H_m_h29UQ8vmwQoND8s_Q9Hv70Fg@mail.gmail.com>
2020-03-26 1:37 ` Norbert Kiesel [this message]
2020-03-26 1:46 ` Norbert Kiesel
2020-03-26 3:37 ` Elijah Newren
2020-03-26 6:32 ` Elijah Newren
2020-03-26 7:28 ` Jeff King
[not found] ` <CAM+g_NthmmJh3=Tp3ea6PmDr1h2-WtpiSTO8q02V3judc9p-Kg@mail.gmail.com>
2020-03-27 18:01 ` Norbert Kiesel
2020-03-27 18:34 ` Elijah Newren
2020-03-27 20:59 ` Elijah Newren
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: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAM+g_Nvt3X4d5cjKajzDOcoDgNS4bVkj3a0KvVm4yDEW-J7v2w@mail.gmail.com \
--to=nkiesel@gmail.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=peff@peff.net \
/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://80x24.org/mirrors/git.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).