On 11/19/20 1:00 AM, Zimoch Dirk (PSI) wrote:
> Unfortunately, ' git config --global diff.renameLimit 0' does not help:
>
> $ git config --global diff.renameLimit 0
> $ git cherry-pick 76aa3aab0124b05e42ae5aa01ee27a78707d5d74...enable_mutex_PI
> error: could not apply 2c7dae9... osdMutex.h: fixed multiple-inclusion guard
> hint: after resolving the conflicts, mark the corrected paths
> hint: with 'git add <paths>' or 'git rm <paths>'
> hint: and commit the result with 'git commit'
> $ git status
> # On branch PSI-7.0
> # You are currently cherry-picking.
> # (fix conflicts and run "git commit")
> #
> # Unmerged paths:
> # (use "git add/rm <file>..." as appropriate to mark resolution)
> #
> # deleted by us: src/libCom/osi/os/posix/osdMutex.c
> # deleted by us: src/libCom/osi/os/posix/osdMutex.h
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> How do you apply changes in libCom from EPICS 3 to 7? You must be doing that all the time, but I have no idea how.
Personally, I don't do this so often these days as I'm working
almost exclusively with 7.0.
The first thing I would suggest is trying with the newest possible version
of git. You might also try adding '-s recursive -X patience', though this
may already the default for you.
Back when I was doing this more often, I moved large change sets around
incrementally with git-rebase. That is, I didn't go directly from say
3.14 to 7.0 directly. Instead I would move in stages up to one of the
large rename commits, then over it, then move onward. I found that this
seemed to help since the renames are detected as simple 100% moves.
If this sounds like a lot of work, it was.
>> -----Ursprüngliche Nachricht-----
>> Von: Michael Davidsaver <mdavidsaver at gmail.com>
>> Gesendet: Mittwoch, 18. November 2020 18:56
>> An: Zimoch Dirk (PSI) <dirk.zimoch at psi.ch>
>> Cc: 'core-talk at aps.anl.gov' <core-talk at aps.anl.gov>
>> Betreff: Re: another git question
>>
>> On 11/18/20 7:56 AM, Zimoch Dirk (PSI) via Core-talk wrote:
>>> Will git be able to handle files that have been moved to a different path?
>>
>> Most of the time, yes. Though there can be confusion
>> when eg. both a move and a rename are detected.
>> Some of the osd*.c files do this.
>>
>> Before merging you will probably want to set:
>>
>>> git config --global diff.renameLimit 0
>>
>> This overrides a conservative default intended to speed
>> up merges of very large projects (aka. the linux kernel).
>> I've never had noticed this with Base.
>>
>> cf. 'man git-config'
- References:
- another git question Zimoch Dirk (PSI) via Core-talk
- Re: another git question Michael Davidsaver via Core-talk
- AW: another git question Zimoch Dirk (PSI) via Core-talk
- Navigate by Date:
- Prev:
Re: Problems with hanging osiSockTest Johnson, Andrew N. via Core-talk
- Next:
Re: AW: Problems with hanging osiSockTest Michael Davidsaver via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
AW: another git question Zimoch Dirk (PSI) via Core-talk
- Next:
Re: another git question Yendell, Gary (DLSLtd, RAL, LSCI) via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|