Phil Hord <phil.hord@xxxxxxxxx> writes: >> I am saying that "separate history" has no place in git workflow, if these >> multiple roots _originate_ in the same single repository with a working >> tree. > > No place in *your* workflow. Oh, wait. Except it has, and you use it > in the git tree. So, um... I'm confused. No, no place in anybody's workflow. I do carry non source html/man branches in the same distribution point repository, but I did not create and I do not have these unrelated branches in my development repository. Possibility to run "git checkout html" in my development repository is just insane. The branch switching semantics of Git is designed to work well when all the branches you check out in the working tree are somewhat related content-wise. You create a new file, or make modifications to an existing file, realize that the change wants to go to a branch different from the current one. You _can_ switch to the branch the change should belong to, because the contents in the working tree is defined to be not tied to any branch, but is floating on top of the current branch. We often see new people who do not understand this (yet) wonder "I modified a file, switched to another branch, but the modification is still there. Why?" It is because the local changes in the working tree do not belong to a specific branch, and local changes could be committed to any branch. What would happen if I were crazy enough to have the html branch in my development repository and checked it out? In addition to the previous build artifacts *.o files, new source files *.[ch] and documentation sources Documentation/*.txt will stay and will be mixed in the checkout of the html branch, where we all know there is no reason for them to be committed on. A sane way to use Git is to have a separate repository to keep track of changes in the other unrelated material, and I have separate repositories with checkouts for html and man. Of course I do not edit them manually; these repositories are targets of "make install-doc" from the source repository. They happen to be pushed into the same distribution point repository, but that is a mere historical artifact. It only started because at k.org I only had a write access to /pub/scm/git/git.git but not to /pub/scm/git/ directory itself; I may have used /pub/scm/git/html and /pub/scm/git/man repositories otherwise. And cloners are advised to "tar-tree" these out and extract them to somewhere else, if they do not want to format the documentation themselves but still want to look at them. Of course, they could "checkout", but you would not edit these generated files in the working tree or commit to these branches. So in that sense, yes they could "checkout", but that is like saying they can run "rm -fr .git" too---they can do useful things and not so useful things just alike. I suspect that people often see those html/man branches in the distribution point repository and get a wrong idea that having these unrelated histories somehow add their coolness factor. It doesn't. >> I have no trouble in a single repository with multiple roots if that is >> done in a distribution point, which by definition does not need and >> typically does not have any working tree. Options to "checkout/commit" >> would not help as they need a working tree. > ... >> The way to do it is to work in multiple repositories, one for each of >> these roots, and push into a single repository from them. > > That's one way to do it. And I have been trying to teach why the other way is a wrong thing to do, but there is no point in teaching a better practice if the listener is not willing to learn. My time is better spent on other topics. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html