[kwlug-disc] Subset of files in a second git repo

[Paul Nijjar]

The log/versioning is not that important to me. The thing that is
important is that I will continue to update the files in main.git and
somehow reflect those changes in the public.git. If others want to
fork that and do something with it then they are welcome to, but my
interest is just to publish.

Hooks sound like an interesting idea. Another possibility is just to
generate diffs and patch the public repo manually. 

- Paul

On Tue, Mar 31, 2020 at 11:42:33PM -0400, Adam Glauser wrote:
> Paul, how important is it that the publicly accessible copy of the files is
> versioned? Do you want to facilitate public contributions, or is it more a
> convenient way to serve the files and give some sort of change log?
> 
> Either way, I’m wondering if you’d be just as far ahead to use something
> like a commit hook to automate a publish step or duplicate commit in
> public.git whenever the changes to the public files of main.git are
> committed. This might get a bit tricky where deletions and renames are
> concerned. It would also suffer the problem of possibly leaking info
> through commit messages should your discipline waiver.
> 
> If I’m interpreting the man page for `git filter-branch` correctly, this
> would be a one-time deal to generate the public repo. But it
> would fail the “‘Tracks’ development on main.git fairly easily” criterion I
> think. If public.git is created by filtering main.git, I don’t think you
> would later be able to pull branches from main.git into public.git, since
> git would presumably have to know to filter that branch again. And would it
> even be able to identify the common ancestor to do so?
> 
> It’s quite probable that I’m wrong and git is way smarter than I think, but
> my gut says that rewritten commits from the filter operation won’t jibe
> with the original commits.
>