1

Im an electronic product designer, and my projects consist of various parts, like:

  • Hardware design
  • Software design
  • Housing design
  • Instructions
  • Pricing
  • Etc

I have a main project folder, and every part in a separate subfolder.

Right now im using GIT, and i create a new repo for every aspect of the project. For my sake, i use GitExtensions/SourceTree to avoid typing GIT, and having a visual GUI for my change history. For every project i have from 2 to 7 different repos for every aspect related to it. It think this is not the way to go, and i would like to unify everything in a single "container", while keeping separate histories for every aspect.

Here recommend to use a single repo, and the different parts kept in different folders. But i think this will make a single history line.

Here suggest to create one repo, and orphan branches for every part. But i would have to be sure if im on the correct branch everytime i do a commit. Also he suggest to use different repos and push to the same remote, but this would require to have different instances of the GIT GUI opened for every repo.

Im very new to GIT, so my conclusions may not be right.

I would like to have an open GUI for the project, all the parts with "parallel" histories, and if i make a change on the HW, when i make a commit it would be done in the HW history line, or if i make a SW change, then this could be committed to the SW history line. All this without the hassle of checking out branches, or having multiple instances of the GUI.

Is this kind of possible?

Thanks!

PD: maybe there is a better way to organize projects. Id like to hear other solutions also.

Martin
  • 45
  • 1
  • 5

2 Answers2

0

Just commit all your files to a single repo (either a brand new one or by adding all the files to one of the existing repos).

You can view the history of a single subdirectory easily:

git log THE_DIR

Or with the changes shown, not just the commit messages:

git log -p THE_DIR
John Zwinck
  • 239,568
  • 38
  • 324
  • 436
  • 1
    If command line is not your friend, this is now possible in the latest version of source tree https://stackoverflow.com/a/18172519/546375 – Alex M Jan 18 '18 at 13:21
  • I think this option won't allow going back and forth for an individual folder history without affecting the others, also wont allow branching on them, right? – Martin Jan 18 '18 at 15:18
  • 1
    @Martin - It won't provide good support for independent rollback in a single work tree, no. And certainly branching would be across the entire project. – Mark Adelsberger Jan 18 '18 at 18:11
0

You can rig something up using orphan branches and submodules. There's a bit of complexity in this, so you might want to really check your assumption about whether it matters to have separate histories for each part. But if you want to set it up, you could do something like this:

git init
git checkout --orphan master-a
# ... commands to set up the content for project part A in your working tree
git add .
git commit -m "init part A"
git checkout --orphan master-b
# ... commands to set up the content for project part B in your working tree
git add .
git commit -m "init part B"
git checkout --orphan master
rm -rf *
git submodule add -b master-a --name part-a -- ./ a-directory
git submodule add -b master-b --name part-b -- ./ b-directory

I cannot speak to how seamlessly any given UI tool interacts with submodules, though. But this does give you independent histories for each part, while storing everything in one repo, yet having the default branch construct the worktree for the entire project.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • I want separate histories so if im at HW v4.0 and i want to go back to v3.0 i can do it without also rolling back the other parts like SW, etc. If there is a better work flow im open minded. Im starting with GIT and i would like to learn the "good" way to do it instead of realizing that i was doing it wrong for years and have to change – Martin Jan 18 '18 at 17:26
  • @Martin - Ok. In case it was unclear, I have no comment on what your requirements should be; I'm simply pointing out that this combination of requirements entails a sophisticated setup that may or may not be well-supported by your preferred GUI tool. So if you've thought it through and want independent histories in one repo with a unified work tree, this is a way to get it. – Mark Adelsberger Jan 18 '18 at 18:10
  • Im testing your approach, and its quite near what im looking for :) Although i think it needs to clear working dir and index before checking out orphan of branch master-b, otherwise files from master-a will be tracked also on master-b. – Martin Jan 19 '18 at 12:06
  • @Martin - Yes, part of "set up content for project part B in your working tree" includes removing any files that aren't part of project part B. When you stage a "part" branch, your worktree root is relative to that part of the project. The overall tree only exists in the final `master` branch. – Mark Adelsberger Jan 19 '18 at 13:26