Clash Royale CLAN TAG

How to have a tracked file in a git repo that doesn't change from branch to branch

What I’m sort of looking for:

I’m looking for a way to have a file or (better yet) a directory in a project repo that is part of the repo (tracked), but is left unchanged by switching branches.

Also, know that I am not adverse to considering something other than Git. Its just what I'm use to.

Use case:

I have a personal project which I want to apply the magic of git to. There is one catch so far.

I have a file that is not part of the actual code. It is not meant for production. Its sole purpose for existence is so that I have a place to write down ideas when they come to me, or to brain storm when I'm stuck. I usually am editing this in parallel with whatever else I'm doing, and I keep it open at times. It doesn’t matter what I’m doing, its the same file whose contents are in no way dependent on what branch I’m on.

I do not want this file altered when I switch branches. To me, its kind of this floating file that is part of the project and could use versioning. However, its not really connected in a coding way to the rest of the files so when I checkout some files, this floating file should not change, but when I commit, I want the planning file to be committed as well, but not so much to a branch but to the repo. This of course doesn’t make sense because Git doesn’t work that way, but that doesn’t mean that I can’t do something that provides a similar result.

I have some files that are part of a project but exist outside the normal structure. I want these files tracked, but left unchanged when I switch branches, or always exist in the same form on all branches.

Possible (but rejected) solutions:

The first thing I search for was “branch specific exclusion” which lead to worktrees. This can sort of be done with per worktree exclusion. What I figure I can do is have a work tree ../planning/ , set it to exclude everything except the contents of ../planning/planning/ (which exists as ./planning/ in the main tree). In the main tree, I then merge in the planning branch.

../planning/

../planning/planning/

./planning/

The problem here is that the directory structure is weird, and files are unnecessarily redundant. Also, I can foresee a merge going wrong and messing up the rest of the files in the project.

Also a little voice in my head is telling me that I’m overlooking some major flaw.

Thinking of overlooking things and major flaws. . .submodules (which seem to be the single most maligned feature of git).

The next thing I came across was a submodule. This was in my search for “subproject”, which are like independent repos inside another repo. Then I started reading about them. The main problems as far as I’m concerned are that they seem to need their own remote (don’t want this), and unless you are constantly vigilant, you can easily mess things up, sometimes silently. Errors are bad; silent errors are much worse.

Even if I was willing to hope I don’t mess up to terribly, submodules seem to be of use when you have a separate upstream, which is exactly the sort of thing I don’t want. Of course, if this is what needs to be done. . .so be it.

Unless I’m missing something, I don’t see any advantage of using subtrees, in my case, to symlinking a repo to subdiretory.

It seems to me as if a subtree is less of a part of the “super-tree” than a submodule is.

However, since this is just a bash script, it seems as if I can make something like this work that doesn’t require a separate remote.

While searching for “one repo several projects” I found a Stack Overflow question on that very subject (not mine, but what I searched). The best/first answer was about orphaned branches. This looked really promising since it most closely matches what I had in my head---a separate branch from the main trunk. The problem is it I can’t be working on both the planning documents (which are always open) and whatever file from the actual project needs to be worked on.

At first I thought either Gitslave (which is no more) or Meta, would be able to do what I want, after learning of them, but it doesn’t appear so. They perform the same action, it seems, on each repo in the super/meta-repo. If I had two repos, then the one for planning would have an extremely simple branch structure; what branch I’m on in the planning repo shouldn’t change based on what I’m on in the main repo.

While this would accomplish part of what I want, it runs contrary to the stated requirement that the files in question are part of the project repo. This is the fall back in case what I want is impossible since it accomplishes everything else.

To keep everything tidy, I’d symlink files into place within the directory for the main project.

Final thoughts:

So far none of the things I’ve looked at or considered seem to do what I want them to. At this point I doubt there is a solution that fits what I am looking for, however, I’m hoping that someone with more experience knows of something I am overlooking that might satisfy my needs. If not, then I would like to know what my best option is among imperfect solutions.

Continued efforts

Someone actually asked this here and the answer was that Git doesn't have this feature and the reasons were given. It was a shot in the dark, and I didn't think that it would be possible, but. . . one can hope right?

Other things I’ve read:

https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree

https://spin.atomicobject.com/2016/06/26/parallelize-development-git-worktrees/

What would I use git-worktree for?

https://git-scm.com/book/en/v2/Git-Tools-Submodules

Difference between subprojects and submodules in Git?

https://www.quora.com/How-do-I-handle-sub-projects-using-Git

https://gist.github.com/gitaarik/8735255

https://medium.com/@porteneuve/mastering-git-submodules-34c65e940407

https://medium.com/@porteneuve/mastering-git-subtrees-943d29a798ec

https://makingsoftware.wordpress.com/2013/02/16/using-git-subtrees-for-repository-separation/

What's the best practice for putting multiple projects in a git repository?

git status

git push --mirror

1 Answer
1

I have a fairly satisfactory solution. With all the things I've considered before in front of me I considered combinations of them. In particular the worktree and the orphaned branch.

The concept

The concept is to have a worktree that is on an orphaned branch.

The orphan has nothing in common with anything else in the project, which is desired since the planning documents are not part of the code. This method produces an empty directory so there is no mess. It just looks like another directory, but you do have to make a separate set of commits, though I think there is a way to commit all branches at the same time.

How to do it.

mkdir myRepo
cd myRepo
git init


There needs to be some commit here so the worktree can be made.

touch deleteMe
git add deleteMe
git commit -m "initial commit"


mkdir planning
git worktree add --detach planning
cd planning


git checkout --orphan=planning
git rm -f deleteMe
touch commitMe
git add commitMe
git commit -m "initial commit"


It isn't necessary to make the worktree before the orphaned branch, however it is easier. I've done it both ways, and this method seems cleaner.

Result

I now have two work areas, one of which is detached from the other. The only thing that I can see going wrong is being in ./planning/ and accidentally checking out a branch thinking I'm somewhere else in the repo.

If I could add two features to this set up, it would be to allow me to prevent changing branched in the worktree (or better giving the worktree its own set of branches) and allowing me to commit all worktree branches with a single git commit command.

git commit

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.