merge-conflict | An exercise from the Git for Scientists course | Learning library

As bk2204 said in a comment, this is the wrong way to go about things. But let's answer the title question. If you do want to create a conflicted index entry, git update-index is indeed the right (and only) tool for this:

• An index entry is, by definition, conflicted / unmerged if and only if it has a nonzero stage number.
• Only git update-index offers the ability to insert an index entry with a nonzero stage number.

But git update-index does not support setting these 'stage values' ...

This claim is wrong. However, to set a nonzero staging number is nontrivial. Reading the git update-index documentation closely, we find just one way to do this:

--index-info
     Read index information from stdin.

USING --INDEX-INFO

--index-info is a more powerful mechanism that lets you feed multiple entry definitions from the standard input, and designed specifically for scripts. It can take inputs of three formats:

1. mode SP type SP sha1 TAB path

   This format is to stuff git ls-tree output into the index.

2. mode SP sha1 SP stage TAB path

   This format is to put higher order stages into the index file and matches git ls-files --stage output.

[format 3 snipped; boldface above is mine]

To place a higher stage entry to the index, the path should first be removed by feeding a mode=0 entry for the path, and then feeding necessary input lines in the third format.

Note further that because you have to place a hash ID into the index, you must first make sure that the data you want exist as a blob object. To get that, use git hash-object -w -t blob (though you can leave out the -t blob since that's the default).

So what I want to do is the following, in case git merge-file fails:

• Add the file original.base as 1 derived (base)

Since original.base already has a hash ID (e.g., 4b48deed3a433909bfd6b6ab3d4b91348b6af464), you can just use that. Let's say that's in $hash1 at this point.

• the file original as 2 derived ('our' modification)

This also has an existing hash ID, let's say $hash2.

• and the original derived file as 3 derived ('their' modification) into the index

For this, you'll have to derive the file again (I think—I may have mis-read something in the question) and run git hash-object:

One way to automate this is with bash:

A stash stores both the state of the index and the state of the working tree, because those are both things you might have in an incoherent or unfinished state. Making a stash puts both the index and the work area into commits and rolls both back to the head commit state; the index commit then has the current head as parent, and the work tree commit has the index commit and the current head as parents, making the stash’s content a merge commit. You can actually see this structure by doing a git log on your stash entry (your identifier numbers will be different of course):

If you do the checkout of your commit after the first merge to master, you will get an "Everything is up to date" when merging from master.

Unfortunately, the action that should be triggered by pull_request is not going to run if the pull request has merge conflicts. It's a limitation of GitHub Actions as described here: https://github.community/t/run-actions-on-pull-requests-with-merge-conflicts/17104/2

Firstly, it is good practice to stay up to date with DEV branch in the feature branches since you will have to merge the changes anyway at some point. I have never been in the situation where it is bad to be up to date with DEV branch, but I can imagine some scenarios.

One workaround for the above is to continue with the merging on the web and allow the remote DEV branch be merged into your remote feature branch. Your local feature branch, however, is still at the place before DEV was merged.

At this point you can force push the local changes to the remote branch, thereby resetting the remote feature branch to where you want it to be.

There has to be at least a single line of separation that remains the same so that they can be treated separately and not produce a conflict. Given that they are not separated by a line that stays the same on all 3 revisions (the two tips and the common ancestor) then they are treated as a single block. One branch modifies that block one way, the other in another way... so, conflict.

what I am really looking for is that I should see the options "Accept Current Changes" and "Accept Incoming Changes" when I pull remote repo to my local machine.

A while ago I was working on a project whose code was continuouslyy being pushed to github and each time I used to pull the code from remote, I would get a merge conflict in some files.

Why did I see those two options in the project I mentioned?

Because you had committed local modification that were not pushed.
And then you pulled modifications from the remote for the same file. That triggered a conflict.

But for your own repository, where you are the only one working on it, and pushing to it, a pull is likely to not trigger any conflict, which will explain the lack of "Accept Current Changes" and "Accept Incoming Changes".

Git doesn't let you perform a merge without having a working tree, so if you want to merge two branches, you need to check one of them out and merge the other. There isn't a tool to check just for merge conflicts, and with the state of Git now, it would be a little tricky to add that functionality. If you want to use Git, you can do this: