1

How can I create a new domain branch without duplicating revision history? By domain branch, I mean something like "mac", "windows", "serialization", configuration, or another domain of the application — larger than any feature, but smaller than the application proper. Some argue feature branches may be an anti-pattern. Regardless, it's useful to logically group feature revisions in a domain branch. How can this be done with a fresh revision history, so that the first commit is just a squash from master?

For "release", it's sufficient to just squash every merge from master, since "release" never merges back to "master". The other are upstream of master, but must be created from master and have its prior history by default. I can do it with git checkout master && git switch --orphan <domain> && git checkout master -- .gitignore && git add . && git commit -m "create new domain branch <domain>" && git push --set-upstream origin <domain> && git merge --squash master -m "merge changes from master to domain branch <domain>" --allow-unrelated-histories && git push but that doesn't define the initial commit as a squash in terms of master — it's an unrelated history. That nearly doubles the size of my repo, which is unacceptable once, let alone for multiple domains. Is there a way to do this without ballooning my repository?

kwaalaateimaa
  • 111
  • 4
  • Please correct me if I'm misunderstanding, but are you saying you're looking for a space-efficient way to keep unrelated code with different histories on separate branches, just starting from the same code (a completely squashed version of what's on master)? The feature-branch workflow refers to branches for developing features that are intended to get merged back to master/release/whatever (and is an alternative to long-lived "employee-x" type branches), so it sounds like you might be mixing some terms up. – Zac Anger Jan 12 '23 at 01:38
  • You're provoking the exact behavior you're trying to avoid here. You;'ve severed the history links, congratulations on finding a way to momentarily confuse Git's duplicate detection, but your server will eventually run an (automatic or requested) repack and undo out the damage, your new branch will occupy about 200 bytes total after a repack. – jthill Jan 12 '23 at 02:09
  • @ZacAnger Yes that's what I'm referring to. I also know what a feature branch is — exactly as you described. I'm seeking domain branches in between them. – kwaalaateimaa Jan 12 '23 at 03:08
  • @jthill is there a particular "git repack" command I should run in this context? – kwaalaateimaa Jan 12 '23 at 03:09
  • I believe just `git repack -ad` to have it examine everything and lose everything unreferenced will have it examine the new pack and realize it's all but wholly a dup and delete it (save for the new commit record, that's the 200-ish bytes you really added) – jthill Jan 12 '23 at 04:00
  • Hello. I, for one, do not understand what you are trying to achieve. What purpose do you see in having a branch with a separate history that starts with the content of `master` ? as opposed to start a greular branch from master ? – LeGEC Jan 12 '23 at 06:21
  • @LeGEC clean history is more readable and contextualized – kwaalaateimaa Jan 12 '23 at 08:09
  • @kwaalaateimaa: I would invite you to also consider the viability of having to cherry-pick each new feature and bugfix accross several unconnected branches. – LeGEC Jan 12 '23 at 09:38
  • FWIW: `git commit-tree master^{tree} -m "new commit"` will create a parentless commit with the same content as master. Create a branch from that commit afterwards, e.g: `git switch -c newbranch`. – LeGEC Jan 12 '23 at 09:38

0 Answers0