7

I cloned my new repo from Github and the file FETCH_HEAD in Working Directory -> .git contains the following:

fe300b2c9852acf68b4f1dd78ace916a083f3236    not-for-merge   branch 'master' of ssh://git@github.com/mike123/myRepo.git

What does not-for-merge mean?

Fizz
  • 4,782
  • 1
  • 24
  • 51
mike
  • 1,135
  • 4
  • 22
  • 39
  • "not-for-merge" is added by standard git too (2.25.1), so I'm suggesting a tag edit. Also according to https://stackoverflow.com/a/45543739/3588161 if you first check out a branch and then do a fetch that branch (only) will *not* be tagged with not-for-merge, but I can't confirm this right now. – Fizz Jun 06 '20 at 11:49
  • On some git-releated project a bug was mentioned in handling/generation of that https://github.com/libgit2/libgit2/issues/2236 – Fizz Jun 06 '20 at 11:51

2 Answers2

1

Basically, git fetch fetches branches and stores the result in the FETCH_HEAD file. When it's run as part of git pull, this information is later used internally to decide what needs to be merged.

In case multiple branches were fetched, only the ones not marked as not-for-merge are later merged. See also this blog post by Junio.

In your case, JGit (the library used by EGit for working with Git repositories) seems to behave differently than the command-line Git implementation. In command-line Git, there is no FETCH_HEAD right after cloning. But after the first time you pull, the file is there. Try pulling and see how the file changes. This difference in implementation should do no harm though.

robinst
  • 30,027
  • 10
  • 102
  • 108
  • I'm not quite following you. I've tried several tests and I can't find a case when FETCH_HEAD doesn't contain not-for-merge. Can you please show the steps to achieve this? – mike Aug 16 '13 at 19:14
  • @mike: Clone the repository a second time, create a new branch and push it, then fetch from the original clone and inspect `FETCH_HEAD`. – robinst Aug 18 '13 at 12:03
  • I'm still not seeing any difference in FETCH_HEAD. I've tried this with a brand new repo. (only a single master branch with a README containing the default two lines in it, as generated by Github.) Then I cloned twice. In the second copy, I created a new branch. I based this new branch on the remote tracking branch. Then I tried pushing the new branch both with and without committing on it first. But when I go back to the first clone and fetch, I still have not-for-merge in FETCH_HEAD. – mike Aug 19 '13 at 18:40
  • Did you do this in EGit or the command line? As mentioned, they may behave differently. – robinst Aug 20 '13 at 12:23
  • Ok, I misunderstood you. No, I used Egit not the command line. I don't have Git installed. I trust what you're saying, that there are differences in Egit versus the command line. But if it's as you said: `When it's run as part of git pull, this information is later used internally to decide what needs to be merged.` And `FETCH_HEAD` always say's `not-for-merge` how does Egit decide what's for merge. – mike Aug 20 '13 at 18:56
  • Ok, I wasn't sure from the question whether you only used EGit or both. In EGit, we don't really decompose the steps into `git fetch` followed by `git merge`, instead it's done directly in the implementation of `git pull`. How `git pull` knows what remote branch should be merged into the local branch, that is configured in `.git/config`, see the section for the current branch, then the `merge` attribute. – robinst Aug 21 '13 at 11:30
  • I don't understand the connection between `not-for-merge` always being in being `FETCH_HEAD` and whats in the config file. If I create a new repo, clone it in Egit then I'll have a master branch and a tracking branch for it. The config file will contain `[branch "master"] remote = origin, merge = refs/heads/master`. If I create a new branch based on `origin/master` (master's tracking branch) and select "None" as the pull strategy, then the config file will have no info about the new branch. If I select "Rebase" or "Merge" as the pull strategy then entries for the branch will be added to config – mike Aug 22 '13 at 18:27
-1

Egit is based on JGit, and "not-for-merge" is only used in org.eclipse.jgit.transport.FetchHeadRecord

That notForMerge variable of the FetchHeadRecord is set in the org.eclipse.jgit.transport.FetchProcess#want method.

    fhr.notForMerge = spec.getDestination() != null;

If the the refspec destination isn't null, then this fetched HEAD isn't for merge.

When you fetching a remote, the destination of a remote branches is refs/remotes/yourRemote, because of the local config for fetch refspec:

[remote "origin"]
   fetch +refs/heads/*:refs/remotes/origin/*

The one branch that would be fetched without a direct destination would be one which is tracking a remote branch:

[branch "master"]
        remote = origin
        merge = refs/heads/master

That is why, after a fetch of JGit repo (in command line, not in Eclipse Egit), I see:

C:\Users\VonC\prog\git\jgit\.git>type FETCH_HEAD
c2a9f9e742f7e6633af130823c154a485e6071b2                branch 'master' of https://github.com/eclipse/jgit
51d1af9489924ff03fa10ec963110c608c2882a3        not-for-merge   branch 'stable-0.10' of https://github.com/eclipse/jgit
989149736ad1cd09c15e143aa598028b9f9b6502        not-for-merge   branch 'stable-0.11' of https://github.com/eclipse/jgit
b2b58feba7400269df8b31ef8495b695af3a9793        not-for-merge   branch 'stable-0.12' of https://github.com/eclipse/jgit

Let's try to reproduce that in Egit/JGit (Luna, Egit 3.0, Win7 64-bits):

After several fetch, I never see an entry without a not-for-merge though.
Even a pull which would merge new comits from a remote branch would still generate a FETCH_HEAD with:

220c4502ecea147ef4beaae8039b168965e148e9    not-for-merge   branch 'master' of ..\..\jgit

I guess the behavior of JGit differs on that aspect.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • OK you've confirmed what robinst and I have said, that not-for-merge is always in `FETCH_HEAD` But the question remains, if not-for-merge is always in `FETCH_HEAD`, even when pulling, then how does `FETCH_HEAD` fit into the process? – mike Sep 07 '13 at 19:14