threads / discuss / 16237

force a merge conflict

Subject: force a merge conflict

## tl;dr

7 messages between Nov 9, 2008 and Nov 11, 2008.

replies: 6people: 3as markdown or json

Caleb Cushing· Nov 9, 2008, 15:09 UTC · lore
is there any way to force a merge conflict?

there are 2 projects which have basically diverged becoming incompatible, and both have updated since there common ancestry. I'm working slowing on merging them back together.

in this case I have a dev branch and fork branch the fork is a copy of dev except I committed one of the files from the fork. I need to merge this file back into dev, but git thinks it's a fast forward, because it really is for git, in reality it isn't, both files have newer history than their common ancestry.

-- 
Caleb Cushing
Deskin Miller· Nov 9, 2008, 18:39 UTC · re: Caleb Cushing · lore

Re: force a merge conflict

On Sun, Nov 09, 2008 at 10:09:49AM -0500, Caleb Cushing wrote:
> is there any way to force a merge conflict?

I'm not sure a 'conflict' is what you want, based on what you say below; rather, it seems you simply want to force a 'merge commit', i.e. a commit with multiple parents.

Show 5 quoted lines
> in this case I have a dev branch and fork branch the fork is a copy of
> dev except I committed one of the files from the fork. I need to merge
> this file back into dev, but git thinks it's a fast forward, because
> it really is for git, in reality it isn't, both files have newer
> history than their common ancestry.
git merge --no-ff ?

Hope that helps, Deskin Miller

Caleb Cushing· Nov 9, 2008, 20:19 UTC · re: Deskin Miller · lore

Re: force a merge conflict

> I'm not sure a 'conflict' is what you want, based on what you say below;
>  rather, it seems you simply want to force a 'merge commit', i.e. a commit with
>  multiple parents.
>
> git merge --no-ff ?
>

I tried that but I don't see that it's any different than a fast forward in this scenario. Actually I don't see any difference between it and a fast-forward.

-- 
Caleb Cushing
Deskin Miller· Nov 9, 2008, 20:35 UTC · re: Caleb Cushing · lore

Re: force a merge conflict

On Sun, Nov 09, 2008 at 03:19:57PM -0500, Caleb Cushing wrote:
Show 10 quoted lines
> > I'm not sure a 'conflict' is what you want, based on what you say below;
> >  rather, it seems you simply want to force a 'merge commit', i.e. a commit with
> >  multiple parents.
> 
> >
> > git merge --no-ff ?
> >
> I tried that but I don't see that it's any different than a fast
> forward in this scenario. Actually I don't see any difference between
> it and a fast-forward.

Look at the results of 'git merge' and 'git merge --no-ff' in gitk. Or, compare the resultant sha1 for the two commit objects. Or, look at 'git log' of the resulting commit objects, and look for a 'Merge:' line.

Deskin Miller
Brett Simmers· Nov 10, 2008, 19:11 UTC · re: Caleb Cushing · lore

Re: force a merge conflict

> I tried that but I don't see that it's any different than a fast
> forward in this scenario. Actually I don't see any difference between
> it and a fast-forward.

If you want to be given a chance to edit the result before the merge commit, you probably want 'git merge --no-commit'.

-Brett
Caleb Cushing· Nov 11, 2008, 17:10 UTC · re: Brett Simmers · lore

Re: force a merge conflict

> If you want to be given a chance to edit the result before the merge
>  commit, you probably want 'git merge --no-commit'.

That's the closest to what I need to do... unfortunately it's not what I need to do. Apparently I'll have to do a vimdiff outside of git since git doesn't appear to be capable of doing what I need it to do.

-- 
Caleb Cushing
Caleb Cushing· Nov 11, 2008, 17:24 UTC · lore

Re: force a merge conflict

Show 6 quoted lines
> Is not the following option of the merge just for it?
>
>  --no-commit
>     Perform the merge but pretend the merge failed and do not
>  autocommit, to give the user a chance to inspect and further tweak the
>  merge result before committing.

yes and no... it doesn't auto-magically allow me to do what a merge conflict does. which is put together a diff. all it really did was not commit the auto merge.

as far as --no-ff I'm not saying it commits the same way but I didn't see any difference in the resulting diffs, which, imho, all that matters is whether the resulting merged code is correct.

-- 
Caleb Cushing

← back to recent threads