On Dec 30, 2010, Jakub Narebski <jnareb@xxxxxxxxx> 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@xxxxxxxxxx/msg00903.html 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@xxxxxxx> 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-rebase.html 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html