# git merge and generated files? - Thread: https://externals.io/message/59188 - Original archive: https://news-web.php.net/php.internals/59188 - Started by Pierre Joye on 2012-03-28T00:14:40+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #59188 — Pierre Joye — 2012-03-28T00:14:40+00:00 URL: https://externals.io/message/59188#59188 hi! How do you solve: $ git merge --no-ff --log PHP-5.4 Auto-merging Zend/zend_language_scanner.c CONFLICT (content): Merge conflict in Zend/zend_language_scanner.c Auto-merging Zend/zend_language_scanner_defs.h CONFLICT (content): Merge conflict in Zend/zend_language_scanner_defs.h Automatic merge failed; fix conflicts and then commit the result. so I do not have to resolve them every 2nd commit? This is really annoying :) Thanks for any good idea, Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #59189 — Stas Malyshev — 2012-03-28T00:33:21+00:00 URL: https://externals.io/message/59188#59189 · In reply to: #59188 Hi! > $ git merge --no-ff --log PHP-5.4 > Auto-merging Zend/zend_language_scanner.c > CONFLICT (content): Merge conflict in Zend/zend_language_scanner.c > Auto-merging Zend/zend_language_scanner_defs.h > CONFLICT (content): Merge conflict in Zend/zend_language_scanner_defs.h > Automatic merge failed; fix conflicts and then commit the result. > > so I do not have to resolve them every 2nd commit? Why would these change every 2nd commit? These only should change when you change the scanner, which happens very rarely. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #59190 — Pierre Joye — 2012-03-28T00:38:04+00:00 URL: https://externals.io/message/59188#59190 · In reply to: #59189 > Hi! > > > […] > > Why would these change every 2nd commit? These only should change when > you change the scanner, which happens very rarely. It depends what you do, but still annoying when it happens. But that does not answer the question... cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #59191 — Stas Malyshev — 2012-03-28T00:43:59+00:00 URL: https://externals.io/message/59188#59191 · In reply to: #59190 Hi! > > […] > > It depends what you do, but still annoying when it happens. > > But that does not answer the question... Looking at the patch, it looks like yours and git's line endings did not match, which may have caused the conflict. I think it'd be also the best to resolve such conflicts by leaving the files as-is, maybe just by using git reset or using git mergetool and choosing the "old" variant. Depending on the system mergetool would use different tools so I'm not sure which one would be best on yours. I usually just use mergetool, mark every change to resolve to "old" variant and that cleans up the commit. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #59192 — Kris Craig — 2012-03-28T00:54:00+00:00 URL: https://externals.io/message/59188#59192 · In reply to: #59191 Pierre, On Tue, Mar 27, 2012 at 5:43 PM, Stas Malyshev wrote: > Hi! > > > […] > > Looking at the patch, it looks like yours and git's line endings did not > match, which may have caused the conflict. Stas is right. Looks like the Windows CR line endings are causing it to puke on ya. I'm assuming you're working in Windows, right? What Git client are you using? If you're using Msysgit, it automatically converts these line endings for you specifically to avoid this problem, but you have to select that option during the installation process when it prompts you. I don't know if the setting can be changed after install; my guess would be it can, but I have no idea how. The easiest thing to do would be to just re-run the Msysgit installer (if that's what you're using) and when prompted select the option to auto-convert line endings (i.e. I think the option is something along the lines of "Use Unix-Style line endings"). --Kris > I think it'd be also the best > to resolve such conflicts by leaving the files as-is, maybe just by > using git reset or using git mergetool and choosing the "old" variant. > Depending on the system mergetool would use different tools so I'm not > sure which one would be best on yours. I usually just use mergetool, > mark every change to resolve to "old" variant and that cleans up the > commit. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #59193 — Yasuo Ohgaki — 2012-03-28T01:01:56+00:00 URL: https://externals.io/message/59188#59193 · In reply to: #59191 Hi, 2012/3/28 Stas Malyshev : > Hi! > > > […] > > Looking at the patch, it looks like yours and git's line endings did not > match, which may have caused the conflict. I think it'd be also the best > to resolve such conflicts by leaving the files as-is, maybe just by > using git reset or using git mergetool and choosing the "old" variant. > Depending on the system mergetool would use different tools so I'm not > sure which one would be best on yours. I usually just use mergetool, > mark every change to resolve to "old" variant and that cleans up the > commit. Besides the line ending problem, it's annoying when we're working on single work dir. All developers should have required build tools. How about remove generated C files from repository? These files are only needed for released versions, I suppose. We still compare generated C files against released versions and this would be sufficient for most developers. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net