Re: rebase parents, or tracking upstream but removing non-distributable bits
- From
Alexandre Oliva <lxoliva@fsfla.org>
- Date
- Dec 30, 2010, 22:32 UTC
- Message-ID
- <or4o9uc2ny.fsf@livre.localdomain>
- In-Reply-To
- <20101230205847.GA29012@burratino>
On Dec 30, 2010, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 6 quoted lines
> 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.
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.
Finally, it wouldn't be a complete solution. Consider, for example, an objectionable file or tree from an early commit, that I replaced with something I can live with. A later commit that changed that tree, or any of those files, would AFAICT *silently* override my replacement, requiring constant monitoring and new replacements for every such change.
With the rewrite/rebase model I have in mind, changes to modified files would conflict, prompting an immediate fix, without any risk of publishing modified versions of unwanted files. (Of course, in my particular case I'd still have to monitor for newly-introduced objectionable stuff, but that's to be expected.)
Did I make any mistakes in my analysis of the “replace” feature? It would be lovely if I could use it, but, in a way, it appears to be the dual of what I need: I need to fix a problem in what I provide to others, while replace would fix the problem in what I see myself.
Anyhow, thanks for the pointer, appreciated!
-- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer