{"thread":{"id":"64126","subject":"Git private branch Feature Suggestion","startedAt":"2025-09-10T23:29:19Z","lastAt":"2025-09-11T08:15:22Z","messageCount":5,"participants":["ynckz","rsbecker@nexbridge.com","brian m. carlson","Henrique Soares","Kristoffer Haugsbakk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"526101","messageId":"CAGyVUB5QLV+HQMWT+0kDu1_H0uXHK7kTy35WqhXQaETZ5if5EQ@mail.gmail.com","threadId":"64126","inReplyTo":null,"subject":"Git private branch Feature Suggestion","fromName":"ynckz","fromEmail":"yanckezcs@gmail.com","sentAt":"2025-09-10T23:28:54Z","receivedAt":"2025-09-10T23:29:19Z","isPatch":false,"sender":{"key":"yanckezcs@gmail.com","avatar":null},"body":"Hi Git developers,\n\nI have a request for you. Could you please add private branches? This\nis a really useful thing.\nImagine that you want to publish your project as open source, but you\nneed to hide the .env file in a separate repository. It's easier to do\neverything in one repository, but in a different branch. Maybe there\nis another way, and I'm just dumb as fuck, but here's another example:\nSay you don't want to release a new feature yet. To do so, create a\nprivate branch, make the feature there, then merge it into the main\nbranch.\n\nMaybe I'm a dumb ass, and don't need to ask this of you, but GitLab,\netc., anyway, I'd appreciate it if you could add this feature.\n"},{"id":"526102","messageId":"061501dc22ae$45ac35c0$d104a140$@nexbridge.com","threadId":"64126","inReplyTo":"CAGyVUB5QLV+HQMWT+0kDu1_H0uXHK7kTy35WqhXQaETZ5if5EQ@mail.gmail.com","subject":"RE: Git private branch Feature Suggestion","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-09-10T23:54:34Z","receivedAt":"2025-09-10T23:54:47Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 10, 2025 7:29 PM, ynckz wrote:\n>I have a request for you. Could you please add private branches? This is a really\n>useful thing.\n>Imagine that you want to publish your project as open source, but you need to hide\n>the .env file in a separate repository. It's easier to do everything in one repository,\n>but in a different branch. Maybe there is another way, and I'm just dumb as fuck,\n>but here's another example:\n>Say you don't want to release a new feature yet. To do so, create a private branch,\n>make the feature there, then merge it into the main branch.\n>\n>Maybe I'm a dumb ass, and don't need to ask this of you, but GitLab, etc., anyway,\n>I'd appreciate it if you could add this feature.\n\nPut your private content into a submodule and set the visibility of that submodule\nto private in GitLab. Your *.env files go in there and will not get shared.\n\nOnce you have this working, please try to use polite language instead of what is\nIn your message. Thanks.\n\n"},{"id":"526103","messageId":"aMIRO83CyG_qtKez@fruit.crustytoothpaste.net","threadId":"64126","inReplyTo":"CAGyVUB5QLV+HQMWT+0kDu1_H0uXHK7kTy35WqhXQaETZ5if5EQ@mail.gmail.com","subject":"Re: Git private branch Feature Suggestion","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-09-11T00:00:59Z","receivedAt":"2025-09-11T00:09:43Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-09-10 at 23:28:54, ynckz wrote:\n> Hi Git developers,\n> \n> I have a request for you. Could you please add private branches? This\n> is a really useful thing.\n> Imagine that you want to publish your project as open source, but you\n> need to hide the .env file in a separate repository. It's easier to do\n> everything in one repository, but in a different branch. Maybe there\n> is another way, and I'm just dumb as fuck, but here's another example:\n> Say you don't want to release a new feature yet. To do so, create a\n> private branch, make the feature there, then merge it into the main\n> branch.\n\nThe reason we haven't added this is that it isn't secure.  Git has a\nfeature called namespaces, which basically implements the feature you\nwant.  There are different namespaces and references can be stored in\nany one of them.\n\nHere's what the gitnamespaces(5) manual page says about this:\n\n    The fetch and push protocols are not designed to prevent one side\n    from stealing data from the other repository that was not intended\n    to be shared. If you have private data that you need to protect from\n    a malicious peer, your best option is to store it in another\n    repository. This applies to both clients and servers. In particular,\n    namespaces on a server are not effective for read access control;\n    you should only grant read access to a namespace to clients that you\n    would trust with read access to the entire repository.\n\nIt then goes on to explain the kinds of approaches that can be used to\nexploit this, but basically, if an attacker can find an object ID that\nit thinks the server has, it can acquire information about that object.\n\nNow, you might say, well, the object ID is private.  But it's very\ncommon to leak those in issues, build logs, or as part of a version\nidentified in a build, so in general we can't base security on that.\nCryptography tells us that cryptographic hashes of general data are not\nsecrets, so we cannot rely on them for access control.\n\nIt could be possible to allow this _if_ Git had some way to know that\nthe client was only allowed to access certain refs _and_ Git were\nconfigured to only allow access to objects that were reachable from\nthose refs.  However, Git doesn't have that information and that's in\ngeneral expensive to determine, so it would make things like partial\nclone perform really terribly.  It would also require a lot of changes\nto Git's internals and security model, and nobody has so far volunteered\nto do that.\n\nI will note that in general, secrets should never be checked into a\nrepository.  It's too easy to accidentally expose a repository, and when\nthat happens, you leak every secret in the entire history, and then\nrotating them all is a colossal hassle.  (I know, I've had to do it.) If\nyou use a secret store, which is a security best practice, then this\ndoesn't happen.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"526104","messageId":"aMIUJJTUegO3Nzcm@localhost","threadId":"64126","inReplyTo":"CAGyVUB5QLV+HQMWT+0kDu1_H0uXHK7kTy35WqhXQaETZ5if5EQ@mail.gmail.com","subject":"Re: Git private branch Feature Suggestion","fromName":"Henrique Soares","fromEmail":"henriquegogo@gmail.com","sentAt":"2025-09-11T00:13:24Z","receivedAt":"2025-09-11T00:13:28Z","isPatch":false,"sender":{"key":"henriquegogo@gmail.com","avatar":"https://gravatar.com/avatar/384040f3ab2afcdfa318aa718b71038956f846a0fee435e161566efdab3bc668?d=mp&s=160"},"body":"On Thu, Sep 11, 2025 at 02:28:54AM +0300, ynckz wrote:\n> I have a request for you. Could you please add private branches? This\n> is a really useful thing.\n\nAny branch created locally is private by default.\nJust don't push it to the remote origin and nobody will have access to it.\n\n> Imagine that you want to publish your project as open source, but you\n> need to hide the .env file in a separate repository. It's easier to do\n> everything in one repository, but in a different branch. Maybe there\n> is another way, and I'm just dumb as fuck, but here's another example:\n\nIf you need to share the .env file to few people, but not to everyone,\nthen use a submodule.\n\n-- Henrique\n"},{"id":"526112","messageId":"fccd1ea3-c57d-4c41-a31b-f0563848416a@app.fastmail.com","threadId":"64126","inReplyTo":"CAGyVUB5QLV+HQMWT+0kDu1_H0uXHK7kTy35WqhXQaETZ5if5EQ@mail.gmail.com","subject":"Re: Git private branch Feature Suggestion","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-09-11T08:15:00Z","receivedAt":"2025-09-11T08:15:22Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Sep 11, 2025, at 01:28, ynckz wrote:\n> Hi Git developers,\n>\n> I have a request for you. Could you please add private branches? This\n> is a really useful thing.\n> Imagine that you want to publish your project as open source, but you\n> need to hide the .env file in a separate repository. It's easier to do\n> everything in one repository, but in a different branch. Maybe there\n> is another way, and I'm just dumb as fuck, but here's another example:\n> Say you don't want to release a new feature yet. To do so, create a\n> private branch, make the feature there, then merge it into the main\n> branch.\n>\n> Maybe I'm a dumb ass, and don't need to ask this of you, but GitLab,\n> etc., anyway, I'd appreciate it if you could add this feature.\n\nI use a sibling repository `.git-mine` with files that don’t\noverlap with those from `.git`.  This way I can have two “working trees”\nchecked out.\n\n-- \nKristoffer Haugsbakk\n"}]}