2

We recently got into a situation wherein we could not push the code and got error message indicating "Control Freak... FoxTrot Merge"

Basically, this is our source tree-

Branch - A (this is a child of origin/develop which was off origin/master) Created Another branch B from A - Work on it Created another branch from C

At some point after few commits, it won't let us push any commits to C and complained about FoxTrot merge. We checked that bitbucket (enterprise) had a hook which blocks this.

We bypassed this (Since we really had to push the changes) by creating another branch D.

We don't know how we landed in this situation. How can we avoid this in future?

Rockoder
  • 746
  • 2
  • 11
  • 22

1 Answers1

4

I'm going to close this as a duplicate, but the "duplicate" question itself just defines foxtrot merges without explaining why they happen.

They happen because git pull means git fetch && git merge and that second git merge is a "foxtrot merge". It treats your work as the main branch, and someone else's work, done on master after you started on your work, as a secondary, probably-not-master branch. The goal of the hook is to prevent people from working on master and using git pull like this.

To avoid having this sort of thing happen, you can use this simple rule (perhaps a bit too simple but it works): never do any work on master yourself.

That is, after:

git clone <url>
cd <clone>

you begin work with:

git checkout -b feature/tall

to work on the new feature named tall. You, Alice—well, that's probably not your actual name, but I have three people doing things in this example, so I've assigned you the name "A"–do all your work on your own feature/tall, while Bob and Carol do all their work on their own feature branches, whatever their features' names are.

Then when your stuff is ready you do:

git checkout master && git fetch && git merge

or, if you like git pull (I don't):

git checkout master && git pull

You're now ready to merge your feature:

git merge feature/tall

and when the merge is complete—after resolving any merge conflicts if necessary—you can push again:

git push

and your work appears as a non-"foxtrot merge". Once your work is successfully merged and pushed you can delete your feature-branch. Meanwhile Bob and Carol can keep working on their features, or, if they finished before you did, your merge merges atop their merges.

torek
  • 448,244
  • 59
  • 642
  • 775
  • upvoting for instructions on how to land into this. however, i was also looking for how to trace it down to which commit could cause foxtrot merge which we can avoid. Went through the docs of github and it talks about first-parent and second-parent but I am not clear which developer's commit led us to that situation and why it is seen only after few commits and push and not at very first push in branch which is having this issue. – Rockoder Mar 20 '19 at 00:02
  • @Rockoder: making a regular commit never causes the problem. Running `git merge` incorrectly causes the problem (if you consider it a problem), and `git pull` *automatically* runs `git merge` incorrectly. To find who did it, look at each person's merge commits—but if you're using a centralized storage workflow with a bitbucket hook that prevents pushing such merges, the "who" *has to be you*. – torek Mar 20 '19 at 00:23
  • 1
    So, if (a) you consider this a problem and (b) you/your team has set bitbucket up like this, and (c) you get the error on `git push`, it means *you* ran `git pull`. *You* should not have run `git pull`: you should have run `git fetch`, and then run `git merge` yourself, running the correct merge instead of letting `git pull` run the wrong one. – torek Mar 20 '19 at 00:25
  • Why do you think it is not a problem? From my reading, it seems FoxTrot merge is pretty bad and it should not happen. Also on bitbucket, the default setting is to prevent it. There is an option to bypass Foxtrot merge. Is that a good option to follow? Can this screw up commit history? – Rockoder Mar 20 '19 at 19:05
  • 1
    I neither think that it *is* a problem, nor think that it *isn't* a problem. It's more a symptom of something that *might be* a problem: users blindly running `git merge`, particularly by invoking `git pull` without understanding what it does. In any case, whether it's a problem is clearly a matter of opinion—some people just don't care. Maybe they should, but they don't. – torek Mar 20 '19 at 21:04
  • As far as commit history goes, commit history *is* "the commits in the repository". That's all there is. These commits form lines and graph blobs, so that the Git commit graph is a Directed Acyclic Graph. Your goal as someone making commits is to make sure that the graph is useful to you-six-months-later (or whoever is working on the system six months later), and that sort of thing. All of this fussing-about with who merges what how is done in service of being useful to future-you. – torek Mar 20 '19 at 21:06