Stephen Morton <stephen.c.mor...@gmail.com> writes: > On Thursday, 26 January 2017 16:37:16 UTC-5, Magnus Therning wrote: >> >> >> Stephen Morton <stephen....@gmail.com <javascript:>> writes: >> >> > I'm looking for a git branching and merge strategy for merge with >> > lots of conflicts requiring multiple people. I can make it work, >> > and I understand git, but it all seems kind of awkward and it feels >> > like there must be a better way. >> > >> > I've got a big git merge to do. There are lots of conflicts and it >> > requires many people to resolve them all. >> >> Have you looked at git-imerge? >> > > No, I had not looked at git imerge. It looks interesting for some of the > merges we do. Thanks. > > git imerge is of course a tool to help you to resolve the conflicts in a > big merge. My question really was much more along the lines of once the > conflicts are resolved, what is the best way to arrange the commits/merges > (the DAG) to represent a complex multi-step conflict resolution in git. So > although very useful-looking, 'git imerge' isn't really an answer to my > question. However, I see from the docs/video that 'git imerge' has a number > of optional solutions to my question when running its finish/simplify > command: [merge, rebase, rebase-with-history, full]. I imagine most people > eventually just take 'merge' or 'rebase'. The 'rebase-with-history' and > 'full' options are interesting and do present a novel 'more git-y' solution > to my problem, although you can really only achieve them using something > like 'git imerge'. > So it looks to me like really if not using something like 'git imerge' > from the beginning, if just resolving all the conflicts as a series of > commits after the fact, there is not more 'git-y' way to do what I want to > do. We will resolve all the conflicts as described originally works and > then just use that final state to make one single merge commit to represent > the whole merge, perhaps saving all the conflict resolutions in a branch > for posterity.
I don't understand what you mean by "represent a complex multi-step conflict resolution". What is it you want represented beyond a merge changeset (merge), or maybe several of them (rebase-with-history)? git-imerge isn't magical, it just automates step that you can do manually if you want to. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Computer Science: "In low-level languages like C" Computer Engineering: "In high-level languages like C" -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
