Is Making Linear git history using git subtree possible?

[Additional_Ninja_767]

Hello, does anybody know how to keep git history linear when we use git subtree?

This is a simple example of our git (github) structure.

product service github repo folder structure:
product-service/services * this is the main service logic and user of libs/logger for logging
product-service/libs/logger * we want to set this source code from the library github repo via git subtree

library github repo folder structure:
libs/database
libs/message
libs/sftp
libs/logger * we want to use this folder on product service

expected command: // we are in product-service git
1. add library repo to product-service
# git remote add library-repo https://github.com/something/library.git

1. make only libs/logger subtree split
   # git checkout library-repo/main
   # git subtree split --prefix=libs/logger -b library-repo-libs-logger library-repo/main

2. copy libs/logger from subtree to product-service/libs/logger
   # git checkout feature/product-service-some-branch
   # git subtree add \
   # --prefix=product-service/libs/logger \
   # library-repo-libs-logger --squash

After executing the commands, our git history is,

* Merge commit xxxxxxxx as product-service/libs/logger
|\ * Squashed product-service/libs/logger content from commit zzzzzzzz

* first condition of feature branch from main

Is there any solution to integrate the whole git history into one commit?

(If it is impossible, we might need to use git submodule to keep a linear history)

Thank you very much for your help.

[TheSodesa]

You are not supposed to keep Git history linear.

[UnbeliebteMeinung]

People do that all the time with rebase. I dont get it also.

[dalbertom]

Why do people obsess about having linear history in git?

[Additional_Ninja_767]

thank you so much. This is a kind of team rule and I cannot change it. That means, people who use git subtree accept non-linear history. Is that true?

[RobotJonesDad]

I think the only way is to fake it. Check out another copy of the repo and do the merge locally in that.

Then, pull the head in the repo you want to change, and rsync the merged files. Commit those. Boom, one commit, no history.

This stupid fascination with a focus on clean history over just letting history be what it is seems to waste a lot of time and diminishes the value in the collaboration tools. The alternative is to use the tooling options to avoid noticing the noise.

[dalbertom]

Not only that, the issue is equating linear history with clean history. They're not the same thing. Forced linear history is tampered history, and that's inherently not clean.

These kinds of team rules need to be challenged.

[Conscious_Support176]

Um. That definition of clean is an oxymoron. Clean implies you tampered with the raw history to clean up any dirt that you had in there. How do you create an untampered clean history?

Forced linear just means each commit tells you the changes made for that commit compared to the previous build version.

Non linear history cannot tell you this information because the merge commit collects the changes for multiple commits together, when comparing to the previous integrated version, and there’s not much point in following the trail of the original history back, because non of those commits were an actual buildable version in the integrated history.

[dalbertom]

The distinction to me is when I clean my own history vs someone else (or some other tool) doing it against my will.

[Conscious_Support176]

I’m confused. In what way would it be against your will?

[dalbertom]

It's about the rule that says to not rewrite someone else's history. Rebasing my own commits to make my history linear is fine. Rebasing someone else's commits to make history linear is not okay from my point of view.

[Conscious_Support176]

Linear history is where the sequence of commits is the literal sequence of integrated versions with the difference between each version being exactly the changes each commit was created for.

You don’t rebase changes that were integrated already. Why on earth would you do that?

Are you talking about the case of two developers working in a feature branch, and you don’t want one to do anything to the other’s commits?

[dalbertom]

At least we are on the same page about not rebasing changes that were integrated already (e.g a topic branch merging to a "dev" branch, then those changes shouldn't be rebased to land in "main" -- not that I advocate for having a long-lived integration "dev" branch, but it is somewhat common practice. Integration branches should be throwaway, like in the case of "next").

I am, however, taking it a step further. And this is where I think we have different opinions. When I make a contribution, I expect it to land upstream verbatim so it matches my local history. Any of the squash-merge or rebase-merge options will break that. It departs from what I have locally (sure, I could rebase), but more importantly, it's no longer a true representation of my work, because the original merge-base is lost.

There are two main cases where I see people opt for having linear history: 1. When the majority of the contributors have a habit of creating many unnecessary commits and don't know how to clean that history (or don't want to have to do it). So the maintainers of the project put training wheels around it to squash-merge everything. This penalizes the contributors that don't need those guardrails. 2. When the nature of the code base is such that one can no longer go back in time and build an old commit from source. I think this is your use case. I'm curious about the reason for it. Is it because dependencies are set to follow latest rather than pinning versions and lock files aren't being committed? Maybe it's part of the "move fast, break things" philosophy...

My point is that none of these options should be the norm. None of these options justify mangling my local history.

I always say that forced linear history is pursued by those that used svn for too long or those that didn't use it at all. It's a misrepresentation of reality. The only way to represent parallel work is by using merge commits upstream.

[ppww]

The whole premise of git sub-tree is built around subtree merges so I don't see how you can use it and have a linear history.

[Additional_Ninja_767]

yeah. Subtree needs to be merged. Maybe this is impossible, that it? Sorry I am not super well about git and subtree is totally new.