Weird merge records

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!

Hi,

On 2023-04-28 11:34, Dan Stromberg wrote:

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

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

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/

On Sun, May 7, 2023 at 1:34 PM Felipe Contreras <felipe.contreras@gmail.com> wrote:

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

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

Dan Stromberg wrote:

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.

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

On Mon, May 8, 2023 at 8:03 AM Felipe Contreras <felipe.contreras@gmail.com> wrote:

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

I see.

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

Thanks!

Dan Stromberg wrote:

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

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.

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

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

I'll keep this in mind.

Thanks.