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

On Dec 30, 2010, Jakub Narebski <jnareb@gmail.com> wrote:

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

Oh, doh, I was modeling them after grafts, but indeed the replace refs,
unlike grafts, can be sent out.  Which doesn't really help, since they'd
be sent out in addition to the objectionable stuff.

Unless the idea is to replace the other way round, i.e., instead of
cleaned-up commit replacing contaminated commit, mark the contaminated
commit as replacing the cleaned-up one.  I haven't explored this
possibility, for it dids't seem to make much sense at first.

> * you replace merge-turned-ordinary commit with a proper merge
>   commit

Aah...  and this would presumably enable further merges onto my local
tree, but I'd public commits that lost history and relationship with
their upstream commits.

I'm aiming at something better than this, something more like the result
of filter-branch, but with improvements for git pull/merge that (i) use
some ref/original mapping (that provides nearly equivalent info to that
of the weak parent idea I proposed before) to tell where we are, what we
have and what needs rewriting, and (ii) perform rewriting of each
brought in commit, keeping local history isomorphic to that of upstream,
and updating the remapping.  Ideally, (iii) have means for merge to use
the remapping backwards, so that one could merge from the cleaned-up
branch to the contaminated branch, or even to publish the remapping as
equivalences rather than unidirectional mappings.  Perhaps storing them
as trees (or some other format) rather than as long lists of refs would
make them more efficient to deal with, especially after packing.

More details about what we're after in the thread containing:
http://www.mail-archive.com/gnu-linux-libre@nongnu.org/ms...


As for the rewriting itself (which I regard as a solved problem, it's
compatibility between rewritten branches that I'm trying to adress), I'm
thinking of making manual changes to the trees whose commits introduced
undesirable content, taking note of the contaminated and clean objects,
and then writing a script to remap with git filter-branch the contents
of the index for each commit, replacing contaminated with clean file, or
removing fully-contaminated file.

> Though I think that better solution would be feature-branch based
> workflow.

We are not in a position to influence how upstream does their
development, and I suppose this would be the case in many (but not all)
of the situations I described as motivators.


On Dec 30, 2010, Yann Dirson <ydirson@free.fr> wrote:

>> I'm under the impression that this could not just work, but also make
>> rebasing in general (especially the hard case) far less problematic, for
>> git would be able to relate a rebased commit with an original commit.

> I suppose that by "hard case" you mean forking off a branch that gets
> rebased later ?

I meant the case described as "hard case" in the git-rebase man page:

http://www.kernel.org/pub/software/scm/git/docs/git-rebas...

Hard case: The changes are not the same.

    This happens if the subsystem rebase had conflicts, or used
    --interactive to omit, edit, squash, or fixup commits; or if the
    upstream used one of commit --amend, reset, or filter-branch.

> This problem suggests a more generic one: how to "merge back" most
> changes from a branch while still not merging some specific changes ?

Thanks for the suggestion.  That made me think that, more than a
parent/child relationship, the original and rewritten commits should be
perceived as siblings as far as merges are concerned, when a
correspondence/equivalence table is given.  Hopefully this wouldn't be
too much of a change to merge and rebase.


Am I making sense?  Does this seem generally useful, say, for someone
trying to do participate in the development of unencumbered portions of
a (patent|copyright|contractually|restriction)-encumbered project?

-- 
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