Re: rebase parents, or tracking upstream but removing non-distributable bits

[Jakub Narebski <jnareb@gmail.com>]

Alexandre Oliva <lxoliva@fsfla.org> writes:

> On Dec 30, 2010, Jonathan Nieder <jrnieder@gmail.com> wrote:
> 
> > Alexandre Oliva wrote:
> >> Now, it looks like I might be able to pull from upstream if I maintain
> >> manually a graft file that named each upstream commit as an additional
> >> parent of the corresponding local rebase commit that brought it into my
> >> rewritten tree.  Workable, maybe, but this wouldn't help third parties
> >> that used my public repository.
> 
> > Have you looked into "git replace"?
> 
> As far as I could tell, it solves a complementary problem.  IIUC, it
> would enable me to replace objects (say files, trees or commits) in my
> local repository so as to remove objectionable stuff, but when I pushed
> a branch out of it, it would go out with the very stuff I'm not supposed
> to publish.  This is because AFAICT replace objects are not sent over
> the wire.

They are not sent by default, but they (refs/replace/*) can be send as
any other ref.

> 
> Even if they were, I still don't think it would be appropriate to use
> them, for I'm speaking of really different trees.  Publishing a commit
> replacement would, for anyone who had both my public repository and my
> upstream, affect not just the branches I published, but also those in
> upstream, which would be surprising and undesirable.
[...]

I guess what Jonathan had in mind was something like that:
* you have two branches, 'clean' and 'contaminated'
* you want to merge 'contaminated' into 'clean', but you don't
  want people to see history of 'contaminated'
* in your private repository you merge 'contaminated' into 'clear'
  (with --no-ff, just in case), save merge commit, then rewrite
  top commit to be ordinary commit not a merge commit; it would
  bring [redacted] changes but not history
* you replace merge-turned-ordinary commit with a proper merge
  commit
* you don't distribute replacement refs to public repository

Though I think that better solution would be feature-branch based
workflow.  Each feature is developed in seperate feature branch.  If
given feature is sutable for 'clean', you merge it into both 'clean'
and in 'contaminated'.  If it is not, you merge it only into
'contaminated'.

Hopefully that would help develop workflow for you.
-- 
Jakub Narebski
Poland
ShadeHawk on #git