Possible to branch off and use a file within project in Git?

[Elaine Byrne]

Hi Folks

Git beginner question here: I want to make a copy of a Java file (containing a single class), modify it, test its performance in comparison to the original from another file contining the main project/program class, and then may or may not want to replace the original file with the modified one, or continue to use in parallel (both processing data, or user choosing between them via a GUI button).

Ideally, I would like the 'child' file, which would of course have a different name from the parent, to have the 'parent' history asociated with it up to the point of branching. Then if it ere to replace the parent later, I uppoe that would be a merge. I've Googled a little and am experimenting with a test project, but thought I would ask here to try to get an idea more quickly if this something that is ever done, or even possible. It's not something I want to spend much time on right now, so I would rather drop it if not straightforard.

[Raju Gandhi]

It seems to me you want to create a new file, but have Git treat it like the "parent" (in that it maintains the Git history). The only (easy) way I can think of this is to create a branch, use `git mv` to rename the "parent" (Git now knows you've renamed the file and you can trace it's history), and make your modification. However, this means that you'll lose the "parent" in that branch.

If you simply want to compare performance, then look into `git worktree` that allows you to have two branches checked out at the same time—then you can run one branch, measure performance, and repeat with the other branch.

Now if you want to keep _both_ later on, that might be a tad tricky—b/c Git knows that the "parent" was renamed to "child" so when you merge Git will attempt to rename "parent" to "child". Not sure how you'd get around that.

Reference: See https://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename-files-in-git-and-maintain-their-history

Hope this helps. Feel free to reach out if you have any other questions.

Raju

[Elaine Byrne]

Thanks Raju

In fact, looking at that link, I now realise that even renaming a file is a big issue, which is unfortunate as I now want to rename the original file anyway, never mind about the naming and hsitory of the code I plan to modify from a copy of the original code, so I'll have to be careful about that! Also, I might want to keep modifying both parent and child files in parallel (with independent changes), and compare their performance in the same run, so I think I'll forget about trying to preserve history, and just write a note in the comments at the top of the new file about its origin.

[Stephan van Hulst]

Elaine Byrne wrote:so I think I'll forget about trying to preserve history, and just write a note in the comments at the top of the new file about its origin.

Don't. Just treat it as a separate file.

If you have code duplication, refactor it away. For instance, both classes could implement a common interface and make use of common components or utilities.

[Elaine Byrne]

Thanks Stephan

(I'm not sure if this is what you have in mind, but when I copy a tracked file (giving it a new file and class name) to work in the same project, then commit, the history of the copied file does not appear to be associated with the new one. I think I'll shelve this quest for the moment.)