2

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.

In short. . .

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.

Things to note

  • I am the only one committing (or even looking at it).
  • I have two machines I will be using when working on this.
  • When I push the repo to remote, I want everything pushed.
  • The file in question is not shared with other projects (the normal use of subtrees and submodules).
  • Unless there are unavoidable technical limitations, I don’t see having more than one remote (the one for the project).
  • These files don’t need any kind of multi-branch scheme for themselves (all commits for that file exist on the same branch or simultaneously to all branches).

Possible (but rejected) solutions:

Worktree

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.

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.

Submodule

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.

Subtree

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.

Use an orphaned branch

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.

Gitslave/Meta

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.

Just have a separate 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

Commit to all branches.

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?

Community
  • 1
  • 1
Nero gris
  • 562
  • 7
  • 15
  • It sounds like the solution is a notebook. – Daniel Mann Jul 27 '18 at 00:31
  • @DanielMann I'm guessing you're I'm SOL? – Nero gris Jul 27 '18 at 00:35
  • Regarding the use of submodules: while your case isn't specifically suitable for submodules (a submodule and its states _are_ parts of a project, so in different branches one has different states by definition), there're no "slient errors" there. `git status` clearly shows that there's something to bother about if submodule worktree differs from its prisitine state. – user3159253 Jul 28 '18 at 22:32
  • @user3159253 Thanks. I'll keep that in mind, however I actually worked out something that is close enough to what I want; I've written it up, but want to step back before reviewing it and posting it. Also, I tried a submodule approach earlier today, and it had some other draw backs. Because I want one remote per repo, if I run `git push --mirror` it makes a mess of things. – Nero gris Jul 28 '18 at 22:37

1 Answers1

2

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.

Step 1: Make a repo

mkdir myRepo
cd myRepo
git init

Step 2: Make an initial commit

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

git commit -m --allow-empty "initial commit"

Step 3: Set up the worktree

mkdir Plan
git worktree add --detach Plan
cd Plan

Originally I had said to use a directory "planning" however Git can get confused sometimes; it doesn't always know if you mean the branch or the directory.

Step 4: Set up the branch

git checkout --orphan=planning
git commit -m --allow-empty "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.

Step 5: Adding in excludes

echo "Plan/" >> .git/info/exclude

Step 6 (optional): Cloning

This structure is not stored in a remote. You need to take a few extra steps to recreate it.

cd myRepo
mkdir Plan
git fetch origin planning:planning
git worktree add Plan planning
echo "Plan/" >> .git/info/exclude

#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.

##Areas for improvement

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.

This structure isn't quite recreated on cloning. This is the one actual problem.

Nero gris
  • 562
  • 7
  • 15