2

I have an old stash of working tree that is now some dozens of commits old. This stash nevertheless still represents useful work on a feature I need to bring forth. I abandoned it prior as I had to switch to a higher-priority feature since, stashing the former. Now, as always, my master represents current state of the art, obviously, but I need to take up work on the old feature. I don't think I want or need rebase at all. In fact, I won't be committing (other than stashing) until the feature is done.

Since stashes are commits, I thought I'd see if I can produce a working tree incorporating the said abandoned feature work and the current master branch. I did:

git checkout stash@{0}
git merge --no-ff --no-commit master

The long options for git merge were just to make sure I have a chance to review the merge. What was surprising was that everything went butter smooth. Looking at the two versions of one file that had most changes, it's obvious to me that I do not want the merge Git did.

Now, what I want is for Git to produce the kind of file(s) I get when I have merge conflicts -- one with <<<<< and >>>>> giving me sections that are different. I will edit these file(s) into a sensible state and just take it from there, no problem.

Either that or I am preparing to use git format-patch and git merge-file (which I am unsure of as I never used it) to give me a patch file which I will tweak and apply on top of stash@{0} most likely.

What is the idiomatic way to "induce" a case of merge conflict as described, even in situation where Git does not see one?

Armen Michaeli
  • 8,625
  • 8
  • 58
  • 95
  • https://stackoverflow.com/questions/10131577/forcing-git-merge-to-declare-all-differences-as-a-merge-conflict – Josh Lee Apr 18 '17 at 16:28
  • 1
    You probably can't trick the merge algorithm into declaring that the files conflict, but you could probably get git into a state where `mergetool` will bring up the various versions as though they were unmerged. – Josh Lee Apr 18 '17 at 18:14
  • I am voting to close my own question as it either may have too many right answers or none, because it may be technically vague and I am not even sure now which problem I need to solve. – Armen Michaeli Apr 20 '17 at 08:13

1 Answers1

1

Some of the things you wrote could be improved a lot (using stash instead of feature branches, committing seldomly), but you seem pretty set on them.

As to your actual question: create new temporary commits on top of both the commits you are merging. Embellish every hunk you want to conflict with some irrelevant changes. That could be white space, comments or whatever. Then merge those new commits and you will get conflicts.

AnoE
  • 8,048
  • 1
  • 21
  • 36
  • I have to admit that after posting the question I came to think that it is not a very useful one here on SO/SuperUser. I could just use the parent of the stash, merge master onto it, point the feature branch tip to it, and apply the stash, at which point I'd either get my merge conflict or a guarantee that everything is applied perfectly. It took me a bus ride home to think it out. Sorry I am wasting your time, hope you did get something out of my question :) I don't commit seldom, but I typically commit only what at least builds, and what was stashed did not build at all. – Armen Michaeli Apr 19 '17 at 08:31
  • 1
    Yeah, it's not a problem. ;) Sometimes a bus ride is all it takes. – AnoE Apr 19 '17 at 15:18