CODEWITHSUNDEEP
gitversion-controlbitbucket
AnonymousAlias
AnonymousAlias

Reputation: 1399

GIT is showing a file as moved on bitbucket - i want it as a new file for pull request

As I mentioned in the description when i look at my pull request it looks like the files are moved, this is because it is a common functionality file where i copied another file in and started editing. I would prefer for my pull request that it showed as a brand new file rather than a moved file. I tried deleting the 2 files and committing and then creating new files and pasting the code in and committing again but this didn't work.

Upvotes: 1

Views: 1897

Answers (2)

torek
torek

Reputation: 487755

Files in commits are never really new, or old, or moved, or anything. They are simply there in the commit. Any files that aren't in the commit, are not. That's all there is, because each commit simply holds a snapshot of all of the files that Git knows about.

Now, if you take any two different commits, and place one on the left side and the other on the right side, now you can compare the left-side files to the right-side files. When you do this, you may have the same file names, or different file names. The contents of each of those named files can be the same, or different. It's up to whoever does the comparing to decide: is the left-side file named hello the same file as the right-side file aloha?

Git itself, when comparing files, normally uses the following short-cut:

  • If the left-side commit has a file named F, and the right-side commit has a file named F, these are "the same" file, even if F's content on the left and right side differ. If the contents do differ, Git will construct and show a recipe by which you can change the left F into the right F.

  • But if the left-side commit has a file named L and the right side doesn't, and the right-side commit has a file named R that the left side doesn't: well, now Git will optionally compare the contents of left-L to those of right-R. If the contents are similar enough, Git will say that L got renamed to R: the two files will be paired-up and Git will produce any recipe required to change L into R, starting with the "rename L to R" step.

This process of pairing left and right side files is the way the version control system decides which files are "the same" files in the two commits. Just because the files have the same name doesn't necessarily mean they're the same file, though. Depending on the Git operation, you can instruct Git to break pairings in some cases. For the "detect a rename and pair up differently-named files" cases, there can be controls to enable or disable it, and to set the threshold at which Git decides that two files are similar enough.

The tricky part with a Pull Request (PR) is that PRs are not actually part of Git at all. A PR is handled by some hosting service, in some hosting-service-specific way. The hosting service typically chooses how to run one or more git diff commands to compare left and right side commits, then shows you Git's output. Can you convince the hosting service to set the parameters for this kind of git diff? If so, you may be able to convince it to show your PR the way you'd like to see it. If not, then you're just out of luck: they will show your PR the way they show it.

(Bitbucket over the last few years have had several different engines for doing these comparisons, but as far as I know, they don't have this kind of fine-grained control. You can of course just fetch the request into a local command-line Git repository and look at it that way.)

Upvotes: 1

eftshift0
eftshift0

Reputation: 30156

Other than keeping the old file, of course, you can't force git to show it as a new file.... actually, it's just some guessing from git.... git does not care for the most part... it's not part of the information that is saved in a revision.... git will do its best to try to see what happened with files if you merge or cherry-pick or whatever later on.

Upvotes: 0

Related Questions