Yes what you say is right and @daviddavis also pointed this out to me via IRC. I'm glad you posted this clarification.
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`. Thank you for posting this. -Brian On Thu, Nov 3, 2016 at 3:26 PM, Michael Hrivnak <[email protected]> wrote: > Excellent advice! > > 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?" > > 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." > > https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_ > not_.22track.22_renames.3F > > 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. > > Michael > > On Thu, Nov 3, 2016 at 3:06 PM, Brian Bouterse <[email protected]> > wrote: > >> 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: >> >> - When moving code, use git mv. If you need to edit it after moving it >> edit after the `git mv`. * >> >> - 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]. ** >> >> - 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. >> >> 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. >> >> *: 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. >> >> **: 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. >> >> [0]: https://github.com/pulp/pulp/pull/2815/files >> >> Happy coding, >> Brian >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
