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

[Adam Glauser]

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.

On Tue, Mar 31, 2020 at 3:20 PM Erik Schnetter <schnetter at gmail.com> wrote:

> Yes, git filter-branch is probably the way to go.
>
> Be aware that the commit messages themselves will not be filtered: If
> there is a commit that spans both public and private files, then the
> respective commit is filtered (rewritten) to only act on public files,
> but the message itself might still mention a private file.
>
> -erik
>
> On Tue, Mar 31, 2020 at 2:16 PM Doug Moen <doug at moens.org> wrote:
> >
> > I am not a git expert, so the following may be incorrect.
> >
> > However, my intuition is that this isn't possible exactly as stated.
> > The public.git repo contains no version information about private files.
> > Each git commit is a snapshot of the entire tree, and has a hash of all
> > the data in that snapshot. Since the public.git repo contains only a
> subset
> > of the files in main.git, all of the commit hashes will be different.
> > Therefore "pulling changes" from main.git into public.git won't be
> > possible in the way you envision it due to hashes not being the same.
> >
> > Although I've never used it, I suspect that "git filter-branch" could be
> > used to make a copy of main.git from which all of the private files have
> > been removed. It is a very expensive operation, but it would serve the
> > purpose of making the revision history of all the public files available
> > to other people. It's not exactly what you asked for though.
> >
> > Doug Moen.
> >
> > On Tue, Mar 31, 2020, at 5:49 PM, Paul Nijjar via kwlug-disc wrote:
> > >
> > > I have a git repo. Let's call it main.git . It has a bunch of files,
> > > most of which should stay private.
> > >
> > > I have a subset of those files that I would like to share with the
> > > public. Is it possible/easy to set up a second git repo public.git
> > > with the following properties:
> > >
> > > - Contains the files I would like to share and none of the other files
> > >   from main.git
> > > - "Tracks" development on main.git fairly easily (so if I make a
> > >   change to a public file and commit it, then I can easily pull that
> > >   change into the public repo). For this part, let's assume I can be
> > >   disciplined enough to make distinct commits for public files.
> > > - Has NO information in the git changesets about the private files.
> > > - Does not require me muddling with main.git (I do not want to make a
> > >   subproject that includes the public files and then have to worry
> > >   about incorporating that subproject into main.git)
> > >
> > > The fallback is that I don't bother tracking the files, and just
> > > release a snapshot of files I manually copy out of main.git repository.
> > > Being able to track the files in the public repo would be nice, but I
> > > am not willing to compromise my workflow on main.git (much) in order
> > > to accomplish this.
> > >
> > > - Paul
> > >
> > >
> > >
> > >
> > > --
> > > Events: https://feeds.off-topic.kwlug.org
> > > Blog: http://pnijjar.freeshell.org
> > >
> > > _______________________________________________
> > > kwlug-disc mailing list
> > > kwlug-disc at kwlug.org
> > > https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
> > >
> >
> > _______________________________________________
> > kwlug-disc mailing list
> > kwlug-disc at kwlug.org
> > https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
>
>
> --
> Erik Schnetter <schnetter at gmail.com>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20200331/7b718dbf/attachment.htm>