3 ms·
Keep the proprietary history to yourself, publish just a squashed snapshot of the state you want to make public, use git-replace [1] to link the public history
by hobo_mark 5y ago
Keep the proprietary history to yourself, publish just a squashed snapshot of the state you want to make public, use git-replace [1] to link the public history with the (hidden) private one when you want full history, develop only on the public one from now on.
[1] https://git-scm.com/book/en/v2/Git-Tools-Replace https://git-scm.com/book/en/v2/Git-Tools-Replace
- infogulch 5y agoI've never seen git replace before, very interesting! Can you use git-replace to edit an old commit message without rebuilding the whole commit graph and instead by just adding a new commit? The article seems to imply that you can use it to "truncate" history but still be able to browse it if you happen to have the full history, or something. I'll have to look more closely into exactly what's going on.
- throw_away 5y agoI think this just changes your own local view of the history. So you can fix the message, but in order for anybody to see it on push, you'd need to reify the changes with git-filter-branch & rebuild. https://www.oreilly.com/library/view/git-pocket-guide/9781449327507/ch10.html#_keeping_it_real https://www.oreilly.com/library/view/git-pocket-guide/978144... https://blog.plover.com/prog/git-replace.html https://blog.plover.com/prog/git-replace.html
- blagie 5y agoI haven't tried, but my read was "yes" when I looked at the intro, and "no" once I got an illustration of the data structure. There is something ambiguous in one or the other. I'm leaning towards "no." The text doesn't make sense, and the data structure does. So I think you still rebase; you can just keep both versions around.