Weird merge records

Weird merge records

[Dan Stromberg]

Hi.

I'm in a development team that has one official repo, and each
developer has their own repo that is much the same as that official
repo - modulo how recently we synchronized them.

I'm getting _many_ Merge records that look like:
    Merge branch 'develop' of ghosthub.whatever.net:abcd-def/ghij-jk…

...and I don't know where they are coming from.

The merge records do not appear to show up in 'git log -v'. I only see
them in Ghosthub pull requests (Ghosthub being like Github, but
private).

I suspect the merge records may be coming from this small bit of shell
script I've been using to pull from the master repo into my personal
repo:
    git fetch upstream
    git checkout "$branch"
    git config pull.rebase false
    git pull upstream "$branch"
    git push origin "$branch"

Does that snippet look responsible? If yes, how might I change it to
stop creating all those merge records? If no, any guesses what else
might be causing it?

Thanks!

Re: Weird merge records

[Thomas Guyot]

Hi,

On 2023-04-28 11:34, Dan Stromberg wrote:
> I suspect the merge records may be coming from this small bit of shell
> script I've been using to pull from the master repo into my personal
> repo:
>      git fetch upstream
>      git checkout "$branch"
>      git config pull.rebase false
>      git pull upstream "$branch"
>      git push origin "$branch"
>
> Does that snippet look responsible? If yes, how might I change it to
> stop creating all those merge records? If no, any guesses what else
> might be causing it?

It is, indeed. This is IMHO something the developers should do 
themselves, in particular the pull may fail on conflicts and you don't 
seem to stop when it does.

First of all, that line:

git config pull.rebase false


You shouldn't change the user's config - you can instead use 
command-line switches with git-pull to force the desired behavior. In 
this case (which is also the default if there is no pull.rebase config) 
it will merge with the remote (and that merge will be a fast-forward if 
you have no added commits).

If you have local commits that aren't on the tip of the remote branch 
(i.e. someone else committed to the branch) you really have only two 
options here, merge or rebase (there is a new preserve option I think 
that I'm not familiar with, seems like rebase but preserving local 
merges). Rebase is the way to avoid merge commits, but conflicts can be 
painful to resolve if you have many commits to push.

Also note the first fetch is redundant, pull already does a fetch.

So you could change your script to:

     git checkout "$branch"
     git pull --rebase upstream "$branch" || exit 1
     git push origin "$branch"


In the case the pull fails, you will be left with conflicts to resolve - 
the instructions should be printed on screen and also shown in git-status.

Regards,

--
Thomas

Re: Weird merge records

[Felipe Contreras]

On Sat, May 6, 2023 at 10:20 AM Thomas Guyot <tguyot@gmail.com> wrote:

> You shouldn't change the user's config - you can instead use
> command-line switches with git-pull to force the desired behavior. In
> this case (which is also the default if there is no pull.rebase config)
> it will merge with the remote (and that merge will be a fast-forward if
> you have no added commits).

Actually no: it won't merge the current branch with the remote, it
will merge the remote with the current branch, which is not the same.

This is one of the many reasons many git veterans recommend most users
to simply avoid doing `git pull` [1]: it very rarely does what you
want.

[1] https://felipec.wordpress.com/2021/07/13/why-is-git-pull-broken/

-- 
Felipe Contreras

Re: Weird merge records

[Dan Stromberg]

On Sun, May 7, 2023 at 1:34 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Sat, May 6, 2023 at 10:20 AM Thomas Guyot <tguyot@gmail.com> wrote:
>
> > You shouldn't change the user's config - you can instead use
> > command-line switches with git-pull to force the desired behavior. In
> > this case (which is also the default if there is no pull.rebase config)
> > it will merge with the remote (and that merge will be a fast-forward if
> > you have no added commits).
>
> Actually no: it won't merge the current branch with the remote, it
> will merge the remote with the current branch, which is not the same.
>
> This is one of the many reasons many git veterans recommend most users
> to simply avoid doing `git pull` [1]: it very rarely does what you
> want.

You seem to be implying that I shouldn't use 'git pull --rebase
upstream "$branch"'.

If that's the case, what would you recommend?

Re: Weird merge records

[Dan Stromberg]

On Sat, May 6, 2023 at 7:43 AM Thomas Guyot <tguyot@gmail.com> wrote:
>
> Hi,
>
> On 2023-04-28 11:34, Dan Stromberg wrote:
> > I suspect the merge records may be coming from this small bit of shell
> > script I've been using to pull from the master repo into my personal
> > repo:
> >      git fetch upstream
> >      git checkout "$branch"
> >      git config pull.rebase false
> >      git pull upstream "$branch"
> >      git push origin "$branch"
> >
> > Does that snippet look responsible? If yes, how might I change it to
> > stop creating all those merge records? If no, any guesses what else
> > might be causing it?
>
> It is, indeed. This is IMHO something the developers should do
> themselves, in particular the pull may fail on conflicts and you don't
> seem to stop when it does.

It should stop on an error - because there's a "set -eu" in effect.

> Also note the first fetch is redundant, pull already does a fetch.
>
> So you could change your script to:
>
>      git checkout "$branch"
>      git pull --rebase upstream "$branch" || exit 1
>      git push origin "$branch"

I'll keep this in mind.

Thanks.

Re: Weird merge records

[Felipe Contreras]

Dan Stromberg wrote:
> On Sun, May 7, 2023 at 1:34 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > On Sat, May 6, 2023 at 10:20 AM Thomas Guyot <tguyot@gmail.com> wrote:
> >
> > > You shouldn't change the user's config - you can instead use
> > > command-line switches with git-pull to force the desired behavior. In
> > > this case (which is also the default if there is no pull.rebase config)
> > > it will merge with the remote (and that merge will be a fast-forward if
> > > you have no added commits).
> >
> > Actually no: it won't merge the current branch with the remote, it
> > will merge the remote with the current branch, which is not the same.
> >
> > This is one of the many reasons many git veterans recommend most users
> > to simply avoid doing `git pull` [1]: it very rarely does what you
> > want.
> 
> You seem to be implying that I shouldn't use 'git pull --rebase
> upstream "$branch"'.

If you know what you are doing, then do whatever you want. `git pull --rebase
upstream $branch` is fine, if you know what that does.

I would just keep in mind that `git pull` wasn't meant to merge your changes to
upstream, it was meant to merge $branch to your integration branch.

> If that's the case, what would you recommend?

I would recommend `git fetch` + `git rebase` (or merge). If you are explicit
about what you want to do, surprises are minimized.

-- 
Felipe Contreras

Re: Weird merge records

[Dan Stromberg]

On Mon, May 8, 2023 at 8:03 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> > You seem to be implying that I shouldn't use 'git pull --rebase
> > upstream "$branch"'.
>
> If you know what you are doing, then do whatever you want. `git pull --rebase
> upstream $branch` is fine, if you know what that does.

I consider myself a git neophyte.  It's a large topic.

> I would just keep in mind that `git pull` wasn't meant to merge your changes to
> upstream, it was meant to merge $branch to your integration branch.

I see.

> > If that's the case, what would you recommend?
>
> I would recommend `git fetch` + `git rebase` (or merge). If you are explicit
> about what you want to do, surprises are minimized.

Might that look like:
        git checkout "$branch"
        git fetch upstream
        git rebase "$branch"
        git push origin "$branch"
?

Thanks!

Re: Weird merge records

[Felipe Contreras]

Dan Stromberg wrote:
> On Mon, May 8, 2023 at 8:03 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > > You seem to be implying that I shouldn't use 'git pull --rebase
> > > upstream "$branch"'.
> >
> > If you know what you are doing, then do whatever you want. `git pull --rebase
> > upstream $branch` is fine, if you know what that does.
> 
> I consider myself a git neophyte.  It's a large topic.
> 
> > I would just keep in mind that `git pull` wasn't meant to merge your changes to
> > upstream, it was meant to merge $branch to your integration branch.
> 
> I see.
> 
> > > If that's the case, what would you recommend?
> >
> > I would recommend `git fetch` + `git rebase` (or merge). If you are explicit
> > about what you want to do, surprises are minimized.
> 
> Might that look like:
>         git checkout "$branch"
>         git fetch upstream
>         git rebase "$branch"

With `git rebase` you specify the upstream branch you want to rebase to, so:

  git rebase upstream/master

This can be configured with the "upstream tracking branch" info, so:

  git rebase "$branch"@{upstream}

But this is the default of `git rebase`, so just:

  git rebase

>         git push origin "$branch"

If the branch already exists in the remote, you are probably going to need --force there.

Also, you don't need to checkout the branch, as `git rebase` can do that for you.

This is what I would do:

  git fetch upstream
  git rebase upstream/master $branch
  git push --force origin $branch

Hopefully in this scenario "upstream" is the upstream repository and "origin"
is your personal fork.

-- 
Felipe Contreras