<div dir="ltr"><div><div>Yes what you say is right and @daviddavis also pointed this out to me via IRC. I'm glad you posted this clarification.<br><br></div>One aspect of this is how many commits those actions are spread over. For `git mv` to be handled the same as `git rm` + `git add`, both the 'rm' and 'add' must occur within the same commit. I believe that if `git rm` and `git add` occur in different commits, the merge forward would show as an update/delete conflict due to the diff of one commit only being `git rm`.<br><br></div><div>Thank you for posting this.<br><br></div>-Brian<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 3, 2016 at 3:26 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Excellent advice!<div><br></div><div>However, I think we may have acquired some collective "knowledge" at some point about git mv that's not correct. This note inspired me to go look at docs for "git mv", just to make sure my understanding was right. A little voice of doubt was saying to me "It's all about diffs; is git really tracking name change relationships persistently?"</div><div><br></div><div>According to this documentation, apparently not. "Git has a rename command git mv, but that is just for convenience. The effect is indistinguishable from removing the file and adding another with different name and the same content."</div><div><br></div><div><a href="https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_not_.22track.22_renames.3F" target="_blank">https://git.wiki.kernel.org/<wbr>index.php/GitFaq#Why_does_Git_<wbr>not_.22track.22_renames.3F</a><br></div><div><br></div><div>I'm interpreting that to mean that if we never use "git mv" again, nothing will have been lost except for the time to make a few extra key strokes.</div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Nov 3, 2016 at 3:06 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div>As we introduces changes to both the 2.y line and 3.0-dev branches, the following behaviours will help us avoid loosing changes in Pulp3:<br><br></div><div>- When moving code, use git mv. If you need to edit it after moving it edit after the `git mv`. *<br><br></div><div>- When moving code in pulp3, move the code, don't just copy it. This usually involves deleting something out of pulp.server. For example dkliban deleted the old code in this commit [0]. **<br></div><div><br>- Consider checking in on your bugfix or feature introduced in 2.y to see if it made it all the way to 3.0-dev. We can merge forward together or you can ask me to merge forward if you want to be sure.<br></div><div><br></div><div>Continue merging forward the 2.y branches to master and leaving your changes there. I will continue to periodically merge master -> 3.0-dev which.<br></div><div><br></div><div>*: git mv allows git to resolve any changes from 2.y into their new locations in 3.0-dev. For example when we move around our docs on the 3.0-dev branch, using `git mv` allows any updates to docs on 2.y to land in the right locations when the merge forward occurs.<br></div><div><br>**: If a bugfix or feature change is introduced on 2.y, when master is periodically merged into 3.0-dev a conflict will be noticed because the edit from 2.y conflicts with the deleted code. This will allow us to update the moved code with the change to resolve the conflict. If the old code was left this would never be noticed when the merge forward occurs.<br><br>[0]: <a href="https://github.com/pulp/pulp/pull/2815/files" target="_blank">https://github.com/pulp/pulp/p<wbr>ull/2815/files</a><br></div><div><br></div>Happy coding,<br></div>Brian<br></div>
<br></div></div>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>