git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

  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).